North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: Load balancing in routers

  • From: Tony Tauber
  • Date: Mon Apr 08 14:08:21 2002

On Mon, 8 Apr 2002, Chris Woodfield wrote:

> If by "round-robin" you mean by destination only, then this is
> correct.

The term "round-robin" refers to a schedule which cycles
through some number of things in a fixed order.

A packet arrives and the router makes a forwarding decision.
The things that it can cycle through are entries in a forwarding table.

Those entries can be either physical paths (ie. one packet
goes over this link, next packet over the next and so forth).
Call that "per-packet load-sharing"

The entries could be cached destinations.
Call that "per-destination load-sharing"

The entries could be based on source/destination pairs.
Call that "flow-based" or "src/dst-based".

The entries could be based on the whole "5-tuple" of
source and destination address, IP protocol, source
and destination port numbers (and ToS value)?
Call that "full-flow".

Now, how effective any of these schemes are at sharing load
at a bit level (how links operate) vs. packet level (how
forwarding decisions are made) has been the subject of
debate for some time.

> However, if you [mean] strict per-packet load sharing regardless
> of flow, then CEF does have this capability, although the default
> behavior is the flow-based load sharing you describe.
> However, IIRC, code stability issues have plagued this feature in
> many IOS releases; I recall Intermedia selling a "bonded T1" product
> that used this feature, and supporting it was...not pleasant.
> -C

I'm not sure about stability, I think it's been stable.
However, there's a fundamental issue with the GSR architecture
which affects it's applicability there.

On the GSR, forwarding decisions are made on ingress to the router;
but, per-packet is configured on the outbound interface.  The ingress
interface has no way to keep track of which outbound interface a
packet was last sent to; that would require some kind of counter.
I believe, some kind of workaround may have been coded for this
problem recently, but it might have significant performance impact
and/or negate other "extended" feature sets.


> > We used CEF in 11.x and it behaved the same way.  It was never round-robin
> > in any way we could observe.