Layer 2 Loop Storm: Finding the Loop When the Whole Network Goes Down

The Signature of a Layer 2 Loop

Redundant links and redundant devices are supposed to make a network more reliable — until a network change forms an actual loop, and that same redundancy turns into a broadcast storm.

Ethernet switching networks deploy redundant devices and redundant links deliberately, for reliability. But network adjustments, configuration changes and version upgrades routinely create data or protocol frames that circulate in a ring by accident — and the moment a loop-breaking protocol isn't running, or a configuration change quietly punches a hole in one that is, that redundancy becomes a broadcast storm instead of a safety net. A single broadcast frame caught in a loop gets forwarded out every other port on every switch on the ring, over and over, until it saturates every link at close to line rate — and normal traffic simply stops getting a turn.

This note covers how to tell that this is actually what's happening (as opposed to some other kind of outage), how to locate the loop fast, how to break it without making the outage worse, and the specific misconfiguration cases — VLAN 1 left on a port, STP edge ports never set, MSTP regions that don't match, RRPP nodes running different modes — that account for a large share of loops that were never supposed to exist in the first place.

What a Loop Looks Like, and How You Confirm It

A loop's symptoms and the four-method confirmation flow, side by side.

The four confirmation methods below have no fixed order — use one or several together, whichever the situation gives you access to first.

Diagram labels are kept in English for engineering clarity.

Four Ways to Confirm It's Actually a Loop

All four rely on commands already available on every switch — no special tooling required.

1. Interface Traffic — the Fastest First Check

Run display interface brief and compare two readings a short time apart: on a port carrying a loop, InUti and OutUti climb steadily toward the port's rate ceiling. If only one device's one port shows heavy traffic in both directions, suspect a single-port self-loop; if one device's two ports are both heavy, suspect a two-port loop causing protocol flapping; if only one direction is heavy on a single port, the loop is more likely downstream of that port rather than on it.

<HUAWEI> display interface brief | include up
Interface             PHY Protocol InUti OutUti inErrors outErrors
GigabitEthernet0/0/16   up   up      76%   76%     0     0
GigabitEthernet1/0/12   up   up      76%   76%     0     0
// both interfaces climbing toward rate ceiling between two readings -- consistent with a loop

<HUAWEI> display interface XGigabitEthernet2/0/1
  Broadcast:      184920331, Multicast:    20524
// broadcast/multicast counters far above this device's other interfaces point at the same conclusion

2. MAC Address Flapping — the Confirming Signature

MAC flapping is when an interface learns a MAC address that a different interface in the same VLAN also learns — the later learning overwrites the earlier entry. A loop always produces MAC flapping; MAC flapping doesn't always mean a loop (it can also mean an unauthorized attack), but seeing the same MAC address bounce back and forth between two specific ports is the single most direct confirmation available.

[HUAWEI] vlan 10
[HUAWEI-vlan10] loop-detect eth-loop alarm-only
<HUAWEI> display trapbuffer
L2IFPPI/4/MFLPVLANALARM:OID 1.3.6.1.4.1.2011.5.25.160.3.7 Loop exists in vlan 1001, for
flapping mac-address 0025-9e6e-1c55 between port GE2/1/23 and port GE2/1/22.
// the same MAC bouncing between two named ports in the same VLAN -- direct evidence of a loop

3. Deploy Loop Detection — When You Need Definitive Proof

Loop Detection (chassis switches) and Loopback Detection (all switch form factors) periodically send a special detection frame out an interface and check whether the device itself receives it back — either on the same interface (a self-loop) or on a different one (a network loop). This is the most direct way to prove a loop exists, at the cost of extra system resources, which is why the manual explicitly recommends disabling it again once the check is done, and never enabling it on an uplink port.

[HUAWEI] loopback-detect enable
<HUAWEI> display loopback-detect
Loopback-detect is enabled in the system view
Interface              ProtocolID RecoverTime Action Status
GigabitEthernet0/0/2        602          30          block     NORMAL
// "Status" flips away from NORMAL the moment this device receives its own detection frame back
[HUAWEI] undo loopback-detect enable
// disable again once the check is complete -- this is a diagnostic tool, not a permanent setting

4. CPU Usage — the Corroborating Signal

A high PPI (Product Process Interface) task share in display cpu-usage — sustained, not a brief spike — strongly suggests a loop is flooding the CPU with packets it has to process. If PPI itself looks normal, check display cpu-defend statistics for protocol packets being dropped by rate-limiting; heavy drops there point the same direction.

<HUAWEI> display cpu-usage
CPU Usage           : 91% Max: 96%
TaskName         CPU Runtime            Task Explanation
PPI              70%      0/512f8c      PPI Product Process Interface
// a sustained high PPI share, not a brief spike, is the pattern that suggests a loop

<HUAWEI> display cpu-defend vrrp statistics all
Packet Type   Pass(Bytes) Drop(Bytes)  Pass(Packets) Drop(Packets)
vrrp          79880066214 2581617736  1174644777    37950869
// heavy protocol packet drop under rate-limiting is consistent with a loop saturating the link

Stop the Bleeding: Emergency Loop-Breaking

Once a loop is confirmed, the priority shifts from diagnosis to getting business back up — as fast as possible, without introducing a second problem.

