[c-nsp] Etherchannel and variable latency on member links

Peter Rathlev peter at rathlev.dk
Tue Mar 24 15:41:29 EDT 2009

Thank you to Ian who replied off list with an example of an
unproblematic implementation of exactly this. I'm more calm now. :-)

On Mon, 2009-03-23 at 19:09 -0400, Jeff Kell wrote:
> AFAIK, etherchannel will select one physical path per flow (based on 
> src/dst ip/mac), so there is no out-of-order to it, nor any load-sharing 
> in the sense that it pays any attention to the link load at all.  At 
> least from the Cisco end... I can't speak for all vendors / host adapters.
> If it *can* load-share, cisco-to-cisco, I'd love to be corrected; but 
> you need something like EIGRP for that (to really look at "load") or 
> equal-cost paths and per-packet load sharing.

You are of course right, but I think this is really a discussion about
what the term "load sharing" means. From my perspective the "load" is
all the traffic, and the etherchannel hashing "shares" this load between
several paths. It is not "fair" or "intelligent" load-sharing in the
same way as per-packet ECMP, MLPPP or actual "load balancing" is, but it
does still split the load.

I was basically trying to say that I didn't consider OoO a problem in
this context. My question was more about what the EC itself and maybe
LACP would say about it. And if it would be wise to use some specific
hashing, like staying away from L4 informations to not confuse certain
hosts. (We always use the default src-dst-ip anyway.)

We'll go through with and tomorrow evening GMT. I'll make sure to update
if we run into any problems. :-)


More information about the cisco-nsp mailing list