2.1.e Implement and Troubleshoot EtherChannel

2.1.e Implement and Troubleshoot EtherChannel

 

Etherchannel, port-channel, team, LAG, and in vendor neutral groups (trunk) all refer to the static or negotiated bundling of links.

Etherchannels provide at the heart provide us link redundancy. If a link fails it’s automatically removed from the etherchannel.

When we configure an etherchannel we group links into a channel-group, and then from there we are created a port-channel interface.
The goal of this is to present one “interface” to upper layer protocols such that they just see a bigger interface with more bandwidth and they can continue working as normally.
For example this presents spanning tree one interface thus it doesn’t need to block all of the members.

Etherchannels are also much cheaper than buying interfaces or upgrading switches to support higher bandwidth for certain connections.
Etherchannels of course add redundancy.

The only downside to etherchannels are that 1 FLOW (as load balanced by CEF) cannot exceed the bandwidth of a link. Thus you will only realize the multiple links’ speed when you have multiple flows traversing the etherchannel.

You should know you should not mix optic type like copper or fiber in a etherchannel
Also an etherchannel requires interfaces of the same speed or else we would have out of order packets.
In general the interfaces should have the same config or else the etherchannel will fail.

Leave a comment

Exit mobile version