Network loop? How to find it on switches with tcpdump
Learn how to identify broadcast storms caused by physical loops using tcpdump. Practical diagnostics to stabilize your network immediately.
Summary
- Network loops trigger broadcast storms that exhaust all available network bandwidth.
- The tcpdump command enables real-time traffic analysis to identify repetitive packet patterns.
- Physical faults like looped cables or Spanning Tree Protocol misconfigurations are common culprits.
- Specific filters in tcpdump help isolate the traffic saturating your network interfaces.
- Accurate packet capture is the most effective way to pinpoint the source of a network loop.
What happens when your network loops?
When two cables are incorrectly connected between switches, or a switch is connected to itself, a Layer 2 loop is created. In practice, this causes broadcast frames—packets sent to all devices—to circulate infinitely. Because every switch receives the packet and broadcasts it out of every other port, the network is quickly flooded, leading to a total system freeze. It is a silent nightmare that often shuts down even well-structured network environments.
Why tcpdump is your best diagnostic tool
Unlike management tools that show mere statistics, tcpdump acts like a microscope for data traffic. It captures and analyzes every single packet passing through a network interface. If you suspect a loop, tcpdump reveals a deluge of identical packets with the same source and destination MAC addresses or constant ARP packet repetitions. If you are not yet familiar with the utility, I recommend our guide on how to capture packets on Linux to prepare your environment.
Preparing the capture to identify the culprit
To diagnose the storm, you need to run tcpdump on an interface connected to the network core or a mirror port. The goal is to observe the volume of packets. If an interface is processing thousands of broadcast packets per second, you have found the trail. To capture only broadcast traffic, we use filters that ignore typical unicast traffic, focusing on what is actually flooding the network.
tcpdump -i eth0 -n -e broadcastThis command displays only broadcast packets on the eth0 interface. If the terminal output scrolls frenetically, you have a problem. To check the frequency, you can use auxiliary tools or output to a pcap file to analyze latency and packet loss, since a switch under loop stress will stop responding to ping requests.
Identifying the loop pattern
While analyzing the flow, look for 'Spanning Tree Protocol' (STP) packets or ARP requests repeating exhaustively. If the switch failed to apply the protocol meant to block redundant ports, you will see those packets circling back. During maintenance, it is common for someone to swap a cable or alter VLAN configurations, creating a logical fault that STP cannot detect. The diagnosis boils down to isolating the port that sends the most broadcast packets.
How to resolve the broadcast storm
- Physically isolate the suspected area by removing cables between switches one by one.
- Monitor the interface load with the command
to see if traffic drops after removing a link.tcpdump -i eth0 -c 1000 -e - Check the physical integrity of cables and connectors, treating the fault as if you were testing a shorted electronic component.
After locating the culprit link, the loop will cease immediately. Keep in mind that, in severe cases, the switch might require a power cycle to clear the forwarding tables corrupted during the storm. Maintaining accurate documentation of your physical topology remains your best prevention against this issue.