A network loop forms when two switch ports create a redundant Layer 2 path and Spanning Tree Protocol isn't blocking one of them. Broadcast frames recirculate endlessly, consuming all available bandwidth. Isolate the offending link, set a correct root bridge, and enable BPDU Guard on every access port to fix it.
Symptoms
Every switch port LED blinks in unison at near line rate. Uplinks often go amber.
VoIP calls drop. DHCP requests time out. Users report the whole site is offline, all at once.
Switch CPU pins above 80 percent. SSH sessions stop responding and the web UI times out.
MAC address table entries flap between two or more ports for the same address.
Wireshark shows the same broadcast or unknown-unicast frames flooding in, back to back, within milliseconds.
Common Causes
Unmanaged switch or hub plugged into two live ports
Plug a cheap desk switch into two ports on the same access VLAN and you have an instant loop. No STP on the rogue device means nothing blocks the ring.
Spanning Tree disabled or filtered on an uplink
Turn off STP, or let an ISP handoff or transparent firewall drop BPDUs, and redundant links stay active. Traffic circles indefinitely.
Misconfigured LACP or port-channel
Bundle ports on one side and leave them as individual access ports on the other, and you create parallel forwarding paths. STP alone may not converge on those quickly.
Patch cable looped back into the same switch
A technician terminates a wall port to a keystone that's already wired upstream, or a user plugs both ends of a cable into two different wall jacks. Either way, it's a loop.
Overlapping VLANs across trunks
Two trunks carrying the same VLAN between the same switch pair, with per-VLAN STP misaligned, can let one VLAN loop while the others stay clean. That makes the fault surprisingly easy to miss.
Step-by-Step Fix
Confirm the loop before you touch anything
Get into the core switch out-of-band if you can. Run show processes cpu sorted and show interfaces counters errors. A loop shows up as sustained high CPU driven by ARP or IP input, with broadcast counters climbing thousands of frames per second across multiple ports simultaneously.Locate the looping ports via the MAC table
Run show mac address-table | include <a-known-mac> a few times in a row. If the same MAC address bounces between two different interfaces, those are your loop ports. HP and Aruba use show mac-address; Juniper uses show ethernet-switching table. Write down both port IDs before you do anything else.Shut the suspect port to break the storm
Go into interface configuration and issue shutdown on one of the two flapping ports. CPU should fall within seconds and broadcast counters stop climbing. If nothing changes, the loop is somewhere else; re-enable the port and move to the next suspect pair.Trace the physical path
Once the port is shut, physically trace the cable from the patch panel to the wall jack. You're looking for a daisy-chained desk switch, a second cable looping back to another jack, or a mislabeled uplink. Take photos before you rewire anything.Enable Rapid PVST+ or MSTP on every switch
Run spanning-tree mode rapid-pvst on Cisco, or the MSTP equivalent for your platform. Set the core or distribution switch as root using spanning-tree vlan 1-4094 priority 4096. Then run show spanning-tree root and confirm every access switch points to the same root bridge.Harden access ports with BPDU Guard and PortFast
Apply spanning-tree portfast and spanning-tree bpduguard enable on every user-facing port. When someone plugs in an unauthorized switch, the port err-disables in milliseconds rather than bringing down the whole site. Set errdisable recovery cause bpduguard with a 300 second timer so the port can self-heal.Verify convergence and clear counters
Pull up show spanning-tree summary and confirm no ports are stuck in listening or learning. Clear with clear counters and clear mac address-table dynamic, then watch traffic for two or three minutes. A healthy LAN sits at a few hundred broadcast frames per second at most.Document the topology and label both cable ends
Update your diagram with the actual uplink map, root bridge assignment, and every port carrying BPDU Guard. Label both ends of every patch cable. Loops come back because nobody documented what changed after the first outage.
Quick triage: symptom to likely cause to first action
Symptom | Likely cause | First action |
|---|---|---|
All uplink LEDs blinking in sync | Layer 2 loop between two switches | Shut one uplink, watch CPU drop |
One access port floods traffic | User plugged in a mini switch or looped cable | Shut the port, inspect the wall jack |
MAC flaps between two trunks | STP disabled or misaligned per VLAN | Enable Rapid PVST+, set a single root bridge |
Loop only on one VLAN | Trunk allowed-list mismatch | Align switchport trunk allowed vlan on both ends |
Port err-disabled after cable change | BPDU Guard triggered by rogue switch | Remove the rogue device, then no shut the port |
Storm returns after reboot | STP config not saved or overridden by template | Write config, review any orchestration templates |
Prevention
Put BPDU Guard and PortFast on all access ports as part of your standard switch template.
Storm Control should cap broadcast traffic at 1 to 5 percent of link capacity, applied per port.
Shut down unused ports with the shutdown command and move them to a black-hole VLAN.
Stick to managed switches with STP enabled. Unmanaged consumer switches still on your LAN should be retired.
FAQ
Will Spanning Tree Protocol alone prevent every network loop?
STP only protects against loops on switches that actually participate in STP. If BPDUs get filtered by a transparent device, or an unmanaged consumer switch just drops them, STP has no visibility into that segment. Same problem if someone creates a loop on a port where STP is disabled. Combine STP with BPDU Guard, Loop Guard, and Storm Control to cover those gaps.
How fast should a modern network recover from a loop event?
Rapid PVST+ or MSTP typically converge in well under a second on a small LAN after a topology change. BPDU Guard is faster; it err-disables the offending port in milliseconds. Traditional 802.1D STP is a different story: 30 to 50 seconds of convergence time makes it unsuitable for any production network.
Is it safe to just reboot the switches to clear a broadcast storm?
A reboot might pause the storm, but the loop comes straight back the moment the ports come up again. Find the physical loop or misconfiguration before you touch the power. Rebooting also destroys the diagnostic evidence you need: MAC flap counters, CPU history, the data that actually points to the root cause.