Troubleshoot STP Issues on Cisco Catalyst Switches

Spanning Tree Protocol failures manifest in three ways: forwarding loops that saturate links, excessive flooding driven by topology changes, and slow convergence. All three can be traced back to the same root causes — BPDU loss, duplex mismatches, or unidirectional links — but finding the exact spot takes a methodical approach. This article distills Cisco's official troubleshooting guide for Catalyst switches into an actionable sequence: identify the loop, discover its scope, break it, and harden the network so it never happens again.

How Spanning Tree Should Behave

Troubleshooting STP is much easier when you know exactly what "normal" looks like. In 802.1D or PVST+, every VLAN elects one root bridge: the switch with the lowest bridge ID, which is a 16-bit priority (default 32768) followed by the base MAC address. Each non-root switch then picks one root port - the lowest-cost path toward the root - and one designated port per segment; every other port is blocking. Costs are media-dependent (10 Mbps = 100, 100 Mbps = 19, 1 Gbps = 4, 10 Gbps = 2 in the traditional short mode), so a single mis-cabled gigabit link can pull the topology in an unintended direction.

Convergence after a change runs on three timers: hello 2 seconds, max age 20 seconds and forward delay 15 seconds. A port moves blocking → listening → learning → forwarding, which is why classic STP takes roughly 30-50 seconds to open a path. Rapid PVST+ (802.1w) replaces the timers with a proposal/agreement handshake and reduces the states to discarding, learning and forwarding, converging in a second or two for the usual cases. MST (802.1s) maps groups of VLANs to instances and runs RSTP per instance - but it is only consistent if every switch in the region shares exactly the same region name, revision number and VLAN-to-instance mapping.

Whatever the variant, the invariant is the same: each segment must have exactly one designated port, and every BPDU must be received on the port STP thinks should receive it. A loop appears the moment a bridge stops believing the truth about the topology - because BPDUs stopped arriving, because it never saw them in the first place, or because it was told not to listen.

Recognizing the Failure Modes

A forwarding loop congests the lowest-bandwidth links on the path and eventually takes down the whole L2 domain. Excessive flooding is subtler: slow links clog up with flooded traffic and users behind them see slowness or total loss of connectivity. Both usually come from one bridge failing to receive or process BPDUs — which means it no longer knows the correct topology and stops blocking the redundant port.

Alongside the two headline symptoms you will see a recognisable set of by-products:

• MAC address flapping - the same MAC is learned on two or more ports in quick succession because its frames are arriving from both sides of the loop.
• Control-plane CPU spikes - a topology-change storm and endless BPDU processing push the switch's CPU toward saturation, and management access becomes slow or impossible.
• Err-disable events - BPDU Guard, loop guard and UDLD may already be firing and shutting ports down, which is good news: the protection worked, and the err-disable reason tells you where to look.
• Late-night, intermittent outages - a loop that only appears when a specific conference-room port is used, or when a link goes half-duplex under load.

One more candidate deserves a place on the list even though it is not an STP failure: a broadcast storm from a single source (a failing NIC or a misconfigured server) produces the same saturated links. Storm control and the MAC table distinguish the two.

Identify the Loop

Look for ports with abnormally high utilization. The show interface command displays packets-per-second utilization; on Supervisor 2+ Catalyst 6500s, show interfaces | include L2|line|broadcast pinpoints the VLAN with the highest switched-packet count — usually the VLAN where the loop lives.

Widen the search with a small set of evidence-gathering commands. Run them in this order and the loop usually identifies itself in under two minutes:

Switch# show interfaces | include is up|line protocol|rate
Switch# show interfaces counters errors
Switch# show mac address-table | include Gi1/0/1
Switch# show spanning-tree summary
Switch# show spanning-tree detail | include VLAN|topology|from
Switch# show processes cpu sorted | exclude 0.00

The first command shows which interfaces are running flat out at line rate - a loop almost always saturates one link rather than silently misusing capacity. The second exposes CRC errors, late collisions and runts, which point at a duplex or cabling fault rather than STP. The third reveals the classic loop signature: if a single MAC appears on multiple ports, frames are circulating. show spanning-tree detail prints the topology-change counters per VLAN; a VLAN whose change counter is climbing every few seconds is where the instability lives, and the "from <port>" field names the port that sent the last notification. Finally, a CPU graph pinned near 100 percent on one of three processes confirms the flooding is being processed, not just forwarded in hardware.

