Thanks for reply. My intention was try to reproduce the logic of the routing cache using the firewall rules (by conntrack). The problem with using only the CONNTRACK/CONNMARK is a balancing per connection. Many web applications use a control session internally. And most of the time we do not have this persistence by socket. I've had problems with this before. Imagine your public IP addr changing between a connection and another for the same destination. For this reason I wanted to find a way to control it by "flow". Apparently I got a better result than the routing cache. Before I increased the amount of gc_timeout just to ensure a greater time for the flow in question. The problem is that it forced me to have a script in the background to handle failover. And decrease the value of gc_timeout would bring me more problems (a lot of people recommended to do this as failover, but it certainly brings you problems with the control session). Now i define and update the timeout by ipset. If the link becomes unavailable, the packet is retransmitted in round-robin and the next link is attempted. The result was better than that obtained previously with gc_timeout. May not need more failover script (I'm still not sure about this). Now I see this as a real advantage. I changed the logic of my firewall script to generate this: -N GETMARK -A GETMARK -m mark --mark 0x0 -m set --match-set lb_link1 src,dst,dst -j MARK --set-xmark 0x301/0xffffffff -A GETMARK -m mark --mark 0x0 -m set --match-set lb_link2 src,dst,dst -j MARK --set-xmark 0x302/0xffffffff -N SETMARK -A SETMARK -o eth0 -m mark --mark 0x0 -j MARK --set-xmark 0x301/0xffffffff -A SETMARK -m mark --mark 0x301 -j SET --add-set lb_link1 src,dst,dst --exist --timeout 1200 -A SETMARK -o eth1 -m mark --mark 0x0 -j MARK --set-xmark 0x302/0xffffffff -A SETMARK -m mark --mark 0x302 -j SET --add-set lb_link2 src,dst,dst --exist --timeout 1200 -N CNTRACK -A CNTRACK -o lo -j RETURN -A CNTRACK -o eth0 -j SETMARK -A CNTRACK -o eth1 -j SETMARK -A CNTRACK -m mark ! --mark 0x0 -j CONNMARK --save-mark --nfmask 0xffffffff --ctmask 0xffffffff -P OUTPUT ACCEPT -A OUTPUT -m mark --mark 0x0 -j GETMARK -A OUTPUT -m mark --mark 0x0 -j CONNMARK --restore-mark --nfmask 0xffffffff --ctmask 0xffffffff -P PREROUTING ACCEPT -A PREROUTING -m mark --mark 0x0 -j CONNMARK --restore-mark --nfmask 0xffffffff --ctmask 0xffffffff -A PREROUTING -m mark --mark 0x0 -j GETMARK -P POSTROUTING ACCEPT -A POSTROUTING -j CNTRACK Thanks! 2014-03-04 4:56 GMT-04:00 Nikolay S. <nowhere@xxxxxxxxxxxxxxxx>: > В Пн, 03/03/2014 в 13:54 -0400, Humberto Jucá пишет: > > Just an idea. Grab HMARK in prerouting, use this mark to select routing > table. Then in input/output/forward/postrouting chains you can re-use > fwmark for queue selection or anything else. > > -- 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
