Spanning TreeCCNA 200-301

Continuous STP Topology Changes Causing Network Instability

Presenting Symptom

Users in VLAN 10 experience intermittent connectivity drops and slow network performance, while the switch logs show repeated STP topology change notifications every few seconds.

Network Context

A small branch office network with three Cisco Catalyst 2960 switches (SW1, SW2, SW3) running IOS 15.0. SW1 is the root bridge for all VLANs. The switches are interconnected via trunk links, and each switch has access ports in VLAN 10 for end-user devices. The network uses Rapid PVST+ as the STP variant.

Diagnostic Steps

Check STP status on all switches

show spanning-tree vlan 10

VLAN0010
  Spanning tree enabled protocol rstp
  Root ID    Priority    32778
             Address     0001.1111.1111
             This bridge is the root
             Hello Time   2 sec  Max Age 20 sec  Forward Delay 15 sec

  Bridge ID  Priority    32778  (priority 32768 sys-id-ext 10)
             Address     0001.1111.1111
             Hello Time   2 sec  Max Age 20 sec  Forward Delay 15 sec
             Aging Time  300 sec

Interface           Role Sts Cost      Prio.Nbr Type
------------------- ---- --- --------- -------- --------------------------------
Gi0/1               Desg FWD 4         128.1    P2p
Gi0/2               Desg FWD 4         128.2    P2p

Number of topology changes: 1523 last change occurred: 00:00:05 ago
          Timer: hold 1, topology change count 1523
          Port: Gi0/1 not blocked
          Port: Gi0/2 not blocked

The high topology change count (1523) and the short time since the last change (5 seconds) indicate frequent topology changes. This is abnormal; a stable network should have very few changes. The root bridge shows all ports as designated forwarding, which is expected for the root.

Identify which ports are causing topology changes

show spanning-tree vlan 10 detail | include Topology|from

SW1# show spanning-tree vlan 10 detail | include Topology|from
  Number of topology changes: 1523 last change occurred: 00:00:05 ago
        from GigabitEthernet0/1
  Number of topology changes: 1523 last change occurred: 00:00:05 ago
        from GigabitEthernet0/2

The output shows that topology changes are being triggered from both trunk ports (Gi0/1 and Gi0/2). This suggests that the cause is not a single flapping access port but rather a recurring event on the trunk links themselves or on downstream switches.

Check for port flapping on trunk links

GigabitEthernet0/1 is up, line protocol is up (connected)
  Last input 00:00:01, output 00:00:00, output hang never
  Input errors: 0, CRC: 0, Frame: 0, overrun: 0, ignored: 0

The trunk link appears stable with no input errors or CRC errors. This rules out physical layer issues on the trunk. The problem is likely not due to a flapping link but rather a configuration issue causing STP to perceive a topology change.

Examine STP port roles and states on non-root switches

show spanning-tree vlan 10

VLAN0010
  Spanning tree enabled protocol rstp
  Root ID    Priority    32778
             Address     0001.1111.1111
             Cost        4
             Port        1 (GigabitEthernet0/1)
             Hello Time   2 sec  Max Age 20 sec  Forward Delay 15 sec

  Bridge ID  Priority    32778  (priority 32768 sys-id-ext 10)
             Address     0002.2222.2222
             Hello Time   2 sec  Max Age 20 sec  Forward Delay 15 sec
             Aging Time  300 sec

Interface           Role Sts Cost      Prio.Nbr Type
------------------- ---- --- --------- -------- --------------------------------
Gi0/1               Root FWD 4         128.1    P2p
Gi0/2               Altn BLK 4         128.2    P2p

Number of topology changes: 1523 last change occurred: 00:00:05 ago
          Timer: hold 1, topology change count 1523
          Port: Gi0/1 not blocked
          Port: Gi0/2 not blocked

On a non-root switch, the root port (Gi0/1) is forwarding and the alternate port (Gi0/2) is blocking, which is normal. However, the topology change count is also high here, indicating that the topology change notifications are being propagated. The cause is likely on the root bridge or a misconfiguration that triggers TCNs.

Check for PortFast and BPDUguard on access ports

show running-config interface gigabitEthernet 0/3

interface GigabitEthernet0/3
 switchport mode access
 switchport access vlan 10
 spanning-tree portfast
 spanning-tree bpduguard enable

If PortFast is enabled on an access port that is connected to a switch (instead of an end device), it could cause a loop and trigger topology changes. However, here PortFast and BPDUguard are correctly configured for an access port. The issue might be that PortFast is missing on some access ports, causing unnecessary TCNs when a host connects/disconnects.