Break the Loop, Then Find the Cause

1. Shut down or disconnect the ports involved — restore connectivity first, investigate second.
2. Verify the STP root is consistent — all switches must agree on the root bridge. show spanning-tree vlan <vlan-id> reveals the root bridge ID; differing roots in the same VLAN are a clear red flag.
3. Check BPDU reception — on root and blocked ports, confirm BPDUs arrive periodically with show spanning-tree interface <int> detail. If receive counters do not climb, check show interface <int> counters for multicast reception and errors.
4. Check for duplex mismatch — a half-duplex bridge that cannot transmit BPDUs will unblock a port and create a loop.

Steps 3 and 4 deserve more detail, because BPDU loss and duplex problems account for most real-world STP loops.

Diagnosing BPDU Loss and Unidirectional Links

A blocked port that stops receiving BPDUs has no way to know whether the neighbour died or the path broke - after max age expires it moves to listening and forwarding, and if the other end is still forwarding, you have a loop. Loop Guard was designed for exactly this: spanning-tree guard loop on root and alternate ports keeps a port in the blocking state when BPDUs stop without a link-down event. On the same physical failure, UDLD works one layer lower and shuts the link down entirely. The split of responsibility is worth memorising: loop guard protects against STP BPDU loss, UDLD against a physically unidirectional link. Loop guard and root guard cannot both be enabled on the same port, and loop guard must not be used on PortFast ports.

Duplex mismatch is the other classic. A link forced to full duplex at one end and auto-negotiated to half duplex at the other still passes traffic well enough to look healthy, but the half-duplex side cannot reliably transmit BPDUs under load, and late collisions climb. Verify both ends:

Switch# show interfaces GigabitEthernet1/0/24 | include duplex|speed|error
Switch# show interfaces counters errors
Switch# show spanning-tree interface GigabitEthernet1/0/24 detail

Look for a mismatch between "Full-duplex, 1000Mb/s" on one switch and "Half-duplex, 100Mb/s" on the other, plus growing late collisions and FCS errors. The fix is to return both ends to auto-negotiation, or hard-code both ends identically - never one of each.

BPDU reception itself should be verified explicitly on ports where STP depends on it. show spanning-tree interface <int> detail prints BPDUs sent and received counters; if the receive counter is not incrementing on a designated port, work the problem as a Layer 2 delivery failure - check the cable, the SFP, the upstream port's VLAN membership, and whether a BPDU filter or a misconfigured edge feature is suppressing the frames at the other end.

Harden the Network Against Loops

• UDLD and Loop Guard eliminate most loop causes by shutting down defective links instead of forwarding on them.
• PortFast on end-station ports — always paired with BPDU Guard so a rogue switch cannot inject BPDUs.
• Root Guard prevents ports from becoming root ports.
• Keep user traffic off the management VLAN — broadcast storms on the management VLAN can overload the CPU and distort STP operation.

Stop the Blast Radius: Storm Control and Errdisable Recovery

You will never prevent every loop, so make sure a loop cannot take the whole site down while you investigate. Storm control on access ports caps broadcast, multicast or unknown-unicast traffic at a percentage of link bandwidth or an absolute packet rate, and can either simply log or shut the port down:

Switch(config-if)# storm-control broadcast level 5
Switch(config-if)# storm-control multicast level 5
Switch(config-if)# storm-control action shutdown
Switch(config)# errdisable recovery cause bpduguard
Switch(config)# errdisable recovery cause psecure-violation
Switch(config)# errdisable recovery interval 300

Remember that an err-disabled port stays down until somebody clears it, unless recovery is configured. show errdisable recovery lists which causes will auto-recover, and show interfaces status err-disabled lists the ports that are currently down, with the reason. Auto-recovery is convenient but should be slowed down (300 seconds is a reasonable start) so that a device that keeps re-creating the loop does not flap the network.

