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. For the L2 fundamentals these protocols ride on, see the VLAN and L2 switching pillar.
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 P2pNotice 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
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,30Both 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.
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:
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:
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 distributionThe 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:
- 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.