Monitor STP events in real time

debug spanning-tree events

SW1# debug spanning-tree events
Spanning Tree event debugging is on
SW1#
*Mar  1 00:00:10.123: STP: VLAN0010 new root port Gi0/1, cost 4
*Mar  1 00:00:10.125: STP: VLAN0010 topology change detected on Gi0/1
*Mar  1 00:00:10.127: STP: VLAN0010 sent topology change notification on Gi0/2
*Mar  1 00:00:15.456: STP: VLAN0010 topology change detected on Gi0/2
*Mar  1 00:00:15.458: STP: VLAN0010 sent topology change notification on Gi0/1

The debug output shows that topology changes are being detected on both trunk ports alternately. This pattern suggests that the root bridge is receiving TCNs from both directions, possibly due to a loop or a misconfiguration causing the root bridge to change its root port. However, the root bridge should not have a root port; it should be the root. This indicates that the root bridge might be receiving superior BPDUs, meaning another switch is claiming to be the root. This could be due to a switch with a lower bridge priority or a BPDU attack.

Root Cause

A rogue switch (or a misconfigured switch) with a lower bridge priority (e.g., priority 4096) has been connected to the network, causing the root bridge to change frequently. The new switch sends superior BPDUs, forcing the original root bridge to recalculate its root port and propagate topology changes. This results in continuous STP topology changes, leading to network instability and intermittent connectivity.

Resolution

1. Identify the rogue switch by checking the MAC address of the claimed root bridge from the 'show spanning-tree' output on the original root bridge. 2. Remove the rogue switch from the network or correct its bridge priority. 3. On the intended root bridge, set a lower bridge priority to ensure it remains the root: SW1(config)# spanning-tree vlan 10 priority 4096 4. Optionally, enable BPDU guard on all access ports to prevent unauthorized switches from affecting STP: SW1(config)# interface range gigabitEthernet 0/3-24 SW1(config-if-range)# spanning-tree bpduguard enable 5. Clear the STP topology change counters to verify stability: SW1# clear spanning-tree counters

Verification

1. Run 'show spanning-tree vlan 10' on the original root bridge. Verify that the root bridge is now the intended switch (priority 4096) and that the topology change count is no longer incrementing rapidly. Expected output: Root ID priority 4096, topology change count stable (e.g., 5 after 10 minutes). 2. Check that all ports are in appropriate roles (root port on non-root switches, designated on root). 3. Verify that no TCNs are being sent by monitoring 'debug spanning-tree events' for a few minutes; no new topology change messages should appear.

Prevention

1. Always configure a designated root bridge with a low priority (e.g., 4096) and a secondary root bridge with a slightly higher priority (e.g., 8192) to ensure deterministic root selection. 2. Enable BPDU guard on all access ports to prevent unauthorized switches from connecting and affecting STP. 3. Use PortFast on all access ports connected to end devices to reduce unnecessary topology changes when devices are powered on/off.

CCNA Exam Relevance

On the CCNA 200-301 exam, this scenario tests your ability to troubleshoot STP stability issues. Expect multiple-choice questions asking you to identify the cause of frequent topology changes, or drag-and-drop tasks to order troubleshooting steps. Key facts: STP topology changes are triggered when a port transitions to forwarding or blocking; a high topology change count indicates instability; BPDU guard and PortFast help prevent unnecessary TCNs.

Exam Tips

Memorize that a high 'topology change count' in 'show spanning-tree' indicates instability; the root cause is often a flapping link, a new switch with lower priority, or missing PortFast on access ports.

Remember that BPDU guard err-disables a port if a BPDU is received; this is a common exam topic for preventing rogue switches.

Know that 'debug spanning-tree events' is a powerful tool to see TCNs in real time, but use it carefully in production.

Commands Used in This Scenario

debug spanning-tree events

Enables debugging of Spanning Tree Protocol (STP) state transitions and topology change events to troubleshoot STP convergence issues.

show interfaces

Displays detailed status and statistics for all interfaces or a specific interface, used to verify interface operational state, errors, and performance.

show spanning-tree

Displays the Spanning Tree Protocol (STP) state and configuration for all VLANs or a specific VLAN, used to verify root bridge, port roles, and STP topology.

Test Your CCNA Knowledge

Practice with scenario-based questions to prepare for the CCNA 200-301 exam.

Practice CCNA Questions