A network loop happens when two switch ports form a redundant Layer 2 path without Spanning Tree Protocol blocking one side, causing broadcasts to circulate endlessly. Fix it by locating the offending ports (look for synchronised LED flashing and MAC flapping logs), shutting one down, then enabling STP, BPDU Guard, and Loop Guard.
Symptoms
- All switch port LEDs blink in perfect unison, often at high speed
- Sudden network-wide slowdown or total outage across multiple VLANs
- Switch CPU spikes above 90% with no obvious traffic source
- Log messages showing MAC address flapping between two interfaces
- DHCP, VoIP, and ARP resolution fail intermittently for every client
Common Causes
Unmanaged switch or hub added downstream
A cheap consumer switch plugged into two wall ports by a user creates a loop your managed switches cannot see or block, because the device does not forward BPDUs.
Spanning Tree Protocol disabled or filtered
If STP is turned off on an access switch, or BPDUs are filtered by an ISP handoff, redundant uplinks are never blocked and immediately form a forwarding loop.
Patch cable looped back into the same switch
A technician or user plugs both ends of a patch cable into two ports of the same switch, or daisy-chains two wall jacks that terminate on the same VLAN.
Misconfigured LACP or port channel
Bundling two links where one side runs static and the other runs LACP leaves the ports as independent forwarders instead of a single logical link, creating a loop.
Bridged virtual interfaces on a server or VM host
A hypervisor with two physical NICs bridged into the same vSwitch without STP awareness will forward broadcasts between the two physical segments.
Step-by-Step Fix
- Confirm you are actually looking at a loop, not a broadcast source
Watch the switch port LEDs. In a true loop, most or all LEDs flash in exact sync at very high speed. Compare against CPU load using show processes cpu on Cisco, or the equivalent on your vendor. Sustained high CPU tied to broadcast/multicast counters points strongly at Layer 2 flooding. - Read the MAC address-table for flapping entries
On Cisco IOS run show mac address-table | include FLAP or scan the log for MACFLAP messages. The log line names the two ports the MAC keeps bouncing between. Those two ports are almost always the loop edge. On HPE/Aruba, use display mac-address flapping or the equivalent. - Shut the suspected port to break the loop
Enter interface configuration mode and issue shutdown on one of the flapping ports. The network should recover within seconds. If it does not, shut the second flapping port as well. Never yank cables blindly in a production core; a targeted shutdown is faster and reversible. - Trace the physical path before re-enabling
Walk the cable from the shut port. Check whether it ends in another managed switch, an unmanaged desk switch, a wall jack, or a server NIC. Remove the redundant cable, correct the wiring, or reconfigure the downstream device. Document what you find in your patch record. - Enable Spanning Tree Protocol correctly
Turn STP on globally: spanning-tree mode rapid-pvst (Cisco) or the vendor equivalent for RSTP/MSTP. Verify with show spanning-tree summary that every VLAN has a root bridge and that redundant links show a BLK (blocking) role. Set root bridge priority explicitly on your core, not by accident. - Harden access ports with BPDU Guard and PortFast
On every user-facing port apply spanning-tree portfast and spanning-tree bpduguard enable. If a user ever plugs in a switch that emits BPDUs, the port goes err-disabled instead of joining the topology. This is the single most effective protection against user-created loops. - Add Loop Guard and Storm Control on uplinks
On inter-switch trunks enable spanning-tree guard loop to catch unidirectional link failures where a blocking port silently starts forwarding. Add storm-control broadcast level 1.00 so a future broadcast surge is capped before it saturates the uplink. - Verify stability and document the incident
Leave a continuous ping and an SNMP CPU graph running for at least 30 minutes. Confirm no MACFLAP messages return. Record the root cause, the ports involved, and the config changes in your change log so the next on-call engineer has context.
Loop symptom to likely cause and first action
| Symptom | Likely cause | First action |
|---|---|---|
| All LEDs blinking in sync, whole VLAN down | Active Layer 2 loop | Shut one flapping port |
| MACFLAP log between two access ports | User-side loop or unmanaged switch | Trace cable, apply BPDU Guard |
| Loop only after adding a second uplink | STP disabled or mismatched mode | Enable RSTP on both switches |
| CPU high, broadcasts elevated, no LED sync | Broadcast source, not a loop | Find top talker with SPAN + Wireshark |
| Loop appears only on one VLAN | VLAN not in STP instance (MSTP) | Map VLAN to correct MST instance |
| Port channel behaves as two links | LACP mode mismatch | Align both sides to active LACP |
Prevention
- Enable BPDU Guard and PortFast on every access port by default, not case by case
- Label both ends of every patch cable and keep the patch record current
- Disable unused switch ports with shutdown, not just by unplugging
- Ban unmanaged switches under desks; issue small managed switches with STP instead
FAQ
Why does my network still loop even though Spanning Tree is enabled?
STP only blocks paths it can see BPDUs on. If a user plugs in an unmanaged switch that does not forward BPDUs, or if BPDU filtering is enabled on an uplink, STP is blind to the redundant path. Apply BPDU Guard on access ports and remove any BPDU filter you did not consciously configure.
Is it safe to reboot a switch to clear a broadcast storm?
A reboot will pause the storm briefly, but the loop returns the moment the ports come back up because the physical topology has not changed. Identify the flapping ports and shut one before rebooting anything. Rebooting also loses the diagnostic logs you need for root cause analysis.
How fast does Rapid Spanning Tree react compared to classic STP?
Classic 802.1D STP typically converges in 30 to 50 seconds. Rapid STP (802.1w) converges in a few seconds under most topology changes because it uses proposal/agreement handshakes instead of timer-based transitions. Run RSTP or MSTP on modern hardware; there is no reason to keep legacy STP.
Contact our network team for a Spanning Tree and loop-protection review of your switching estate.