UK How a broadcast storm happens
A broadcast storm is what happens when broadcast traffic on an Ethernet network grows faster than the network can carry it. Broadcast frames are addressed to every device in the network segment, and switches forward them out of every port except the one they arrived on. A small amount is normal: devices use broadcasts to find each other with ARP, to get an address with DHCP and to announce services.
In a storm, the same frames are sent again and again. The classic case is a switching loop, such as a patch lead connecting two ports on the same switch or two switches joined by two cables without loop protection. Ethernet frames carry no hop limit, so each broadcast goes round the loop for ever, and every switch on the way copies it to all its other ports. Within seconds the copies multiply until the links are saturated.
The storm stays inside one broadcast domain, which is one VLAN or one switched network up to the nearest router. Everything inside that domain is affected at once, which is why a single wrong cable can stop a whole production area.
What causes a broadcast storm
Loops are the most common cause, but not the only one.
-
//
Switching loops. A second cable between switches, a port patched back to its own switch, or a loop through an unmanaged switch that does not run spanning tree.
-
//
Faulty or misconfigured devices. A failing network card, a device stuck retrying a broadcast, or a misconfigured bridge on a computer with two network ports.
-
//
Very large flat networks. Hundreds or thousands of devices in one broadcast domain generate enough routine ARP and discovery traffic to load slow links and small devices.
-
//
Multicast and unknown unicast floods. Without IGMP snooping, multicast is flooded like broadcast, and a switch floods unicast frames to every port when it has not learned, or has run out of room for, the destination address.
-
//
Malicious or test traffic. Malware, scanning tools or a traffic generator left running on a production network.
What a broadcast storm looks like
The outcome of a Layer 2 broadcast storm is that the network effectively stops. Port lights on every switch flash constantly, link utilisation sits near 100%, and the switches’ management interfaces become slow or unreachable because their processors are busy. Switch logs often show MAC address flapping, the same address appearing on different ports as frames circle.
End devices suffer too, because every one of them has to receive and examine every broadcast. On a plant network the first visible symptom is usually communication faults: HMIs freeze, PLCs lose their I/O connections and drop to a fault state, and remote I/O and drives go offline. Small devices with simple network processors are often the first to stop responding.
How to prevent and contain broadcast storms
No single feature does everything. Some methods stop a loop forming, while others limit the damage if traffic runs away for another reason. The table compares them.
| Method | What it does | Stops a loop? | Where it runs |
|---|---|---|---|
| RSTP or MSTP | Blocks redundant links so there is one active path | Yes | Managed switches |
| Ring protocols (ERPS, MRP) | Block one ring link and reopen it on failure | Yes, on rings | Managed industrial switches |
| Loop detection and BPDU guard | Shut down a port when a loop or unexpected switch is detected | Yes, at the edge | Managed switches |
| Storm control | Rate-limits broadcast, multicast or unknown unicast per port | No, limits the damage | Managed switches |
| Fixed broadcast storm protection | Caps broadcast traffic at a preset level | No, limits the damage | Many unmanaged switches |
| VLANs and routing | Split the network into smaller broadcast domains | No, limits the spread | Managed and Layer 3 switches |
| IGMP snooping | Sends multicast only to ports that asked for it | No, stops multicast flooding | Managed switches |
The usual design is to prevent loops with RSTP or a ring protocol, contain anything else with storm control and keep each broadcast domain small with VLANs. Our white paper on Layer 2 vs Layer 3 switches covers routing between them.
What is storm control?
Storm control is a managed switch feature that watches incoming broadcast, multicast and unknown unicast traffic on each port and acts when it passes a threshold. The threshold is set in packets per second, as a percentage of port bandwidth or in kilobits per second, depending on the switch. When traffic exceeds it, the switch can drop the excess, shut the port down or raise an alarm through SNMP or syslog.
Set thresholds from the traffic a port normally carries, not from a default. Device-facing ports on a control network carry very little broadcast traffic, so a low limit works there, while uplinks between switches need more headroom. Many of our unmanaged industrial switches and embedded Ethernet switches list built-in broadcast storm protection, a fixed limit that helps with a misbehaving device, but it cannot detect or break a loop, so redundant cabling still needs managed switches running RSTP or a ring protocol.
Quick answers on broadcast storms
Broadcast storms: common questions
What is the outcome of a Layer 2 broadcast storm?
The network stops carrying useful traffic. Links saturate, switch processors overload and every device in the broadcast domain is flooded, so applications and controllers lose their connections until the cause is removed.
What is the most common cause of a broadcast storm?
A switching loop. Usually a cable that creates a second path between switches, or a port patched back to its own switch, with no spanning tree or ring protocol to block it.
How do you stop a broadcast storm?
Remove the loop, then add protection. Disconnect recently added cables or switches until traffic drops, check the switch logs for MAC flapping, then enable RSTP, loop detection and storm control.
Does a router stop a broadcast storm?
It stops it spreading. Routers do not forward broadcasts, so a storm stays inside one subnet or VLAN. It does not stop the storm inside that subnet.
Is storm control the same as loop protection?
No. Storm control limits how much broadcast or multicast traffic a port accepts. Loop protection, through RSTP, ring protocols or loop detection, removes the loop that causes most storms.
We supply industrial switches with our control and edge systems, and as standard we configure loop protection, storm control and VLANs to match the site’s network before it ships.