> ## Content Index > Fetch the complete content index at: https://www.pinglabz.com/llms.txt > Use this file to discover other available public pages before exploring further. # STP and EtherChannel: When They Collide and Who Wins - URL: https://www.pinglabz.com/etherchannel-spanning-tree/ - Published: 2026-05-23T13:00:00.000Z - Updated: 2026-08-24T00:27:55.000Z - Description: How EtherChannel hides bundled links from STP, the bundling protocols (LACP, PAgP, on), the dangerous failure modes, and why LACP active on both sides is the only safe configuration. - Author: Jaime - Tags: STP, VLAN, Fundamentals, #Import 2026-08-01 19:54 EtherChannel and Spanning Tree have a complicated relationship. The whole point of EtherChannel is to take two or more physical links and present them as a single logical link with combined bandwidth. The whole point of Spanning Tree is to block redundant links to prevent loops. By default these two technologies argue about what to do with your second cable. This post covers what happens when they collide, how the resolution actually works, and the misconfigurations that cause one or the other to win in ways you did not intend. For the cluster overview, see the [Spanning Tree Protocol pillar](https://www.pinglabz.com/spanning-tree-protocol/). For the L2 fundamentals these protocols ride on, see the [VLAN and L2 switching pillar](https://www.pinglabz.com/vlans-layer-2-switching/). ## The fundamental tension Plug two cables between two switches with no EtherChannel and no special config. STP sees two redundant paths between the same two switches. It picks one to forward on and blocks the other. The blocked link sits idle. You paid for cable and a switch port that does nothing. Now bundle the same two cables into an EtherChannel. STP no longer sees two redundant links. It sees one logical link with twice the bandwidth. Both physical links forward at the same time, with frames hashed across them based on a configurable load-balance algorithm. STP cooperates because it has nothing to block. This is the entire purpose of EtherChannel from STP's perspective. The bundling is what makes redundant links cooperate instead of one of them being blocked. ## How EtherChannel hides the physical links from STP Once a Port-channel interface is created and physical interfaces are added to it, STP runs against the Port-channel interface only. The individual physical interfaces become non-STP-participants. They forward frames based on the EtherChannel hash. They do not send their own BPDUs. They do not have their own STP state. The verification command: ``` SW1# show spanning-tree interface Port-channel1 Vlan Role Sts Cost Prio.Nbr Type ---------------- ---- --- --------- -------- -------------------------------- VLAN0001 Desg FWD 3 128.97 P2p VLAN0010 Desg FWD 3 128.97 P2p ``` Notice that the cost is 3 even though each contributing physical link might be a 1 Gbps interface (cost 4 on its own). EtherChannel adjusts the effective cost downward to reflect the combined bandwidth. Two 1G links bundled show as cost 3\. Eight 1G links bundled show as cost 1. ## The bundling protocols: LACP, PAgP, On active ProtocolLACP What it does Negotiates the bundle with the far end. Industry standard (IEEE 802.3ad). passive ProtocolLACP What it does Will form a bundle if the other side is active. desirable ProtocolPAgP What it does Cisco proprietary. Negotiates the bundle. auto ProtocolPAgP What it does Will form a bundle if the other side is desirable. on ProtocolNone What it does Forces a static bundle with no negotiation. Both sides must be "on". In modern multi-vendor environments, LACP is the only mode worth using. PAgP is Cisco-only and has been quietly deprecated. "On" mode is dangerous: it forces the bundle without verifying the other side is doing the same, and a misconfiguration creates a loop that STP cannot prevent (because STP no longer sees the individual links). A correct LACP configuration looks like: ``` interface range GigabitEthernet1/0/23 - 24 channel-group 1 mode active ! interface Port-channel1 switchport mode trunk switchport trunk allowed vlan 10,20,30 ``` Both sides set `mode active`. They negotiate, find each other, form Port-channel1\. From STP's perspective, Port-channel1 is the only thing it sees on this link. ## The collision: when the bundle does not form The dangerous moment is when you configure an EtherChannel but the bundle fails to negotiate. Reasons it fails: - One side uses LACP active, the other uses PAgP desirable. They cannot agree on a protocol. - Speed or duplex mismatch on contributing interfaces. - VLAN configuration differs across contributing interfaces (some are access, some are trunk; trunk-allowed VLAN lists do not match; native VLAN mismatch). - One side is configured for the channel-group, the other is not. When negotiation fails, the contributing interfaces are NOT in the Port-channel. They appear in show output as individual interfaces. STP sees them as redundant links, and blocks all but one. This is the safe failure mode: no loop, but no aggregation either. You end up with one active link instead of N active links, and traffic uses only that one. ``` SW1# show etherchannel summary Flags: D - down P - bundled in port-channel I - stand-alone s - suspended H - Hot-standby (LACP only) ... Number of channel-groups in use: 1 Group Port-channel Protocol Ports ------+-------------+-----------+----------------------------------------------- 1 Po1(SD) LACP Gi1/0/23(s) Gi1/0/24(s) ``` The (s) flag on the physical interfaces means "suspended" - LACP did not get an answer from the other side, so the port is not bundled. The (SD) on Port-channel1 means it is down. STP is now load-balancing across nothing. ## The more dangerous collision: "on" mode misconfiguration "On" mode skips negotiation. If both sides are "on" with matching configs, the bundle works. If one side is "on" and the other side is configured normally as two independent interfaces, the side in "on" mode believes it has a bundle. It forwards frames hashed across both interfaces. The other side does not believe it has a bundle. It sees two redundant links and blocks one. Frames hashed to the blocked link disappear. Frames hashed to the forwarding link work. Half the traffic is silently dropped. STP does not see a problem because, from its perspective, the other side is doing the right thing. This is the failure mode that ruins afternoons. The rule: never use "on" mode unless you have a specific reason and you control both ends. ## Cross-stack EtherChannel (MEC, vPC, MLAG) Modern designs often want to bundle links across two different physical switches for redundancy. The bundle members live on different chassis. STP would normally still see them as separate physical links to separate switches, but vendor stacking technologies let you present them as a single logical bundle. Multi-chassis EtherChannel (MEC) on StackWise / VSS Vendor-neutralMLAG What it is Two stacked switches present as one logical switch. Bundle can include ports from both. Virtual Port Channel (vPC) on Nexus Vendor-neutralMLAG What it is Two physically-separate Nexus switches synchronize to act as one logical peer for EtherChannel. STP still sees one switch. From a STP perspective, MEC and vPC both make the dual-chassis pair look like a single switch. STP forms one adjacency with the logical entity. The bundle protects against chassis failure as well as link failure. ## STP behavior when an EtherChannel member fails Probably the cleanest part of the whole story. When one physical link in a bundle fails: - EtherChannel removes the failed link from the load-balance hash. Remaining links pick up the load. - STP does not see anything change. The Port-channel is still up. Same role, same state. - No STP recalculation. No TC bit set. No MAC table flush. This is one of the operational advantages of EtherChannel. A single link failure inside a bundle is invisible to STP, which means it does not trigger the (small but nonzero) disruption a STP topology change normally would. ### Simulating a Member Link Failure On SW1, shut down one member of the port-channel: ```ios SW1(config)# interface Gi0/0 SW1(config-if)# shutdown SW1(config-if)# exit ``` ### Verification After Link Failure Check the EtherChannel status: ``` SW1# show etherchannel summary Group Port-channel Protocol Ports ------+-------------+-----------+----------------------------------------------- 1 Po1(SU) - Gi0/0(D) Gi0/1(P) SW1# show etherchannel 1 detail Channel group 1 : Port-channel Po1 Port-channel LACP Link State: Up Minimum number of ports to bring up the port-channel: 1 Members in this channel: Port Status ------ Gi0/0 Down Gi0/1 Up SW1# show spanning-tree vlan 10 | include Po1 Po1 Desg P2Se.128 FWD 38000 38000 10,20,30 ``` **Critical observation:** The port-channel stayed active (SU = Stand-alone Up), and the cost increased to 38000 (now operating with a single Gigabit link). STP **did not generate a topology change notification** because the port-channel itself remained operational. Bring the link back up: ```ios SW1(config)# interface Gi0/0 SW1(config-if)# no shutdown ``` The cost returns to 19000 immediately. ### Comparison: Two Single Links vs. One Port-Channel If SW1 and SW2 were connected with two independent single-link trunks instead of a port-channel: ``` SW1 ── Gi0/0 ── SW2 SW1 ── Gi0/1 ── SW2 ``` STP would treat them as separate ports. One would be designated (cost 4), the other would be blocked. When the designated link failed, STP would need to reconverge on the blocked link, causing 30–50 seconds of downtime (in 802.1D) or \~6 seconds (in Rapid PVST+). With a port-channel, the loss of one member link is **invisible to STP**. No topology change, no convergence delay. The channel degrades gracefully. ## Load balancing EtherChannel hashes frames across the bundle members. The hash algorithm is configurable. ``` port-channel load-balance src-dst-ip ! Common default port-channel load-balance src-dst-mixed-ip-port ! Better hash distribution ``` The default of src-dst-ip is fine for most environments. If you find your bundle is unbalanced (one member sees most of the traffic), the most common cause is a few high-volume flows between the same IP pair that hash to the same member. Switching to a hash that includes L4 ports usually fixes it. ## Troubleshooting Symptom → Cause → Fix ### Symptom: Port-Channel Shows "D" (Down) in EtherChannel Summary **Cause:** All member links are down, or a configuration error prevents any members from bundling. **Fix:** 1. Re-check EtherChannel status. Bring them up: ``` SW1(config)# interface range Gi0/0-1 SW1(config-if-range)# no shutdown ``` Verify member interfaces are not shut down: ``` SW1# show interfaces Gi0/0 status Port Name Status Vlan Gi0/0 shutdown routed ``` ### Symptom: One Interface Stuck in "Suspended" State **Cause:** Speed, duplex, or VLAN mismatch between the suspended link and others in the channel. **Fix:** Match configurations: ``` SW1(config)# interface Gi0/0 SW1(config-if)# speed 1000 SW1(config-if)# no shutdown ``` Check the configuration difference: ``` SW1# show interfaces Gi0/0 | include Speed Speed : 100Mb/s ``` Identify the suspended link: ``` SW1# show etherchannel 1 detail Members in this channel: Port Status ---- Gi0/0 Suspended Gi0/1 Up ``` ### Symptom: STP Topology Changes Every Few Seconds (TCN Storm) **Cause:** Port-channel members are going up and down due to flapping cables or link-level errors. **Fix:** Check cable quality; replace if necessary. Enable error logging: ``` SW1(config)# logging buffered 1000000 debug SW1(config)# logging trap debugging ``` Inspect individual member links: ``` SW1# show interfaces Gi0/0 status errors Port Errors Gi0/0 CRC: 984, Alignment: 5, Runts: 1 ``` Check for physical layer issues: ``` SW1# show interfaces Po1 | include errors Input queue drops: 0, received discards: 0, drops: 0 Transmit queue drops: 0, total drops: 0 Errors: 1247, CRC: 1200, Frame: 47, Overrun: 0, Ignored: 0 ``` ## Key takeaways EtherChannel and Spanning Tree resolve their conflict by hiding the bundled physical links from STP entirely. STP sees one logical link with adjusted cost; both members forward in parallel. The dangerous failure modes are bundling negotiation failing (mode mismatches, VLAN config differences) and "on" mode bundling without negotiation. LACP active on both sides is the only configuration that fails safely. When you put redundant links between two switches in 2026, you EtherChannel them, you use LACP, and you let STP see one logical link. For the STP cluster, see the [Spanning Tree Protocol pillar](https://www.pinglabz.com/spanning-tree-protocol/).