Flamingo Raises $4.5M Seed Round · Led by Vertex Ventures, bringing total funding to $6.7M to build the open, AI-native layer for IT and security.
A broadcast storm is a Layer 2 loop that lets broadcast frames circle forever and takes a whole office offline at once. Here is what causes one in a small office, how to find the loop in the first ten minutes, and the switch settings that stop the next one.
The whole office loses the network at once, the switch lights blink in perfect unison, and a reboot fixes it for ten minutes. That pattern almost always has one cause, and it is usually a single cable plugged into the wrong place. This guide explains what a broadcast storm is, how to find the loop behind it in the first ten minutes, and which switch settings stop the next one.
Some traffic on a network is addressed to everyone. When a laptop asks for an IP address over DHCP, or asks "who has 192.168.1.1?" over ARP, it sends a broadcast frame, and every switch forwards that frame out of every port except the one it came in on. On a healthy network that costs nothing. Broadcasts are small and they stop at the edge of the segment.
A broadcast storm is what happens when those frames never stop. Put a loop in the cabling, so a switch can reach itself by two paths, and each broadcast goes out one path and comes back in on the other. The switch floods it again, out of every port, including the one that leads round the loop a second time. Each lap adds copies. Within seconds the links are full of the same handful of frames circling forever, and the real traffic cannot get through.
The reason they circle forever is a design choice from the 1980s. An IP packet carries a time-to-live counter that drops by one at every router and kills the packet at zero. An Ethernet frame has no such field, so a switch has no way of knowing it has seen a frame before. A loop at Layer 2 has nothing inside it that will ever end it. Something outside the frame has to break the loop.
Switches make it worse in a second way. Each switch learns which port a device lives on by watching the source address of frames. In a loop, the same source address arrives on two ports alternately, so the switch keeps moving the device from one port to the other. That is called MAC flapping, and it means even unicast traffic gets sent the wrong way. The same confusion shows up one layer up as a stale or flapping entry in the ARP table.
The textbook cause is two switches joined by two cables for redundancy with nothing managing the second path. In a small office the causes are smaller and more human, and four of them cover nearly every ticket.
The first is a cable with both ends in the network. Someone finds a loose patch lead and plugs it into the spare port next to it. Someone moves desk and plugs both ports on the back of their VoIP phone into both wall sockets. The phone has a tiny switch inside it, so that one desk move has joined two switch ports together.
The second is an unmanaged switch under a desk. A five-port switch bought to add a printer has no loop protection at all. Plug two of its ports into the wall, or loop one of its own ports back into another, and it will carry the storm to every switch upstream.
The third is a hypervisor. VMware's own guidance is that vSphere standard and distributed switches do not run spanning tree and cannot join two virtual switches at Layer 2 by default. A virtual machine that bridges two network adapters, or runs a VPN client in bridge mode, can still create the loop from inside the host.
The fourth is a failing network card or a device that crashes into a loop of its own and floods the segment with the same frame. That one is not a loop in the cabling, and spanning tree will not see it, which is why storm control exists as a separate setting.
The r/sysadmin thread below asks whether storms are still a risk on switched networks. The top replies answer it in one line each: find out who just touched a cable, and ask who moved desk and plugged both phone ports into the wall.
The symptoms are distinctive once you have seen them. Every device on the segment loses the network at the same moment, wired and often Wi-Fi bridged through the same switch. DHCP stops handing out addresses, so machines that reboot come back with a 169.254 address. A continuous ping to the gateway flaps between replies and timeouts, sometimes with a destination host unreachable in between. And the switch port lights, which normally flicker at random, blink in unison.
A managed switch will tell you directly. Look for interface counters where broadcast and multicast packets climb by thousands per second, for MAC flapping messages in the log naming the same address on two ports, and for a port that has error-disabled itself. If you have flow data, the storm shows as one tiny conversation filling the link, which our NetFlow guide covers.
On an unmanaged network, a laptop with Wireshark is the instrument. Capture for ten seconds and filter on eth.dst == ff:ff:ff:ff:ff:ff. A healthy office shows a few broadcasts a second. A storm shows the same ARP request or DHCP discover repeated thousands of times, with the same source address on every line.
The fix for a storm in progress is to break the loop, and on a small network the fastest way is to halve it. Unplug half the cables from the suspect switch. If the network comes back, the loop is in that half. Plug half of them back in and repeat until one cable brings the storm back. The device at the end of that cable, or the cable itself, is the answer.
Replies in this r/networking thread give both versions, the top one unplugging everything and adding devices back one at a time, another halving the cables. The office had 24 devices on an unmanaged switch that went down every ten minutes until rebooted. The poster had already replaced the switch, and Wireshark showed nothing but ARP. Several replies bet on an IP phone with both ports plugged into the wall at a desk with a phone and no computer.
On a managed switch you can skip the halving. The port that is error-disabled, or the two ports named in the MAC flapping log, point straight at the loop. Shut one of them, confirm the storm stops, then walk the cable. Before you plug anything back in, check every recent change: a desk move, a new switch, a new virtual machine, a phone swap.
Once it is fixed, write down which port and which desk. If you manage several sites, a script run across a client's devices that records each machine's gateway MAC address shows which ones saw it change during the incident. On OpenFrame that is one script with the output collected in one place.
A storm you found by hand is a storm that will happen again at the next desk move. Four switch features make it a non-event.
Spanning Tree Protocol is the one built for this. Switches exchange small messages called BPDUs, agree on a single loop-free path, and put every redundant port into a blocking state. If a loop appears, spanning tree blocks it before the storm builds. The original 802.1D version is slow: Cisco's own documentation notes it waits twice the 15-second forward delay before a port forwards, so a topology change can mean 30 seconds of disruption. Rapid Spanning Tree, 802.1w, does the same job and, per the same Cisco page, can converge in a few hundred milliseconds. On any switch that offers it, use RSTP, and make one core switch the root bridge on purpose rather than letting the oldest switch win the election.
BPDU guard goes on every port where a desk, a phone or a printer plugs in. Those ports should never hear a spanning tree message. If one does, it means someone has plugged a switch or a loop into the wall, and BPDU guard shuts the port immediately. That is the setting that turns the VoIP phone loop into one dead wall socket instead of a dead office. Pair it with PortFast on the same ports so desks get a link in a second instead of waiting for spanning tree.
Storm control catches what spanning tree cannot, such as a failing card flooding the segment. You set a ceiling for broadcast traffic on each port, as a percentage of the link's bandwidth, and choose what happens when it is crossed: drop the excess, send an SNMP trap, or shut the port. Cisco's guide warns the enforced level can differ from the configured one by several percentage points depending on packet size, and a Cisco Community answer notes there is no universal value because it depends on your normal broadcast load. Measure a normal day, then set the ceiling well above it.
VLANs shrink the blast radius. A broadcast only travels within its VLAN, so a loop in the guest Wi-Fi segment cannot take down the phones or the accounting floor. Splitting staff, phones, printers and guests is covered in our VLAN guide, and it doubles as a security boundary.
For unmanaged switches, look for a model with a loop detection or loop prevention feature, which several small business switch brands offer on their cheaper lines. It is cruder than spanning tree, but it is the difference between a blinking port and a dead office. The Crosstalk Solutions video below explains how spanning tree finds a loop and decides which port to block.
A broadcast storm is a loop at Layer 2 that lets broadcast frames circle forever, because Ethernet has no counter to kill them. It is usually a cable, a phone or a desk switch plugged into two places. Break it by halving the cables or reading the switch log, then turn on RSTP, BPDU guard on desk ports, storm control with a measured ceiling, and VLANs, so the next one stops at a single port.
If you are planning the network that sits under all of this, start with our small office network design checklist.
Content Marketing Lead
Ohayo! I run content, SEO, social, and community at Flamingo. Before IT, I worked as a correspondent for Ukraine's Public Broadcasting Company and have a Master's in journalism.
Still deciding?
Ask Mingo answers from our docs and customer stories.
Still deciding?
Ask Mingo answers from our docs and customer stories.
