STP and EtherChannel: When They Collide and Who Wins

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   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

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.

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.

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.

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.