1. Get or reconstruct the full topology first — device names, system MAC, management IP, and local/remote port names and VLAN plan for every device on the loop. Without this, you're guessing at which link to break.
2. Confirm which links or devices remain reachable for remote management before touching anything — breaking the wrong link can lock you out of the very devices you need to keep managing.
3. Pick the least-disruptive break point: remove the looped VLAN from one port (Access: undo port default vlan; Trunk: undo port trunk allow-pass vlan id; Hybrid: undo port hybrid vlan id) if you can identify one precisely — this is the narrowest-impact option. Note that removing the default VLAN from an Access port can affect downstream devices on that port, so confirm what's actually behind it first.
4. If you can't isolate a single VLAN, shutdown the looped physical port instead — reversible with undo shutdown, and safer than unplugging a fibre by hand.
5. Only pull the physical fibre or cable if the device can no longer be reached remotely at all — this is the last resort, not the first move.
6. Confirm recovery with ping and by watching traffic return to normal levels — a properly broken loop topology should let business resume on its own once the redundant path is no longer looping.

[SwitchA-GigabitEthernet1/0/1] undo port trunk allow-pass vlan 1
// narrowest-impact break: remove only the looped VLAN from this one port

[SwitchA-GigabitEthernet1/0/1] shutdown
// broader but reversible -- undo shutdown restores the port once the loop is actually fixed

Five Misconfigurations That Cause Loops That Were Never Supposed to Exist

Related solution designs

A Real Case: VLAN 1, Two Uplinks, and an OSPF Peer That Kept Going Down

The outage looked like a routing problem. The actual cause was a VLAN that nobody thought to check.

The setup: a switch with dual uplinks to routers, and access-layer devices hanging off it downstream. The symptom: both upstream links went completely dark for business, a reboot brought service back for a while, and then the exact same failure returned.

The log trail pointed first at OSPF, not at Layer 2 at all — the uplink neighbor relationship kept dropping, seemingly for no reason:

NBR_CHG_DOWN(l): Neighbor event:neighbor state changed to Down. (ProcessId=88,
NeighborAddress=x.x.x.x, NeighborEvent=KillNbr, NeighborPreviousState=Loading,
NeighborCurrentState=Down)

NBR_DOWN_REASON(l): Neighbor state leaves full or changed to Down. (ProcessId=88,
NeighborRouterId=x.x.x.x, NeighborAreaId=0, NeighborInterface=Vlanif4, NeighborDownImmediate
reason=Neighbor Down Due to Kill Neighbor, NeighborDownPrimeReason=Physical Interface State Change)

Diagnostic logs told the real story: the uplink ports GE1/0/0 and GE1/0/1 both showed abnormal outbound traffic, while the downstream ports GE1/0/3 and GE1/0/4 both showed abnormal inbound traffic at the same time — all four sitting right at the port's rate ceiling:

Interface GigabitEthernet1/0/0's flow is abnormal. (Speed=1000Mbps, CurrentInSpeed=0Mbps,
CurrentOutSpeed=849Mbps, File=IFPDT_FUNC_C, Line=13072)
Interface GigabitEthernet1/0/3's flow is abnormal. (Speed=1000Mbps, CurrentInSpeed=847Mbps,
CurrentOutSpeed=846Mbps, File=IFPDT_FUNC_C, Line=13072)
Interface GigabitEthernet1/0/4's flow is abnormal. (Speed=1000Mbps, CurrentInSpeed=849Mbps,
CurrentOutSpeed=849Mbps, File=IFPDT_FUNC_C, Line=13072)

Comparing the configuration of every flagged port turned up exactly one thing they all had in common: VLAN 1. Traffic coming into GE1/0/3 and GE1/0/4 inside VLAN 1 was being broadcast straight back out to the other flagged ports, including the two uplinks — flooding them until OSPF hello packets themselves were being dropped, which is what actually took the neighbor relationship down. Removing GE1/0/3 and GE1/0/4 from VLAN 1 cleared the fault immediately, with no further changes needed.

The generalizable point: a VLAN 1 loop is common enough that it's worth checking first, specifically, whenever port traffic looks abnormal across several ports that don't otherwise look related — compare their configurations for a shared VLAN before assuming the fault is somewhere more exotic.

Hardening the Network So This Doesn't Come Back

Once the immediate fire is out, these five checks are what actually prevent the next one.

1. Confirm a loop-breaking protocol is actually deployed and actually protecting every VLAN in use — STP/RSTP/MSTP, RRPP, SEP or ERPS, chosen to match the network design, not left to whatever the default happened to be.
2. Improve link quality and reliability where a marginal link is causing protocol packets to be dropped and blocked ports to open temporarily — replace suspect fibre, optical modules or cabling, and add bandwidth or link aggregation where congestion itself is dropping protocol frames.
3. Deploy broadcast suppression on ring ports as a safety net — roughly 5% is a reasonable starting point per the manual's own guidance, tuned against the network's actual concurrent broadcast traffic.
4. Deploy QoS so protocol packets get priority forwarding — a congested link that drops STP or RRPP frames before data frames is exactly what turns a brief blip into a full topology recalculation.
5. Revisit the network design itself once it's grown complex — layer access and aggregation deliberately, and split a single large flat domain into logically or geographically separate zones once the device count on it gets large.

FAQ

The questions that come up whenever a suspected loop is actually on the table.

Related Reading