Network Loop Detected: Steps to Kill It Fast

Network Loop Detected? Here's What's Happening

You see a message like SW_LOOP_DETECTED in your switch logs, or worse—your whole network just froze. Every light on the switch blinks in unison. Pings time out. The boss is yelling.

What's actually happening is a broadcast storm. A network loop occurs when a packet finds multiple paths back to itself. It gets copied and recopied, doubling each time, until the switch's CPU hits 100% and all traffic stops. The loop detection message means your switch tried to warn you before the storm killed everything.

I've seen this happen from a single patch cable under a desk, a misconfigured trunk, or an unmanaged switch plugged into two wall jacks. The fix depends on where the loop lives. Here's the order I'd attack it.

The 30-Second Fix: Yank Cables

This is quick and dirty. If the network is completely dead, unplug every cable from the switch except the uplink to your router. Wait ten seconds. If things come back, you know one of those cables caused the loop.

Now plug them back one at a time. Watch the switch—if the lights go crazy again, that cable is your loop. Trace it to its endpoint. Most of the time it's a cheap unmanaged switch where someone plugged both its uplink ports into the same wall jack. Unplug one side. Done.

Why this works: The loop requires a closed circuit. Removing one link breaks it. This is brute force, but it's fast when the network is down right now.

The 5-Minute Fix: Check Spanning Tree Protocol (STP)

If unplugging cables didn't reveal the loop—or you don't want to disrupt users—look at STP. Most managed switches run STP by default, but it can fail if someone disabled it or if the topology changed too fast.

Log into your managed switches. Run this (Cisco syntax, but most vendors have an equivalent):

show spanning-tree summary

Look for a line like Root bridge for: none or Number of topology changes: 5000. If you see thousands of changes in minutes, STP is flapping. The loop is happening because STP can't converge—it's recalculating faster than switches can agree on a root bridge.

Fix: On the switch you suspect is the culprit, set a lower bridge priority to force it as root:

spanning-tree vlan 1 priority 4096

This gives one switch authority and stops the negotiation chaos. If the loop stops, you found your problem switch. Also check for BPDUguard—it should be enabled on all access ports. On Cisco:

interface range gigabitEthernet 0/1-24
spanning-tree bpduguard enable

Real-world trigger: I once spent an hour chasing a loop that turned out to be a VoIP phone with a passthrough port that someone daisy-chained into another switch. STP saw two paths and flipped out. BPDUguard on the phone port would have killed it instantly.

The 15+ Minute Fix: Tune Loop Detection and Guard Features

If you're still getting the error after STP seems stable, the loop is likely intermittent. It could be a hardware fault—a switch port that sends out spurious packets—or a configuration that bypasses STP entirely.

Start by enabling loop guard. This is an STP extension that monitors whether a port is receiving BPDUs. If a port that should be receiving them goes silent, loop guard puts it into a loop-inconsistent state instead of forwarding traffic blindly.

On Cisco:

spanning-tree loopguard default

This enables it globally. Some admins skip this because it can cause false positives with PortFast ports—but honestly, don't use PortFast on trunk ports. Only use it on end devices.

Next, if you have unmanaged switches in your network (and you probably do), isolate them. Plug them into a single managed switch port—never into two. For extra safety, enforce root guard on the managed port. This prevents an unmanaged switch from becoming the root bridge if it starts sending BPDUs (which unmanaged switches usually don't, but some do under fault conditions).

interface gigabitEthernet 0/1
spanning-tree guard root

Why this works: Root guard blocks any BPDU that claims a higher priority than the current root. It's a paranoid defense, but it stops loops from misconfigured switches taking over the tree.

If the loop still appears, you need to check for hardware faults. Run a port-error counter:

show interfaces counters errors

Look for ports with high CRC errors, frames too long, or alignment errors. A failing NIC or a bad cable can cause phantom packets that loop. Replace the cable first—Cat6 twisted pair goes bad from being stepped on or kinked. If that doesn't fix it, swap the switch port or the endpoint device.

One more thing: if you're running RSTP (Rapid Spanning Tree), it's more aggressive with convergence. That's usually good, but fast link transitions can trigger false loop detections on buggy firmware. Try downgrading to classic STP (802.1D) as a test:

spanning-tree mode stp

If the errors stop, you have a firmware bug. Upgrade the switch's firmware to the latest stable release. I've seen this on older HP ProCurve and Netgear GS series switches.

What to Do If None of This Works

You have a persistent hardware issue or a configuration that's deeper than a single loop. Your next step is a packet capture. Mirror the suspect port to a monitor port:

monitor session 1 source interface gigabitEthernet 0/1
monitor session 1 destination interface gigabitEthernet 0/24

Run Wireshark on the monitor port and filter for eth.addr == ff:ff:ff:ff:ff:ff (broadcast frames). If you see the same source MAC repeating every few milliseconds, that's your loop source. Find that MAC in your switch's ARP table, trace it to a physical port, and kill it.

This is advanced, but it's the only way when the loop is sporadic or caused by faulty firmware that ignores STP.

The Takeaway

Network loops are nasty because they look like everything broke at once. But 90% of the time, it's a single cable or a misconfigured STP setting. Start with the physical—unplug and replug—then tune your STP guards. And never, ever trust an unmanaged switch.