well....I've just done a test with CONNTRACK and CONNMARK modules as link indicated for Andrew and it's work the load Balance. but I still wonder what is the metric used to do the load balance I guess that the point is in line below iptables -t mangle -A PREROUTING -p tcp -m state --state NEW -m statistic --mode nth --every 2 --packet 0 -j CONNMARK1 iptables -t mangle -A PREROUTING -p tcp -m state --state NEW -m statistic --mode nth --every 2 --packet 1 -j CONNMARK2 I understand that each two new connections the third go out to next link making the load balance. right ?? thank! 2011/5/16 Grant Taylor <gtaylor@xxxxxxxxxxxxxxxxx>: > On 5/16/2011 16:38, Andrew Beverley wrote: >> >> If you don't do this, then each gateway will only see half the >> packets for a connection stream, which although I am not an expert, I >> guess is not a good thing. > > The problem has to do with the fact that most connections are using NAT at > the edge, not a globally routable IP behind the load balancer with multiple > routes back in. > > So what happens is that some of the traffic for a session is sent out one > gateway and being NATed to one external IP and the other traffic for the > same session is being sent out the other gateway and being NATed to a > different external IP. Thus, the server sees weird traffic, coming from two > different IPs. One connection exhibits drops and the other exhibits > incorrect sequence (think TCP 3-way handshake). The server will abort the > out of order / incorrect state traffic, which really causes the client to > abort the entire connection. You end up with a mess. Thus you need to use > something like conntrack to make connections be persistent when NAT is > involved like that. > > > > Grant. . . . > -- > To unsubscribe from this list: send the line "unsubscribe netfilter" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- To unsubscribe from this list: send the line "unsubscribe netfilter" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
