On Wednesday 21 February 2007 11:10, Andrew McGill wrote: > The LARTC howto correctly describes load balancing and split > access for traffic from a machine with multiple ISP connections > (http://www.lartc.org/lartc.html#LARTC.RPDB.MULTIPLE-LINKS) -- > *provided* the traffic originates from the machine itself (i.e. > traffic regularly handled by the INPUT and OUTPUT chains of > iptables). > > When forwarding traffic from an attached local network, the > following problems occur with traffic from the local network to > internet hosts: > > 1. The ip rule add from x.x.x.x refers to local IP addresses > before NAT, such as 192.168.0.44, rather than the public IP > address after NAT (and certainly not both). This is the > fundamental problem that causes load balancing and split > access to be unreliable. the 'ip rule' is evaluated before the routing desition so, this is before FORWARD and before POSTROUTING(the place where NAT actualy happens) so far. Hence, refer to the local IP is correct. > 2. Cached routes are dropped periodically from the route cache, > even while in active use: this causes connection reset errors > and strange timeouts. this is true, and to increase the routes timeout does not help cause at the end you have all internet routes cached making your kernel/noswapable RAM to kicks out every single app on the host. The solution is to use CONNTRACK from iptables, full example described in this[1] e-mail from the archive. No patches needed. > 3. To frustrate iptables based work-arounds, routing does not > obey marks added with iptables -t mangle -A PREROUTING. It > seems that ip fwmark rules are not obeyed if the route is > cached, this is not true, the rules are evaluated before the routing desition, so fwmark rules works as expected. You really think that this BUG can be in linux kernel since early 2.3/2.4 versions and be discovered today? > and the cache hash does not include the firewall mark > (or maybe it does, but it doesn't work ?!?). (Interestingly, > cached routing *does* obey the TOS bits, which makes creative > work-arounds marginally possible. There just aren't too many > TOS values to play with.) > Is there a solution to these problems which works with the official > kernels? If so, which versions? If not, which patches resolve these > problems? Yes as i pointed out, there is a solution and no patches needed. [1] http://mailman.ds9a.nl/pipermail/lartc/2006q2/018964.html -- Luciano _______________________________________________ LARTC mailing list LARTC@xxxxxxxxxxxxxxx http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
