STP Recalc Loops: Stop the Flapping Now

You know the drill — users complain the network's slow, you check logs, and there it is: STP recalculating over and over. It's frustrating, but I've fixed this exact thing more times than I can count. Let's cut straight to the chase.

The Fix: Kill the Flapping Port

The culprit here is almost always a single port that's going up and down — flapping. STP sees each link change as a topology change and recalculates. Here's what to do right now:

1. Identify the flapping port — On Cisco gear, run show log | include %LINEPROTO-5-UPDOWN or show interface status | exclude connected. Look for an interface that's bouncing every few seconds.
2. Shut it down — No hesitation. interface gigabitethernet 0/1 then shutdown. That stops the STP storm immediately.
3. Check the physical layer — Bad cable? Loose connector? Damaged port? Replace the cable first — it's the cheapest and most common fix. If it's a long run, check for signal loss.
4. Enable PortFast on access ports — If the port is an access port (connected to a PC or printer), turn on PortFast. spanning-tree portfast. This tells STP to skip the listening and learning states. Don't do this on trunk ports — you'll create a loop.
5. Enable BPDU guard — spanning-tree bpduguard enable. This shuts the port down if it receives a BPDU, which would mean someone's plugged in a switch where they shouldn't. It's a safety net.

Why This Works

STP recalculates because it detects a topology change — a link went down, then came back up. Each time that happens, the switch floods the network with BPDUs, recalculates the tree, and temporarily blocks some ports. If a port's flapping, you get constant recalculations. Shutting the port stops the trigger. PortFast eliminates the delay for end devices. BPDU guard prevents rogue switches from causing chaos.

Without PortFast, every time a PC boots up or a cable jiggles, the switch has to wait 30 seconds (15 for listening, 15 for learning) before forwarding. That's why users see drops. With PortFast, it forwards almost instantly.

Less Common Variations of the Same Problem

Sometimes it's not a flapping port. Here's what else I've seen:

• Duplex mismatch — One side is auto, the other is hard-coded. This causes frame errors, which the switch interprets as link failures. Check both ends with show interface — if one says "full" and the other says "half", that's your problem. Fix it by setting both to auto-negotiate or both to the same hard-coded values. I prefer auto on modern gear.
• Bad fiber SFP — SFPs go bad, especially the cheap third-party ones. They'll show link but drop packets intermittently. Swap with a known-good SFP. If the flapping stops, that was it.
• Broadcast storm — A loop somewhere else in the network can cause a broadcast storm, which overloads the CPU and triggers STP to recalculate. Check your logs for high CPU or packet counts. Use show processes cpu to see if STP is eating CPU time.
• Wrong STP version — If you've got a mix of PVST+, Rapid PVST+, and MST, they don't play well together. Make sure all switches in the same VLAN region run the same STP mode. In most networks, Rapid PVST+ is the sweet spot — faster convergence than classic STP, and widely supported.

How to Prevent It From Coming Back

Once you've stopped the bleeding, make these changes permanent:

Also, run show spanning-tree active after any change to verify the topology is stable. If you see "Topology change" counts still climbing, something else is wrong.

One last thing — don't bother with spanning-tree vlan X root primary unless you really know what you're doing. It forces that switch to become root, which can help in some designs, but it's not a fix for flapping. Stick with the list above.