# Remove the mark inversion iptables -t mangle -I PREROUTING -i eth1 -m mark --mark 0x0 -j CONNMARK --restore-mark 2013/11/7 Humberto Jucá <betolj@xxxxxxxxx>: > I think I'll miss some scripts! rs > I dont belive in this! > > > Not tested, but might work: > > Client: 192.168.1.1/24 > > Lan Router: 192.168.1.254/24 > Lan Router wan side:192.168.100.254/24 > > Wan IF: eth1 > > Wan Router 1:192.168.100.1/24 > Wan Router 1-wanip: 3.3.3.3 > > Wan Router 2:192.168.100.2/24 > Wan Router 2-wanip: 4.4.4.4 > > > Probably I would use VLAN (mark in vlan interface). > But I think you can resolve with realms (I do not know if it works). > > ip route flush table 100 > ip route add throw 10.0.0.0/8 table 100 realm 100 > ip route add throw 192.168.1.0/24 realm 100 > ip route add default via 192.168.100.1 realm 100 > > ip route flush table 101 > ip route add throw 10.0.0.0/8 table 100 realm 101 > ip route add throw 192.168.1.0/24 realm 101 > ip route add default via 192.168.100.2 realm 101 > > ip route flush table 200 > ip route add default \ > nexthop via 192.168.100.1 realm 100 \ > nexthop via 192.168.100.2 realm 101 > > ip rule add prio 10 table main > ip rule add prio 20 from 192.168.100.1 table 100 > ip rule add prio 21 from 192.168.100.2 table 101 > ip rule add prio 22 fwmark 0x100 table 100 > ip rule add prio 23 fwmark 0x101 table 101 > ip rule add prio 50 table 200 > > ip route del default > > iptables -t mangle -A POSTROUTING -o eth1 -m realm --realm 100 -j > CONNMARK --set-mark 0x100 > iptables -t mangle -A POSTROUTING -o eth1 -m realm --realm 101 -j > CONNMARK --set-mark 0x101 > > iptables -t mangle -A POSTROUTING -o eth1 -j CONNMARK --save-mark > > iptables -t mangle -I PREROUTING -i eth1 -m mark ! --mark 0x0 -j > CONNMARK --restore-mark > > 2013/11/7 Eliezer Croitoru <eliezer@xxxxxxxxxxxx>: >> On 11/08/2013 02:39 AM, Humberto Jucá wrote: >>> >>> You're talking about this: >>> >>> http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=89aef8921bfbac22f00e04f8450f6e447db13e42 >> >> Exactly!!! >> >> >>> I will need to research about it too. >> >> >> The main problem with LoadBalancing based on route cache is that it's not >> real loadbalancing but rather an exploit of the routing capabilities design. >> >> A route cache is per *route* >> means all traffic from this "src ip" that travels throw "this local ip" >> towards "this remote ip" will continue to be routed like this for the next >> 300 secs.. >> as a route cache entry states: >> # ip route get 209.169.10.131 >> 209.169.10.131 via 192.168.10.254 dev eth0 src 192.168.10.1 >> cache mtu 1500 advmss 1460 hoplimit 64 >> ##end >> >> So let say I am issuing 20 connections towards the same host the exact same >> gateway will be used as long as the garbage collection will not remove the >> entry. >> In this time the nexthop\gateway could fall down and get up about 60++ >> times.. >> >> So from what I understood from the change in the kernel is that a routing >> system should use the FIB to calculate the right path (10Mpps is enough?) as >> expected from a dynamic routing system on the packet level instead of >> routing the packets based on a cache and a FIB lookup in a case needed(which >> means it can take two lookups one for the cache and second using the FIB). >> >> In a case of LoadBalancer I would assume there is a need for iptables >> connection marking which has an option to really follow the TCP and UDP >> connections and not just routing based on cache. >> In any case IPTABLES based loadbalancing of TCP level (not an application >> level) can take a bit more cycles and a bit more RAM but it still faster >> then any proxy application. >> >> But an application that monitors the LB router and the services servers load >> constantly can change "static" routes to make sure that the load is >> distributed. >> In this case there must be some connection tracking on the LB to make sure >> that the TCP connections will not just break to the clients in the middle of >> a connection which can lead to a "read error" for example. >> >> How to handle these errors? I think it's another subject which I want to >> later on read more about. >> >> Eliezer >> >> >> >> -- 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
