Root Bridge Left in a Lab Switch After a Migration
Northwind's campus has three buildings - A, B and C - each with a pair of Catalyst 9500 distribution switches and 24 Catalyst 9200 access switches. RSTP runs everywhere; MST is not used. Building C's distribution pair still holds the root bridge because a lab engineer left spanning-tree vlan 1-4094 priority 4096 on both switches three years ago. At peak, the 10 Gbps inter-building link between C and A carries 8.9 Gbps while the A–B link of the same speed idles at 1.2 Gbps. File-server response time for Building B clients is 180–420 ms; clients in C see 2–4 ms. Access-switch uplinks are lightly loaded. Last week a user looped a wall port with a patch cable: the access switch logged 4,100 MAC flaps and the Building A VLAN was unusable for 38 seconds until an engineer manually err-disabled the port. The next change window is 30 minutes long and no new hardware is approved.
1. Explain why Building B clients see 180–420 ms to the file server and why the A–B link is idle, then state the exact root-bridge priority plan you would deploy, including where Root Guard belongs. Show how you would verify the result inside the 30-minute window.
Read the worked answer
The root bridge defines the active RSTP topology, so every switch builds its shortest path toward the root, not toward the file server. With C at priority 4096, C wins the bridge-ID election (bridge ID = 2-byte priority + 6-byte MAC; the default is 32768) and the A–B link becomes an alternate path that blocks on one end. B's traffic therefore goes B → C → A and hairpins through C's 10 Gbps uplink. That explains the 8.9 Gbps load, the queueing delay and the 180–420 ms response time, while the A–B link sits at 1.2 Gbps of transit traffic.
Plan, executed in this order inside the window:
- Make the pair closest to the file server the primary root: priority 4096 on A-DIST-1 and 8192 on A-DIST-2, so the pair never ties on MAC address.
- Set B to 16384 on B-DIST-1 and 20480 on B-DIST-2, keeping it downstream of A.
- Move the current root last. Changing the priority on C triggers an election and a short topology change, so do the non-root switches first and C at the very end.
- Apply
spanning-tree guard rooton every access-facing port of all six distribution switches, so a 9200 with a stray low priority can never become root.
Verification: show spanning-tree root and show spanning-tree vlan <id> on each distribution switch. Confirm A holds the root, B's root port points at A, and the previously blocked A–B port is now forwarding. Watch show spanning-tree detail topology-change counters for five minutes, then close the window. Prepare a one-line rollback for each priority change.
2. The wall-port loop took 38 seconds to contain. Which Layer 2 edge features would have shrunk that blast radius, what exactly does each do, and why did RSTP's fast convergence not help?
Read the worked answer
RSTP converges in well under a second only when a point-to-point link fails and the proposal/agreement handshake can run. A user patch-cable loop is not a link failure: the access port stays up, so no proposal is sent, and the switch starts learning thousands of MAC addresses on two ports. That produced the 4,100 MAC flaps. The 38 seconds was a broadcast storm plus manual intervention, not a spanning-tree timer.
Features, applied at the access edge:
spanning-tree portfast edge: puts the port straight into forwarding so DHCP and PXE work. On its own it removes the accidental protection that listening/learning used to provide, so it must be paired with the next item.spanning-tree bpduguard enable: a PortFast port should never see a BPDU, so receiving one err-disables the port within seconds. This is the feature that would have contained the loop.spanning-tree guard loopon distribution root and alternate ports: blocks a port that stops receiving BPDUs instead of moving it to forwarding, covering unidirectional fibre faults.udld aggressiveon fibre uplinks for the same unidirectional condition at Layer 1.- BPDU Filter only on ports that are genuinely host-only. Applied globally it defeats BPDU Guard and is the classic mistake.
The judgement call is that PortFast without BPDU Guard makes a loop worse, not better, because the port forwards immediately and nothing err-disables it. Deploy them as a pair, and if you enable errdisable recovery cause bpduguard, use a long interval so operations can investigate before the port returns.
3. Six months later a technician installs a new Catalyst 9200 in Building B with a default configuration and an 802.1Q trunk to B-DIST-1. Compare what Root Guard and BPDU Guard would each do on that distribution port, and state which one belongs there.
Read the worked answer
With a default configuration the new 9200 has priority 32768, which is higher than B-DIST-1's 16384, so it should not become root and the topology should stay stable. The interesting case is a switch that has been pre-configured with priority 0 or 4096, which is exactly how the Building C problem started.
Root Guard on the distribution's port toward the access layer reacts only to superior BPDUs. If the new switch claims to be root, the port goes to the root-inconsistent state and stops forwarding that VLAN, protecting the rest of the tree. The port recovers automatically once superior BPDUs stop. That is the correct behaviour for a port facing downstream switches: you want the link to stay up for normal traffic.
BPDU Guard reacts to any BPDU and err-disables the port. It belongs on host-facing access ports, not on a trunk to another switch, because a legitimate switch on that port would be permanently disabled and would need manual recovery or errdisable recovery to come back.
So the trunk to B-DIST-1 gets Root Guard. The access ports underneath it get PortFast plus BPDU Guard. The distinction is the failure mode you want: root-inconsistent for a port that should carry switch traffic, err-disabled for a port that should never carry it.