Etherchannel configuration may seem simple. Even so, it’s a good idea to plan out your configuration before starting. Here are a few ideas that you may not have thought of.

Whenever possible, try to use dynamic negotiation. This means enabling either LACP or PAgP. This is for detecting link failures, and moving traffic flows to alternate links. More devices support LACP than PAgP, so use LACP when possible.

LACP etherchannels can be active or passive. PAgP uses the names desirable and auto, which are basically the same thing. If either end of the channel is set to active, the etherchannel will form. If both sides are passive, the channel will not form.

To shave a few milliseconds off the time it takes to bring the link up, set one end as active and one end as passive. This reduces the number of LACP PDU’s.

There will never be perfect traffic distribution through a bundle of links. For example, 8x 1Gbps links does not equal 8Gbps of bandwidth.

Even so, you can improve distribution by tuning the hashing method. To do this, you will need to understand the flow of traffic across the etherchannel.

Imagine an connecting an etherchannel to a single host with a single IP. Basing the hashing method on destination IP or MAC will not be particularly useful. In this case, it will pin a lot of traffic to a single link. In most cases, the best practice is to use both source and destination IP address. Add the source and destination port as well, to generate the highest number of unique hashes.

Choose the number of links in an etherchannel, with a ‘base-2’ system. For example, 2¹ (2 links), 2² (4 links), 2³ (8 links). This allows optimal distribution of traffic across the links.

When there is a failure of a link in a bundle, the following process happens:

1. LACP or PAgP detects the failure
2. The link is removed from the etherchannel
3. The indexes (hashes) are updated. This re-allocates traffic from the lost link to other links
4. Spanning-tree and routing protocols are notified of the change

An etherchannel will converge faster than a routing protocol. This makes it a good choice for uplinks in some cases, rather than routed paths. The exception here is ECMP. Losing a link when there is ECMP does not cause a re-convergence event.

Other control plane protocols, (spanning-tree, EIGRP, and so on) cannot ‘see’ the links in a bundle. They will only see a single logical link. What can happen though, is the change in links can change the cost of the logical link. This may cause re-convergence, to choose a better path.

One way to handle this is to assign costs on the port-channel. The problem with this, is that the etherchannel may lose several links, and end up being very slow. In this case, consider using the minimum-links command on the etherchannel.

Minimum-links determines that a certain number of links must be up for the port-channel to be up. If the number of active links drops below this value, the entire port-channel will go down. This will cause the control-plane protocol to look for a better path.

Etherchannel is useful in any layer of the network. Routed etherchannels may be used between the core and distribution layers. The distribution and access layers may use switched or routed etherchannels, depending on the network design.Optimize further by deploying VSS in the distribution layer. Compliment this with stacking in the access layer. When using modular switches, connect the links to different line cards. This adds redundancy, as a line-card failure won’t bring the port-channel down. The same principle applies to switches in a stack.Before adding links into a port channel, configure them with the same settings. That is, make sure they have the same link-speed and duplex settings. Also make sure they have the same native VLAN and allowed VLAN list. This is to prevent a mismatch, which could prevent the port-channel coming up. Or worse, it could cause unexpected issues later.