[c-nsp] BGP Balanced

[Rodney Dunn]

I agree it's more CPU overhead but that's what
happens when you are in a software based forwarding
environment and you add more features.

What I do find to help though is that a lot of customers
do fragmentation when they don't really need it.
You could get similar load balancing result without 
fragmentation enabled and you save that extra CPU
overhead.  It will not be the exact load balancing
result but my experience has showed it's very very close.

If you need QOS and it's on low speed links you need
the fragmentation/LFI.

"significantly more CPU" is too broad based of a comment
because people think that's the case for any MLPPP
deployment example which is not the case.  It's correlated
to a bunch of factors: # member links, speed of links,
fragmenation or not, etc...

Doing MLPPP on a 26xx with 2x56k dialup links, I'd say the
CPU overhead is insignifiant.  Doing it on a 26xx with
4 T1's bundles together at line rate with 64 byte packets
then I would say it is significant.

You have to match it up to the individual deployment scenario.

Rodney

On Wed, Aug 25, 2004 at 10:58:50PM +0200, sthaug at nethelp.no wrote:
> > Compare the transfer rates with the different options.
> > 
> > The best you'll get is with MLPPP because it solves the 
> > out of order problem and the "only use one link" problem.
> 
> Absolutely. The drawback is that MLPPP is significantly more CPU
> intensive - enough so that I've seen many cases where MLPPP was
> unusable and other forms of load balancing were fine.
> 
> Steinar Haug, Nethelp consulting, sthaug at nethelp.no