Someone in facilities patches a spare Ethernet cable between two wall jacks to test whether a port is "live." Both jacks happen to land on the same access switch. Nothing about that looks dangerous. Within a couple of minutes the switch's CPU is pegged, desk phones are rebooting, and the help desk queue is filling up with "wifi is down" tickets that have nothing to do with wifi.
What actually happened has nothing to do with Wi-Fi and everything to do with there suddenly being two paths between the same two switch ports, a physical loop. A single broadcast frame, an ARP request, a DHCP discover, anything, hits that loop and gets copied out both directions forever, doubling with every pass until the switch is spending all its CPU forwarding copies of the same frame and nothing else gets through. That's a broadcast storm, and on an access switch it takes far less than a minute to go from "someone made a mistake" to "the floor is down."
This is exactly the failure Spanning Tree Protocol exists to prevent, and exactly the failure that shows up when STP isn't doing its job. STP's purpose is to take a network with redundant physical paths, elect a root bridge, and put every port that isn't on the shortest path to that root into a blocking state, so redundant links exist for failover but never carry traffic during normal operation and never close a loop. Configured and running correctly, plugging a cable into a loop gets one port blocked automatically within seconds, no admin intervention, no outage.
So a live storm means one of two things: no loop protection running on that switch at all, or STP running but something telling a port to skip the process. The usual culprit is PortFast enabled on a port that isn't actually an edge port. PortFast exists to skip STP's listening and learning delay for ports that only ever connect end devices, never another switch, and it works exactly as designed right up until it's applied to a port that ends up connecting a switch to itself.
Diagnosing it live has a specific signature worth knowing before you need it. show mac address-table shows the same source MAC address flapping between two different ports within seconds of each other, repeatedly, because the loop is delivering the same frame back from two directions at once. show spanning-tree on the affected VLAN tells you whether a root bridge is even elected and which ports STP has put into blocking, and a rapidly climbing topology-change count means the network has been unstable, not just now. A MAC flapping between two ports that should never both be active for the same device is your loop, and unplugging either one ends the storm immediately, root-cause digging after.
Getting STP right so this doesn't depend on catching it live, root bridge placement, PortFast reserved for true edge ports, BPDU Guard to shut a port down automatically if it ever receives a BPDU it shouldn't, is core CCNA 200-301 material, not an edge case. The CCNA 200-301 Study Guide runs 41 hands-on labs and 150+ subnetting problems across 324 pages, switching and STP included, built to get this failure mode into muscle memory before it's a live incident: https://resources.codelivly.com/product/ccna-practical-the-hands-on-network-engineer-guide/
The free Routing & Switching Fundamentals path on codelivly.com covers the same OSI-layer switching foundation hands-on first, no cost: https://codelivly.com/learning-paths/routing-switching-fundamentals
Top comments (0)