3.2Troubleshooting EtherChannel

EtherChannel bundles bandwidth and, just as importantly, presents a single logical link to spanning tree so redundant links can be fully used instead of blocked. Yet the most common field problem is "every cable is plugged in but only one link joined the bundle" or "the port went suspended," and the cause is almost always a configuration disagreement between the two ends. This section organizes the conditions for bundling along two axes—protocol negotiation and matching physical/logical parameters—so you can read the flags in show etherchannel summary and instantly tell which axis failed.

3.2.1LACP, PAgP, and on mode combinations

• LACP (Link Aggregation Control Protocol) is the IEEE 802.3ad standard, so it bundles with third-party gear. Its modes are channel-group 1 mode active (actively initiates negotiation) and mode passive (only responds). By the same principle as DTP, passive+passive never bundles. In multi-vendor environments it is effectively the only choice.
• PAgP (Port Aggregation Protocol) is Cisco-proprietary with modes mode desirable (active) and mode auto (passive), and again auto+auto never bundles. LACP and PAgP are not interoperable, so pairing LACP on one side with PAgP on the other fails to negotiate and no bundle forms.
• mode on is static (no negotiation) and bundles correctly only when the far end is also on. The dangerous combination is on on one side and active/desirable on the other: the on side starts forwarding immediately without negotiating while the peer refuses the bundle, so STP cannot see a single logical link and a physical loop or MAC flapping results. The instinct that "setting it to on is the sure way" causes the most incidents.

3.2.2Bundling conditions (parameter consistency)

• Even after negotiation succeeds, a member port drops out of the bundle if its parameters do not match. Speed, duplex, switchport mode (access or trunk), the trunk allowed VLAN list, native VLAN, access VLAN, and STP port cost/priority must all agree. A trivial difference—one link auto-negotiating to 100 Mbps—is enough to be excluded.
• Ordering also causes incidents: convention is to align member-port settings first and only then apply channel-group. Settings added later under interface port-channel 1 are inherited by member ports in some cases but not others, so always verify the member side with show running-config interface.
• Read the state from the flags in show etherchannel summary: P = bundled, I = stand-alone (no negotiating peer), s = suspended (LACP is being received but the port is held back, e.g. by a parameter mismatch), D = down, and H = hot-standby (LACP allows at most 8 active links, so the ninth and beyond wait). The Port-channel itself should read SU (L2, in use).

3.2.3Load-balancing imbalance

• EtherChannel distributes by a hash that picks a member link per flow, and a single flow is never split across links (to prevent packet reordering). So "bundling four 10 Gbps links gives one flow 40 Gbps" is wrong—a single flow is capped at one physical link.
• The hash input is chosen with port-channel load-balance (src-mac, dst-mac, src-dst-mac, src-ip, dst-ip, src-dst-ip, src-dst-port, and so on). If the chosen field has little variety, distribution is skewed—for example, choosing dst-mac where servers all communicate through a single router (one MAC) concentrates every flow on the same link.

Suppose you build an EtherChannel of four gigabit links between core switch CSW1 and distribution switch DSW1, but you do not get the expected 4 Gbps and monitoring shows only one link in use. On CSW1, show etherchannel summary shows Po1 as SU, with Gi1/0/1 (P), Gi1/0/2 and Gi1/0/3 (s), and Gi1/0/4 (I). Each flag has a different cause, so lumping them together as "a config mistake" will not resolve it. First, (I) stand-alone on Gi1/0/4 means it has never received an LACP negotiation packet. Most likely the far-end Gi1/0/4 has no channel-group, the cable landed on a different port, or the peer is set to on (no negotiation); confirm the physical mapping with the peer's show running-config interface and show cdp neighbors. Next, the two (s) suspended links mean LACP is being received (so the peer is configured in a negotiating mode) but the bundling conditions do not match. Suspects here are speed/duplex mismatch, one side access and the other trunk, or a difference in the trunk allowed VLAN list or native VLAN. Checking reveals that switchport trunk allowed vlan on Gi1/0/2 and Gi1/0/3 differs from Gi1/0/1: a recently added VLAN was applied to only two of the links. Thinking "they are suspended, so mode on will force them into the bundle" is the worst possible response, because forwarding begins with the mismatch still present, STP cannot treat the group as one logical link, and MAC flapping or a loop follows. The correct procedure is to make all four member ports identical first, then re-apply channel-group if needed. After aligning them, re-run show etherchannel summary to confirm every member reads (P), then inspect the hash input with show etherchannel load-balance. If every member is (P) yet traffic is still skewed, that is no longer a bundling problem but a hash-input (flow diversity) problem, and you would consider switching to a more distributive input such as src-dst-ip.

3.2.4Section summary

• LACP (active/passive, standard) and PAgP (desirable/auto, Cisco) are not interoperable, and two passive ends never bundle; on does not negotiate, and on on only one side risks a loop
• Even after negotiation, a member drops out as (s) suspended when speed, duplex, trunk mode, allowed VLANs, or native VLAN differ
• (I) = no negotiating peer, (s) = condition mismatch, (P) = healthy; distribution is a per-flow hash and one flow is capped at a single physical link