Re: Multihome load balancing - kernel vs netfilter

Linux Advanced Routing and Traffic Control

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tuesday 05 June 2007 03:48:01 Salim S I wrote:
> -----Original Message-----
> From: Luciano Ruete [mailto:luciano@xxxxxxxxxxxxx]
> Sent: Saturday, June 02, 2007 11:28 AM
> To: Salim S I
> Cc: lartc@xxxxxxxxxxxxxxx
> Subject: Re:  Multihome load balancing - kernel vs netfilter
>
> >Is not about ego, sorry if you take this personal, it is not my
>
> intention, >i
>
> >speak rude because this list get heavly indexed by google, and it is
>
> taked >as
>
> >good advice for many answer seekers.
> >
> >You afirm that Linux cannot handle load balancing properly and this is
> >completly WRONG and is bad advertising and a lie.
> >
> >Since 2.4 series has been avaible the greats julian's patchs[1], and
>
> then >in
>
> >2.6.12 CONNMARK has get in mainline, and with a litle of setup all
> >connection
> >problems related to load balancing get perfectly solved.
>
> I did not say Linux can't do Load balancing (btw, my setup has Julian's
> DGD patch as well as CONNMARK). But there are some limitations to the
> popular methods currently used.
>
> 1.As Peter Rabbitson [rabbit@xxxxxxxxx] mentioned, one issue is the
> separate control and data servers. He mentions AIM servers as example.
> This probably can only be solved by having exception IP list.

Ok, this is one clear example where NAT concept fails in load balancing, this 
is not much Linux related, there is no magic to be done here but to write 
special code for that protcol(as a helper, right). But the helper is not 
needed in a normal setup.
This AIM "geniality" could be done transparent to the end user, and even doing 
it at clients code, there is not need to use the IP as a part of the auth 
mecanism, is for shure insecure and useless.
So i will not blame Linux on this one.

> 2.The other situation, and the one I am more concerned, is about
> different connections which belongs to same session.
>
> Consider Client X and Server Y.
>
> Client X initiates a connection from port a to port b of server Y.
>
> Xa <---> Yb   This connection goes through WAN1.
>
> After sometime, X opens another connection to Y from port c to port d.
>
> Xc <---> Yd   This is a perfectly new TCP connection, so it may go
> through WAN2
>
> (Note that the client is NATed, and that no CONNTRACK exist for this
> app)
>
> The server may reject the second and subsequent connections as it comes
> in with a different source IP than the first.

well it is perfectly clear now.

> This situation happens often in IM and Gaming scenarios. 

I really don't know what IM protocol do this..., if you can specify will be 
better, i have no complains about any IM issue related to load balancing, i 
personally use MSN and Jabber protocols and have not problems at all.

In games i'm not an expert, but i will like to know what is the percentage of 
this special games. Route cache will help as mentioned in case like this but 
it is not fail safe.
But again, this are things that affect not only a Linux box doing load 
balancing, it will affect any other solution, and AFAIKSee you need to start 
to write special per protocol helpers _only_ for load balancing proupouses. 

This are application exceptions, they are not linux fails, they are not 
designed taking in account special setups like NATed load balancing, that's 
it.

> Some sort of IP 
> persistence is required to handle this. And I was wondering if recent
> match would solve this to an extent, without affecting performance. Or
> if there are some other method available. (Note that I can't depend much
> on cache).

I think "recent" could work, matching only the special ports(and optionally 
each client address) the impact on other clients will using same ports but 
with different applications will be mostly null. 

-- 
Luciano
_______________________________________________
LARTC mailing list
LARTC@xxxxxxxxxxxxxxx
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

[Index of Archives]     [LARTC Home Page]     [Netfilter]     [Netfilter Development]     [Network Development]     [Bugtraq]     [GCC Help]     [Yosemite News]     [Linux Kernel]     [Fedora Users]
  Powered by Linux