Cisco · Cisco IOS XE

Cisco Spanning Tree Commands: Root, Blocking and Inconsistent Ports

Quick answer #

Use show spanning-tree summary to identify the STP mode, then inspect the affected VLAN or MST instance. A blocking or discarding port can be healthy redundancy. An unexpected root, repeated topology changes or an inconsistent state requires more context before any change is justified.

Scope: Catalyst IOS XE 17.x; command baseline: Catalyst 9200 17.15.x. The VLAN-specific workflow targets PVST+/Rapid PVST+. For MST, first resolve VLAN-to-instance mapping.

Read-only commands #

Read-only commands
Cisco IOS XE · Authorized EXEC mode; context specified below

Read-only
show spanning-tree summary
Read-only
show spanning-tree root
Read-only

Replace these example values: 120.

show spanning-tree vlan 120
Read-only

Replace these example values: 120.

show spanning-tree vlan 120 detail
Read-only

Replace these example values: GigabitEthernet1/0/24.

show spanning-tree interface GigabitEthernet1/0/24 detail
Read-only
show spanning-tree inconsistentports

MST-specific checks #

MST-specific checks
Cisco IOS XE · Authorized EXEC mode; context specified below

Read-only
show spanning-tree mst configuration
Output may contain sensitive operational data.
Read-only
show spanning-tree mst 1

Read the state in context #

The root ID identifies the elected root for the relevant instance. The root port on a non-root switch is its selected path toward that root. Port roles and forwarding states describe the resulting topology; they are not simply a good/bad classification for each cable.

Workflow #

  1. Select one affected VLAN. Confirm the running STP mode before interpreting per-VLAN output. Under MST, identify the instance containing that VLAN and use that instance throughout the investigation.
  2. Compare the observed root with the intended network design. An unexpected root is a useful finding, but it does not identify who changed the network or whether the election itself was incorrect.
  3. Trace the root-port direction across neighboring switches. Record the logical port-channel where one exists instead of treating every member as an independent STP path.
  4. Inspect details on the port associated with recent changes. Compare the timestamps with interface events and the reported service interruption.
  5. Check inconsistent ports separately. Record the exact inconsistency and inspect its cause on the neighboring device before proposing a recovery action.

Interpretation pitfalls #

Different VLANs can legitimately choose different roots and forwarding paths. One switchport may therefore forward one VLAN and block another. An MST region boundary adds another reason to avoid copying conclusions from a different instance.

A topology-change count without an observation period is weak evidence. A rising count during an incident is more informative than a large count collected across months. Even then, the port reporting a change is a place to investigate, not automatic proof that the attached device created the original fault.

Do not disable spanning tree, remove guard features or enable PortFast on an inter-switch link to make a blocked indicator disappear. First establish the intended loop-free path. Preserve the output that explains why the switch selected its current state.

  • UniFi STP blocked-port guide: For a Cisco-to-UniFi connection, inspect the other vendor's STP state too. Use that device's own commands and interface labels.

Sources

Documentation reviewed: 8 October 2026