Root Bridge on an Access Switch: Warehouse Closet Re-Cable

Causal chain

1. AS3 was left at priority 4096 while DS1/DS2 sit at 32768, so AS3 wins the root election for VLAN 10. The two distribution switches now compute their path to the root over a single 1 Gb access uplink instead of their direct interconnect.
2. The DS1-to-AS3 link is genuinely unstable (bad patch, SFP, or cable). Because the root bridge itself is losing a port, every VLAN 10 switch re-runs the topology change, not just the edge device.
3. Each transition generates TCNs. A TCN causes switches to shorten the CAM aging timer, so unicast frames to known MACs are flooded to every port in VLAN 10 for a period. Leftover flooded traffic plus TCN processing lands on the supervisor in the interrupt path.
4. The flood bursts cause the short application hangs; the 61% CPU is the confirmation that the control plane is being hammered by flooding/TCN work rather than by a routing or application issue.

Causes: mis-set bridge priority on AS3, the unstable physical uplink, missing PortFast/BPDU Guard on edge ports. Symptoms: 3-8 second freezes, high TCN count, CPU spike, intermittent uplink outages.

Note that a flapping edge port without PortFast also emits a TCN each time it transitions, so even after fixing the root election the edge configuration still needs work.

Order of work

1. Fix the physical flap first or last, but know that it will keep causing TCNs until the patch lead/SFP is replaced.
2. On AS3, return the priority to default so it can never win: spanning-tree vlan 10 priority 32768. Harmless on its own.
3. On DS1: spanning-tree vlan 10 priority 4096. On DS2: spanning-tree vlan 10 priority 8192. Use explicit priorities rather than the root primary macro, because the macro sets 24576 by default and adjusts against the current root, which makes the result harder to predict when a rogue low-priority root already exists.
4. On access-facing ports: spanning-tree portfast plus spanning-tree bpduguard enable (or spanning-tree portfast bpduguard default globally).
5. On DS1/DS2 ports facing access switches: spanning-tree guard root, so a future low-priority access switch cannot capture the root.

Service-affecting: step 3. Changing the bridge priority forces a root re-election and a VLAN 10 reconvergence - expect a few seconds of interruption and a burst of TCNs. Do it in a change window, and do DS1 then DS2, not both at once. Enabling BPDU Guard is also disruptive if any edge port currently faces an unmanaged switch or hub that emits BPDUs; those ports will err-disable, so audit first.

Proof points (10-minute check)

• show spanning-tree vlan 10 on DS1, DS2, and a sample of access switches: root ID should be DS1's bridge ID, DS1 the root port/designated role on the interconnect, DS2 showing a root port toward DS1.
• show spanning-tree topology change on DS1/DS2: the counter should stop climbing. A small residual trickle from the still-flapping link is expected until the cable is replaced, so pair this with show interfaces | include flap on the AS3 uplink.
• show interfaces counters errors on the AS3 uplink: FCS/runts should stop increasing once the physical fault is cleared.
• show processes cpu sorted | exclude 0.00: interrupt-path CPU should fall back toward the ~12% baseline within a few minutes as flooding stops.
• Application spot-check with the warehouse team rather than relying on monitoring alone.

Residual risk to document

• The physical flap is not yet fixed; until it is, any link event still causes a (now much smaller) reconvergence.
• BPDU Guard err-disabled ports need a recovery procedure (errdisable recovery cause bpduguard with an interval) so a genuine device move doesn't leave a desk dark for days.
• No record yet of whether the 2960X is end-of-support hardware generating its own instability; check its logs for reloads and its IOS version.