[lkml]   [1999]   [Apr]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: fast EtherChannel support?
Glen Turner wrote:
> The EtherChannel encoding is:
> > Our algorithm (currently) is
> > (destination_ethernet_address AND 000.0000.0003) XOR
> > (source_ethernet_address AND 0000.0000.0003)
> You then round-robin the resulting eight values through
> however many ports are in the channel.

From what I can tell from Sun's Trunking manual, and working with the
software, it doesn't ever really round robin the packets..

Your ethernet address determines which channel of the bundle you use;
and you get stuck with it.

No real load balancing there..

> Again, you don't need this protocol to do enough
> output hashing to interoperate. Linux could establish
> its own hashing scheme and happily co-work with
> EtherChannel switches. It's just that the port allocation
> on the switch needs to be done manually. Not a big deal.

This works.

I know; I'm doing it today. I've sent the bonding patch for 2.2 to
Alan; some comments and changes will probably occur (but not for at
least a week; I'm headed out for a few days..)

The network support people prefer to setup the channel by manually; they
don't trust the auto detect code.

Thomas Davis | PDSF Project Leader |
(510) 486-4524 | "Only a petabyte of data this year?"

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:51    [W:0.026 / U:7.156 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site