I’ve done it.  You’ve done it.  We’ve all done it.  You turn up another EtherChannel bundle and realize the hard way that your interface descriptions aren’t accurate.  Or you’ve swapped out a piece-of-crap 3750 and didn’t notice that the labels on the cables were wrong.  In either case, we all know that EtherChannel bundles don’t really work if the links aren’t plugged into the right switches.

So, what do you to make sure that your links are cabled the way you think they are?  Personally, I don’t trust any label at all - no matter if I did it or not.  At some point, someone has changed something on a switch, and that just might have been a change to where the port is question is cabled.  If I was onsite, I would hand-trace the cabling from one end to the other then do it again to make sure I didn’t hose it up the first time.  The big problem with this technique is that I’m not everywhere at the same time, and the travel budget isn’t very big these days.  If I can’t get my hands on the cables, I relegate myself to using CDP to see what’s on the other end of links when putting ports into EtherChannel bundles.

I was doing some STP labs tonight and found something that caught me off guard a bit.  I had been meddling with some EtherChannels between a pair of 3750s earlier today, and I forgot to reset the configs before starting on the STP stuff.  One my secondary root switch, I ran a show spanning-tree vlan 1 to see what status the ports were in, and I noticed the root path cost.

EtherChannel lets you aggregate links into one logical connection, but the distribution of traffic is not uniform.  It does not use per-packet load-balancing or the like to determine what interface in the bundle to use.  Instead, it uses a XOR function on packet information to generate a hash that is used to determine what interface to use.

By default, the switch will use both the source and destination IP addresses to generate the hash, but there are lots of others.

Have you even noticed that your new servers all have 2 NICs on the board?  At least all of them that I’ve seen in the last 3 years have.  A lot of server admin actually use them in a NIC teaming scenario where both NICs are used as one logical device – much the same as Etherchannel on a switch.  This provides some fault tolerance and availability in case of failure, which is good idea in most cases.