Someone patches a second cable between two switches "for redundancy." Within seconds every link LED is solid, every switch CPU is pinned at 100%, and the whole site is off the network — including the management you'd use to fix it. This is the broadcast storm: the fastest, most total layer-2 failure there is, and the one with no natural brake. Here's exactly how it forms, and the three things that stop it.
A switching loop is a layer-2 path that lets a frame come back to where it started. An IP packet has a TTL that counts down and eventually drops it; an Ethernet frame has no such field. A broadcast — or any frame for an address the switches haven't learned yet — is flooded out every port. If two switches have two paths between them, that flood circles forever, and every lap the switches re-flood it, so one frame becomes two, then four, then the line rate of every port at once.
The result is a broadcast storm: the CPUs saturate processing frames, the MAC tables thrash as the same source appears on every port in turn, and management stops responding right when you need it. The fix is not "be careful with cables" — it's a protocol whose entire job is to find the loop and block one leg of it before a frame can circle. This post is how the storm builds, and the three layers that stop it.
01
Three switches, two cables between a pair, and one broadcast. Watch it circle and multiply until the CPUs saturate — then watch RSTP block one port and the loop die.
The redundant link is not the mistake — redundancy between switches is good design. The mistake is a second active forwarding path with nothing deciding which leg should be standby. RSTP (Rapid Spanning Tree) is that decision: the switches elect a root, compute the shortest path to it, and put every other redundant port into a blocking state where it carries no data but still listens. The cable stays plugged in and warm; if the active leg dies, the blocked port comes up in under a second. You keep the redundancy and lose the loop.
02
Three properties of switching combine into a positive feedback loop. Each is correct on its own; together, with a physical loop, they have no stable state.
| Switch behaviour | Why it feeds the storm |
|---|---|
| No TTL at L2 | An Ethernet frame has no hop counter. Nothing in the frame ever expires, so a looped frame lives until a switch stops forwarding it — which, with a loop, never happens. |
| Flood the unknown | Broadcasts, multicast and unknown-unicast (a destination not yet in the MAC table) are sent out every port but the one they arrived on. A loop turns every flood into a lap. |
| Re-flood every lap | Each switch floods the frame again when it comes round, so one frame becomes many. Replication is exponential until every port is saturated at line rate. |
| MAC table thrash | The looped frame's source MAC appears on a different port every few microseconds, so the switches rewrite the MAC table constantly — real traffic can no longer be forwarded correctly either. |
This is why a loop is the most total layer-2 failure: it doesn't degrade the network, it stops it, and it does so in seconds. It also tends to take out the management plane — SSH, Winbox, the controller — because those run on the same saturated CPUs, which is what makes a loop frightening to fix remotely. (This is the argument for out-of-band management.)
03
A loop looks distinctive once you've seen one. These are the tells, in the order you usually notice them.
| What you see | What it means |
|---|---|
| All link LEDs solid (not blinking) | Ports are passing traffic at line rate continuously — the classic across-the-room tell. |
| Switch CPU at 100%, device laggy | The CPU is drowning in flooded frames; management UI crawls or times out. |
| The whole L2 domain is down at once | Not one VLAN or one host — everything on the broadcast domain, simultaneously. |
| MAC/FDB table flapping | The same MAC learned on a different port repeatedly. On RouterOS, log spam about a MAC moving; on IOS, %SW_MATM host-flapping messages. |
| It started right after a change | A new patch cable, a mini-switch under a desk, two wall ports bridged — a loop almost always has a human cause seconds earlier. |
04
Defence in depth: a protocol that prevents the loop, a guard that kills loops at the edge instantly, and a limiter that caps the blast radius if one slips through.
Run RSTP everywhere by default. It is the mechanism that makes the redundant link safe: one leg forwards, the others block, and failover is sub-second. The common mistake is turning it off "for performance" on a network that has, or will one day have, a redundant path.
# RouterOS: RSTP is the bridge default; make it explicit /interface bridge set bridge protocol-mode=rstp # Cisco: rapid-PVST is the sane modern default spanning-tree mode rapid-pvst
RSTP takes a moment to converge, and a loop at an access port (someone bridging two wall jacks, a cheap switch plugged in backwards) can storm before it does. BPDU guard shuts a port the instant it sees a spanning-tree frame where none should be; loop protection catches the case where no BPDUs arrive but a loop still exists.
# Cisco: on every access port interface range Gi1/0/1 - 24 spanning-tree portfast spanning-tree bpduguard enable # RouterOS: loop protection on edge bridge ports (RouterOS 7) /interface bridge port set [find interface=ether2] edge=yes-discover loop-protect=on
The last line of defence: if a storm happens anyway, limit broadcast/multicast/unknown-unicast to a small percentage of the link so the CPU and the real traffic survive long enough for you to find the cable.
# Cisco: cap broadcast + unknown-unicast storms per port
interface range Gi1/0/1 - 24
storm-control broadcast level 2.00
storm-control action shutdownThe most common self-inflicted storm: wiring a new switch on the desk with two cables back to the live network before its config (and STP) is in place, or enabling a bridge on RouterOS with two ports already patched. Configure new switches off the production network, bring STP up first, and patch the second uplink last. On RouterOS specifically, adding two already-connected ports to a bridge with no STP is an instant loop — the same reason this series' builds enable vlan-filtering and bridges carefully, in Ctrl+X Safe Mode.
05
When a site is "all down at once" and a change just happened, confirm or rule out a loop before anything else.
# RouterOS: CPU, then watch for a MAC learned on many ports /system resource monitor /interface bridge host print where !local # same MAC, flapping port? /interface bridge port print where role=disabled # is STP even blocking anything? # Cisco: the host-flap log is the smoking gun show processes cpu sorted | include CPU show spanning-tree blockedports show logging | include MATM # host-flapping between ports = loop
If you see one MAC bouncing between two ports and no blocked ports in the spanning tree, you have a loop and no brake. The immediate action is physical: find and pull the offending cable (often the newest one, or the one going to a place a switch shouldn't be), then fix the real cause — turn RSTP on, guard the edge — before you plug anything back.
Takeaways
A single mis-patched cable shouldn't be able to take down your whole site. I audit layer-2 for loop exposure — spanning tree, edge guards, storm control — and segment the network so one mistake stays small.
Book a Discovery Call →