R: Re: iproute2 load balacing

hello, thank you for your response.

Configuring the multipath as I
showed you, I need to split the traffic between the two wan. The
traffic, however, does not come from the LAN, but is degeneratedby the
firewall.

Using this rule:

ip rule add fwmark 3 table 3
ip rule add
fwmark 4 table 4

iptables-t mangle-A OUTPUT-p tcp - dport 25-j MARK -
set-mark 3
iptables-t mangle-A OUTPUT-p tcp - dport 110-j MARK - set-
mark 4

but it also happens that packets coming out from the right
interface but with the ip of the other WAN and viceversa

So I decided
to use SNAT --to ip[eth1] and SNAT --to ip[eth2] ,forcing a correct
routing.

But ,I did not understand why, I must constantly flush the
routing cache otherwise I lose packets and dont work.
Tnx
ninnig


----
Messaggio originale----
Da: pascal.mail@plouf.fr.eu.org
Data: 18-mag-
2012 11.30
A: "ninnig1@tin.it"<ninnig1@tin.it>
Cc: <debian-
firewall@lists.debian.org>
Ogg: Re: iproute2 load balacing

Hello,


ninnig1@tin.it a écrit :
> I have doubts about the management of the
multipath with iproute2.
>
> In particular, do not understand how is
the distrubution of traffic
> between two gateways.
>
> Use this
command
> ip route add default scope global \
> nexthop via
192.168.1.1 dev eth1 weight 1 \
> nexthop via 10.64.64.64 dev ppp0
weight 1
>
> Actually I see that some servers will reach from
192.168.1.1, others
> from10.64.64.64, but I do not understand the
logic that uses this command.
>
> Can you help me understand?

iproute
multipath does not distribute traffic but routing cache entries.
A
routing cache entry is based on the source and destination addresses,

and is used to route all packets matching these until it expires.
It
means that all communications from A to B will use the same path

because they use the same routing cache entry. The distribution

algorithm is a simple weighted round robin and does not take the amount

of traffic on each path into account.

The efficiency as a load
balancing increases with the number of routing
cache entries, i.e. the
number of sources and/or destinations.






--
To UNSUBSCRIBE, email to debian-firewall-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: http://lists.debian.org/137760c47ef.ninnig1@tin.it