Reference Configuration for a Hardened Access Switch

This template ties the individual features together. It assumes Rapid PVST+ and a two-switch core, with the access switch pinned away from the root role:

Switch# configure terminal
Switch(config)# spanning-tree mode rapid-pvst
Switch(config)# spanning-tree portfast default
Switch(config)# spanning-tree portfast bpduguard default
Switch(config)# spanning-tree loopguard default
Switch(config)# spanning-tree vlan 10,20,30,99 priority 4096
Switch(config)# interface range GigabitEthernet1/0/1 - 40
Switch(config-if-range)# switchport mode access
Switch(config-if-range)# spanning-tree portfast
Switch(config-if-range)# spanning-tree bpduguard enable
Switch(config-if-range)# storm-control broadcast level 5
Switch(config-if-range)# storm-control action shutdown
Switch(config-if-range)# no shutdown
Switch(config)# interface GigabitEthernet1/0/48
Switch(config-if)# switchport mode trunk
Switch(config-if)# spanning-tree guard root
Switch(config-if)# udld port aggressive
Switch(config)# errdisable recovery cause bpduguard
Switch(config)# errdisable recovery interval 300
Switch# end
Switch# copy running-config startup-config

Two cautions. Do not enable global BPDU filtering to "quiet" a flapping port - filtering BPDUs can hide the very topology information STP needs and create the loop you were trying to prevent. And apply udld port aggressive only on switch-to-switch links, where both ends understand it; on host-facing ports it adds nothing.

Worked Example: One Wall Port Takes Down the VLAN

A floor reports intermittent slowness that clears by itself. On the access switch, show interfaces counters errors shows one port with climbing late collisions, and show spanning-tree detail shows the topology-change counter for the user VLAN rising every few seconds while nothing is being patched. show mac address-table then shows several MACs appearing alternately on the offending port and on the uplink.

The cause is a small unmanaged switch under a desk, plugged into two different wall ports - a physical loop with no STP of its own. Both access ports are PortFast edge ports, so they never blocked; depending on the configuration, either BPDU Guard shut one of them down (visible as an err-disabled port with reason bpduguard, and the network self-healed), or the loop persisted. The permanent fix is the template above: PortFast plus BPDU Guard on every user port, storm control as a backstop, and a documented policy that desk switches are not permitted - with port security or 802.1X to enforce it.

STP Troubleshooting FAQ

Should I hardcode the root bridge by priority or with root primary? For a two-switch core, spanning-tree vlan 10 root primary and root secondary are simple and self-documenting. The macro sets priority 24576 and 28672 respectively. Explicit priorities are more predictable when more than two candidate roots exist.

Why does STP take 30 seconds to recover after a link failure? Because classic 802.1D relies on the max age (20s) plus forward delay (15s) timers. Migrating to Rapid PVST+ or MST removes most of that delay. If you still see 30-second outages with RSTP, a port is probably in a PortFast-less access role and is going through the full state machine.

Do I need BPDU Guard if I have PortFast? Yes. PortFast only skips the listening/learning phase; it does not stop a rogue switch from sending superior BPDUs and taking over the topology. The two features are designed as a pair.

Can I just disable STP on the access ports? No. Disabling STP on individual VLANs or ports is how you convert a redundant design into a self-destructing one at the first accidental patch. Fix the root placement and the edge configuration instead.

What does "inconsistent ports" mean? show spanning-tree inconsistentports lists ports held in a non-forwarding state because of a loop guard or root guard violation. It is the fastest way to confirm that a protective feature - not a hardware fault - is keeping a port down.

Root placement and priority design are covered end to end in Spanning tree root bridge election and design rules, and the edge-port equivalent on Arista hardware is in Arista EOS Spanning-Tree PortFast and BPDU Guard setup. If the same VLANs are mapped to MST instances, check Cisco MST configuration: region, instance and VLAN mapping before blaming the topology.

For the complete command reference used in this workflow, see 思科交换机排障命令手册, and compare the MAC-level symptoms in Cisco IOS XR Input Drops 排障.

原文链接：https://www.cisco.com/c/en/us/support/docs/lan-switching/spanning-tree-protocol/28943-170.html