[LARTC] Problems with ICQ etc. on nano-setup

[LARTC] Problems with ICQ etc. on nano-setup

[Steen Suder, privat]

I administer a nano-setup on a dorm-network with a couple of hundred 
active users.

The setup uses 2 x 2 2Mb/s DSLs, meaning two DSLs from each of two 
different ISPs.

It works fine except for some minor glitches:

https-sites often kicks users. This was solved by tying outbound https 
to a single DSL. Not the best solution but it works so far that users 
dont kicked from the sites anymore. Now they can put credits on the 
SIM-cards again ;-)

ICQ-logins is a pain as it often takes several attempts (4-8 usually) to 
get connected to ICQ.
I've tested with the latest micq from a host on the LAN and it says 
"Connection refused (111)". The same behaviour goes for all other 
(reported) clients of all kinds on the LAN. On the same time ICQ works 
fine from othe locations.

Now I'm wondering and it is somewhat ICQspecific: when one connects to 
ICQ one gets redirected to another server. Perhaps this redirect causes 
the connection to take another DSL on its way onto the Internet... and 
maybe the new sourceaddress causes the ICQ-server to drop the connection 
attempt due to difference between the initial sourceaddress and the 
"second" sourceaddress.

Now, the simple way to solve this issue is to bind anything even 
remotely related to ICQtraffic to one single DSL, but I'd really like to 
solve this "The Proper Way".

Suggestion:
Can one "bind" traffic from one LAN-user to the same DSL, effective in 
lets say 10 minutes from the initial connection?
Can some magic with conntrack be put to use?


1. How can I find out what is causing this "glitch"?

This would be rather important since it could be the cause of other 
"irregularities" in the operation.


2. How is this solved?



A snippet from the /etc/sysctl.conf:

net.ipv4.route.max_size2768
net.ipv4.route.gc_min_interval=5
net.ipv4.route.gc_interval00

It's a 2.4.23-box and it does SNAT on all four DSLs.
It's pretty open from the inside towards the Internet.

-- 
Mvh. / Best regards,
Steen Suder		<http://www.suder.dk/>
ICQ UIN			4133803

_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

Re: [LARTC] Problems with ICQ etc. on nano-setup

[Ben Efros]

Since you are doing SNAT on all the dsl lines, I'd suggest using the -j SAME
target available for netfilter.

http://netfilter.org/documentation/pomlist/pom-base.html#SAME




----- Original Message ----- 
From: "Steen Suder, privat" <steen@suder.dk>
To: <lartc@mailman.ds9a.nl>
Sent: Sunday, December 14, 2003 6:57 PM
Subject: [LARTC] Problems with ICQ etc. on nano-setup


> I administer a nano-setup on a dorm-network with a couple of hundred 
> active users.
> 
> The setup uses 2 x 2 2Mb/s DSLs, meaning two DSLs from each of two 
> different ISPs.
> 
> It works fine except for some minor glitches:
> 
> https-sites often kicks users. This was solved by tying outbound https 
> to a single DSL. Not the best solution but it works so far that users 
> dont kicked from the sites anymore. Now they can put credits on the 
> SIM-cards again ;-)
> 
> ICQ-logins is a pain as it often takes several attempts (4-8 usually) to 
> get connected to ICQ.
> I've tested with the latest micq from a host on the LAN and it says 
> "Connection refused (111)". The same behaviour goes for all other 
> (reported) clients of all kinds on the LAN. On the same time ICQ works 
> fine from othe locations.
> 
> Now I'm wondering and it is somewhat ICQspecific: when one connects to 
> ICQ one gets redirected to another server. Perhaps this redirect causes 
> the connection to take another DSL on its way onto the Internet... and 
> maybe the new sourceaddress causes the ICQ-server to drop the connection 
> attempt due to difference between the initial sourceaddress and the 
> "second" sourceaddress.
> 
> Now, the simple way to solve this issue is to bind anything even 
> remotely related to ICQtraffic to one single DSL, but I'd really like to 
> solve this "The Proper Way".
> 
> Suggestion:
> Can one "bind" traffic from one LAN-user to the same DSL, effective in 
> lets say 10 minutes from the initial connection?
> Can some magic with conntrack be put to use?
> 
> 
> 1. How can I find out what is causing this "glitch"?
> 
> This would be rather important since it could be the cause of other 
> "irregularities" in the operation.
> 
> 
> 2. How is this solved?
> 
> 
> 
> A snippet from the /etc/sysctl.conf:
> 
> net.ipv4.route.max_size2768
> net.ipv4.route.gc_min_interval=5
> net.ipv4.route.gc_interval00
> 
> It's a 2.4.23-box and it does SNAT on all four DSLs.
> It's pretty open from the inside towards the Internet.
> 
> -- 
> Mvh. / Best regards,
> Steen Suder <http://www.suder.dk/>
> ICQ UIN 4133803
> 
> _______________________________________________
> LARTC mailing list / LARTC@mailman.ds9a.nl
> http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
> 
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

