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
