Storm Control: Stopping Broadcast Floods at the Port

A single misbehaving host can take down an entire VLAN. It does not take a spanning tree loop - a NIC stuck in a fault state, a virtualised workload gone wrong, or a genuine attack can flood broadcast frames fast enough to saturate every switch in the broadcast domain. Every switch dutifully floods every broadcast out every port, so one port's flood becomes everyone's problem.

Storm control caps the rate of broadcast, multicast, or unknown-unicast traffic on a port and takes action when the cap is exceeded. This article covers the configuration, the two threshold styles, and the right action to take - with an honest note on platform support. For the fundamentals, start at the complete VLAN and switching guide.

Why broadcasts are uniquely dangerous

A unicast frame goes to one port (once the switch has learned the MAC). A broadcast frame goes to every port in the VLAN, on every switch in the broadcast domain. There is no learning, no filtering, no limit. That is by design - it is how ARP and DHCP discovery work - but it means a broadcast storm scales with the size of your broadcast domain, and it consumes CPU on every device, not just switches. Hosts have to process every broadcast too.

Three traffic types get the same flood-everywhere treatment and are therefore the three storm control watches:

Configuration

Storm control is a per-interface feature. You set a rising threshold and, optionally, a falling threshold:

interface GigabitEthernet1/0/10
 storm-control broadcast level 1.00 0.50
 storm-control action shutdown
 storm-control action trap

That reads: on this port, if broadcast traffic exceeds 1.00% of the interface bandwidth, take action; do not clear the condition until it drops back below 0.50%. The gap between the two thresholds is hysteresis - it stops the port flapping in and out of the storm state when traffic hovers right at the threshold.

Three ways to express the threshold

The two actions

By default, storm control just drops the excess traffic above the threshold and keeps the port up. That protects the rest of the network but leaves the offending host connected and still trying. The two explicit actions change that:

• storm-control action trap - send an SNMP trap and syslog when the storm starts. Always configure this. You want to know.
• storm-control action shutdown - errdisable the port when the threshold is breached. This is the aggressive option: it removes the offending host entirely rather than just rate-limiting it.

Which action depends on where the port is:

Verification

Switch#show storm-control
Interface  Filter State   Upper        Lower        Current
---------  -------------  -----------  -----------  ----------
Gi1/0/10   Forwarding     1.00%        0.50%        0.00%

Switch#show storm-control broadcast
Switch#show interfaces Gi1/0/10 counters storm-control

Filter State: Forwarding means no storm. During a storm it shows Blocking (dropping) or the port goes errdisable. The Current column is the live percentage, which is where you watch a storm build.

Platform note: honest reporting

Storm control is a hardware feature - it depends on the switch ASIC being able to meter traffic per port at line rate. In our CML lab we build the switched topology on virtual IOL-L2 nodes, and those nodes do not implement storm control at all:

SW3(config-if)#storm-control broadcast level 1.00 0.50
                                                       ^
% Invalid input detected at '^' marker.

The command is simply not present, because there is no forwarding ASIC to meter against. We are telling you this rather than showing you invented counters. On real Catalyst hardware (and on the cat9000v platform in CML, which does model the UADP ASIC), the configuration above works exactly as described, and show storm-control reports the live filter state.

This is a general pattern worth internalising for lab work: the control-plane features (routing, spanning tree topology, protocol behaviour) reproduce faithfully on lightweight virtual nodes, but data-plane hardware features (storm control, hardware policers, TCAM-based ACLs at scale) need a platform that models the ASIC. Know which is which before you build the lab.

Choosing a threshold

Too low and you drop legitimate broadcast bursts - a hundred hosts booting and ARPing at 9 a.m. is normal, not a storm. Too high and a real storm saturates the network before the threshold trips.

The practical method: baseline first. Watch show storm-control during a normal busy period and note the typical broadcast percentage. Set the rising threshold comfortably above the normal peak - often 1-2% on an access port is a reasonable start - and the falling threshold at roughly half that. Then tune based on false positives.

Prefer a pps threshold on access ports. Broadcast storms are usually a flood of small frames, and a packets-per-second limit catches a high-rate, low-bandwidth storm that a percentage-of-bandwidth cap would sail straight past.

Storm control in the broader L2 hardening stack

Storm control is one layer. It sits alongside:

• BPDU guard - shuts a port that receives a BPDU it should not (a rogue switch).
• Port security - limits how many MACs a port may learn, catching MAC-flooding.
• DHCP snooping and DAI - stop rogue DHCP and ARP spoofing.
• Errdisable recovery - the safety net that brings a shut port back automatically.

None of these is optional on an access switch facing untrusted hosts. Storm control specifically covers the flood-based denial of service that the others do not: a host that is not spoofing anything, just drowning the VLAN in broadcasts.

Key takeaways

• Broadcasts, multicasts, and unknown unicasts flood every port in the broadcast domain, so one storming host is everyone's problem. Storm control caps the rate per port.
• Set a rising and a falling threshold; the gap between them is hysteresis that prevents flapping.
• Thresholds can be a percentage, bps, or pps. Prefer pps on access ports - storms are usually high packet rate, low bandwidth.
• Default action is to drop excess. Add action trap always; add action shutdown on host access ports (with errdisable recovery), but never on an uplink.
• Baseline normal broadcast levels before choosing a threshold. Too low drops legitimate bursts; too high lets a real storm through.
• Storm control is a hardware feature. Virtual IOL-L2 in CML does not implement it (% Invalid input); real Catalyst hardware and cat9000v do. We report that honestly rather than fake the counters.

Next: DHCP snooping in depth, the foundation of the Layer 2 security stack. The full cluster index lives on the VLAN and switching pillar.