Re: [LARTC] Problems with ICQ etc. on nano-setup

[Steen Suder, privat]

Ben Efros wrote:
> Since you are doing SNAT on all the dsl lines, I'd suggest using the -j SAME
> target available for netfilter.
> 
> http://netfilter.org/documentation/pomlist/pom-base.html#SAME

As I understand it, SAME cannot be used here since the "loadbalancing" 
in a nano-setup is done by the routing (multiple default gateways) and, 
thus, the traffic is already going out a particular interface when it 
reaches the POSTROUTING chain (where SAME lives).

Also, we have only one public IP on every WAN-if.

If I just could manipulate the routing in the kernel to tie new 
connections from a given LANuser to a specific WANif, at least for a 
brief period of time, I'd think the issue would be solved.

<SNIP problems with ICQ behind a nanosetup>

-- 
Mvh. / Best regards,
Steen Suder		<http://www.suder.dk/>
ICQ UIN			4133803

_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

Re: [LARTC] Problems with ICQ etc. on nano-setup

[c0g]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

| Can one "bind" traffic from one LAN-user to the same DSL, effective in
| lets say 10 minutes from the initial connection?
| Can some magic with conntrack be put to use?

You should do Equal Cost Multipath (iproute) + MARK target instead of
state-based loadbalancing for problematic protocols/sites.

Create table with default route thru multiple gateways with equalize
option. Then direct problematic traffic to this table (using routing
rules and mark matching)

Equal Cost Multipath chooses route based on source and destination IP,
so it bounds client to route, no matter how many connections that client
made.

It works for me.

PS: I assume you have separate network interface in your Linux router
for each DSL, so you can do SNAT on each interface. If you have them
connected to one NIC then it not that simple, but may be resolved with
route realms (but not sure for 100%).

- --
c0g@wp.pl
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQE/3atPPqmVt5WhbA8RAo/HAJ9XJ1Fb+/LLDkEQs5aUh9nS7aN8DgCfbuVu
yfQXVOluF+uY7DC5+JZxM4g¤og
-----END PGP SIGNATURE-----

_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

Re: [LARTC] Problems with ICQ etc. on nano-setup

[Steen Suder, privat]

c0g wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> | Can one "bind" traffic from one LAN-user to the same DSL, effective in
> | lets say 10 minutes from the initial connection?
> | Can some magic with conntrack be put to use?
> 
> You should do Equal Cost Multipath (iproute) + MARK target instead of
> state-based loadbalancing for problematic protocols/sites.
> 
> Create table with default route thru multiple gateways with equalize
> option. Then direct problematic traffic to this table (using routing
> rules and mark matching)

Could I not just apply this method to all traffic?

> Equal Cost Multipath chooses route based on source and destination IP,
> so it bounds client to route, no matter how many connections that client
> made.

Sounds better, actually.

Can you point in the direction of some practical examples?
Perhaps some specific documentation?

> It works for me.
> 
> PS: I assume you have separate network interface in your Linux router
> for each DSL, so you can do SNAT on each interface. If you have them
> connected to one NIC then it not that simple, but may be resolved with
> route realms (but not sure for 100%).

This assumption is correct. The box has a separate, physical interface 
for each DSL and I do simple SNAT for each outgoing (DSL) interface as 
it is now.

-- 
Mvh. / Best regards,
Steen Suder		<http://www.suder.dk/>
ICQ UIN			4133803

_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/