[f-nsp] XMR Load balancing
boards188 at gmail.com
Tue May 29 12:24:42 EDT 2007
Niels, thanks for the response. My description was pretty poor, as I
look back over it. I am not questioning whether the load balancing
algorithm is working or not; but my concern is the way it treats an
ICMP traceroute. If I originate an ICMP traceroute from behind the
router to a destination on the internet for which the XMR has two
equal cost routes (or paths, especially in the case of "multipath
multi-as"), it appears to do per-packet load balancing. If my
customer has a problem, he is going to conduct a traceroute and the
XMR will send the packets out different paths. He will infer that
this is the problem (i.e. per-packet load balancing, which could cause
latency and packet re-ordering, etc.) when in fact it may not be the
case since the XMR does the "4 tuple" load balancing on TCP and UDP
If I conduct a traceroute (ICMP) that originates from the XMR to a
destination with two equal cost paths, it always keeps that traceroute
on one path. That seems to me to be very inconsistent.
I am in discussions with Foundry currently on this, but I am not
getting much help explaining why this is the way it should be.
Also, I didn't think there was a way to change the load balancing
algorithm. I thought it was either on with "ip load-sharing <num>" or
off with "no ip load-sharing". By the way, I really want to use the
load balancing across multiple AS'es with the "multipath multi-as",
but I can't right now because of the "perceived" (i.e. per-packet load
On 5/28/07, Niels Bakker <niels=foundry-nsp at bakker.net> wrote:
> * boards188 at gmail.com (Jason Pope) [Sun 27 May 2007, 21:29 CEST]:
> >Has anyone experienced problems with the XMR and load balancing?
> [snip description of XMR load-balancing working]
> I'm not sure I see anything wrong with your description. Generally,
> load-balancing algorithms use src and dst IP addresses and TCP/UDP port
> numbers or ICMP sequence. Not all equipment balances IPv6 and multicast
> traffic as nicely as most do IPv4.
> Given a recent amount of entropy, hash-based load-balancing works quite
> well, in my experience. The XMR can do per-packet too. Just be aware
> that that might in some cases lead to packet reordering. And stay away
> from "switch trunks" (support for which the XMR deprecates).
> -- Niels.
> foundry-nsp mailing list
> foundry-nsp at puck.nether.net
More information about the foundry-nsp