[nsp] ip load-sharing per-packet - cef accelerated ?

[Chris Whyte]

> On Mon, 10 Mar 2003, Jared Mauch wrote:
> 
> > On Mon, Mar 10, 2003 at 02:22:12PM -0800, Dan Hollis wrote:
> > > My understanding is that 'ip load-sharing per-packet' is CEF
> > > accelerated, yes?
> > >
> > > Just trying to understand why some providers won't support
> > > per-packet CEF.
> >
> > 	A good reason they tend to avoid it is it causes out of order
> > 	packets which result in lower end-to-end throughput.
> >
> > 	What you want is a srcIP/dstIP/srcPT/dstPT based balancing to
> > 	be perfectly honest.  This will keep the same flows on the
> > 	same circuit.
> >
> > 	- Jared
> 
> Jared's right, of course, though there could be cases where a given
> flow could exceed the size of one of the parallel paths as in the case
> of a proxy.
> 
> Here's something else to consider, though.  In the GSR architecture,
> the outbound interface lookup is done on ingress.  Where the ingress
> port is on an Engine 2 card (eg. Quad-OC12 or single-port OC48), there
> does not exist the capability (so it's been explained to me by Cisco
> engineers) to keep track of which interface a packet was last sent on
> so that the per-packet decision could be implemented.

Note: This is, of course, only an issue with E2. Newer LCs (with ingress
and egress forwarding engines) don't have this problem. Older sw-based
engines work with both options too.

On a different note, unless they've done something recently, there's
definitely no "accelerated" mode for per-packet LB. And as with GSR, I
believe any potential performance hit (between the two) will vary
depending on the implementation throughout cisco's product lines. I've
never seen a non-bug-related problem with using per-dest though. In
addition, there's actually much more than two options and other other
issues to consider. The 'original' per-dest has polarization issues so
they've added other algorithm options of which were NOT referenced in
the link that Dan posted earlier (unless I missed them).

I used to have an excellent ip cef LB doc (written by Neil J) that
described every option and the potential problem it solved.
Unfortunately, I can't seem to locate it. I believe it's also documented
in a DDTS. Maybe someone from cisco will chime in since I highly suspect
they know what doc I'm referring to. :-) Of course, it might also be
outdated by now...

Thanks,

Chris


> 
> We've seen that MLPPP can work to distribute the load so that a given
> flow can grow larger than the physical size of any of the component
> parallel paths.  MLPPP isn't the CPU pig that it was in earlier
> implementations or on different platforms.  Of course, YMMV.
> 
> Tony
> 
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> http://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>