Root Bridge and Topology Changes on a Three-Switch Campus
Three switches run rapid PVST+. SW1 is the collapsed core: it holds the SVI and default gateway for every VLAN. SW2 and SW3 are access switches; SW2 links to SW1 and to SW3, and SW3 also links to SW1. Every link is Gigabit Ethernet, so the STP cost is 4. Someone applied spanning-tree vlan 1-100 priority 4096 to SW2 to "make spanning tree converge faster"; SW1 was left at the default. Users on SW3 say reaching the gateway feels slower than at the old single-switch site. Separately, the whole campus pauses for two to five seconds whenever anyone plugs a laptop into a wall port: on SW1, show spanning-tree detail shows the topology-change count climbing by hundreds per hour with the TC-while timer almost permanently running. No access port has PortFast enabled.
1. Which switch is root, why is that the wrong switch, and what configuration makes SW1 root with SW2 as deterministic backup? Note the trap with the `root primary` macro.
Read the worked answer
SW2 is root, because 4096 beats SW1's default 32768.
That is the wrong outcome because the root bridge decides the shape of the whole tree. It should be the switch closest to the Layer 3 gateway, so inter-VLAN and off-site traffic takes the shortest Layer 2 path. With SW2 as root, SW3's traffic to the SW1 SVI runs SW3 to SW2 to SW1 instead of the direct link: it costs an extra hop and loads the SW2-SW3 link, while the SW1-SW3 link ends up blocking. You are paying for a link you are not using.
SW1(config)# spanning-tree vlan 1-100 priority 4096
SW2(config)# spanning-tree vlan 1-100 priority 8192
Priorities must be multiples of 4096, lower wins, and a tie is broken by MAC address.
The root primary trap: it is a macro, not a fixed value. It typically selects 24576, and if a lower priority already exists in the network it decrements from that instead, so the resulting number depends on the current topology and changes when someone else changes theirs. It is not reproducible across sites and cannot be audited from a config template. Explicit numbers give you a stated primary and secondary. Either way, verify with show spanning-tree root and show spanning-tree vlan 10 afterwards instead of assuming, and expect a brief reconvergence when the priority changes.
2. Explain the campus-wide pauses and give the fix, including what you must not enable PortFast on.
Read the worked answer
Cause: unconstrained topology-change notifications.
Every time an access-port link changes state, the switch sends a topology-change BPDU toward the root, which floods it to every switch. Each switch responds by shortening MAC address aging and flooding unknown unicast until the tables refill. With dozens of laptops per hour, the tables never stabilise, so the entire campus sees periodic flooding and a stall of a few seconds. It is not a bandwidth problem and not a hardware fault.
SW1(config)# spanning-tree portfast default
SW1(config)# spanning-tree bpduguard default
or per interface, spanning-tree portfast plus spanning-tree bpduguard enable. PortFast tells STP the port is an edge port: it goes straight to forwarding and, critically, does not generate TCNs when it toggles.
Never on:
- switch-to-switch links (SW1-SW2, SW1-SW3, SW2-SW3)
- ports facing hubs, unmanaged switches, or anything that can forward BPDUs
A PortFast uplink skips the listening/learning delay before BPDU processing catches up, which can allow a temporary loop; and BPDU Guard on an uplink would err-disable the uplink and cut off every downstream user. BPDU Guard belongs on edge ports precisely so that a loop-creating device plugged into a wall port is err-disabled instead of looped.
Verify: the topology-change counter in show spanning-tree detail should stop climbing, and show spanning-tree interface should show the access ports as edge.
3. With SW1 as root, which link carries SW3's gateway traffic, and which end of the SW2-SW3 link ends up discarding? Would you fix this with priority or with port cost?
Read the worked answer
Path after re-rooting:
- SW3 has two routes to the root: the direct Gigabit link (cost 4) and the path via SW2 (4 + 4 = 8). It elects the direct link as its root port, so gateway traffic is now one hop instead of two.
- SW2's root port is its link to SW1 (cost 4).
The SW2-SW3 segment: each end has a path cost of 4 to the root, so the designated-port election ties on cost and breaks on bridge ID: the switch with the lower bridge ID keeps its end designated and forwarding, and the other end goes to discarding. Which switch that is depends on the bridge IDs, so read it from show spanning-tree vlan 10 on both switches rather than assuming it is SW3. Note that after re-rooting, the previously blocked SW1-SW3 link becomes forwarding, so the blocked point moves from the core link to the access-to-access segment.
Fix with priority, not cost. Priority is per-VLAN and global to the switch, it documents itself as primary/secondary, and it stays correct when links are added or upgraded. Interface cost tuning is per-link and breaks the moment someone inserts a new Gigabit or 10 Gigabit link, because every hand-tuned number is then wrong. Use cost only for the narrow case where you need one specific link blocked for one specific VLAN and root placement cannot express it.