Storm Control

Mental model

A switch floods broadcasts, and it floods multicast and unknown unicast frames too, out of every port in the VLAN. That is normal. ARP, DHCP and plenty of discovery protocols depend on it.

A storm is when that flooding gets out of hand. A loop, a broken NIC or a misbehaving host pushes the same kind of frame thousands of times per second. Every device in the VLAN receives it, uplinks fill up, and users see “the whole floor is down.”

Storm control puts a speed limit on one port for one traffic type. You tell the switch: “broadcasts coming in on this port should never be more than 1 percent of the link.” If they go over, the switch stops forwarding that traffic type on that port until things calm down.

Think of it as a circuit breaker for flooding. It does not find the cause. It keeps one bad port from taking down everyone else.

How storm control measures traffic

Storm control is disabled by default. Once you turn it on, the switch looks at traffic received on the port and sorts it into broadcast, multicast or unicast. It counts each type over a 1 second interval and compares that count to your thresholds. On Catalyst 9000 switches this is done by a hardware rate limiter in the ASIC, so the action starts as soon as the rate reaches the threshold.

You pick one of three ways to express the threshold:

Two values control the behavior:

• Rising threshold (upper). When traffic reaches this level, the port blocks that traffic type.
• Falling threshold (lower, optional). The port stays blocked until traffic drops below this level, then forwards again. If you leave it out, the switch uses the rising threshold for both.

Two edge cases to remember: a level of 100 means no limit at all, and a level of 0.0 blocks all traffic of that type on the port.

One detail that saves confusion: when the multicast threshold trips, control traffic such as BPDUs and CDP frames is not blocked. Spanning tree keeps working on that port.

Configuration (IOS XE)

All storm control commands live in interface configuration mode. Start with broadcast on an access port:

SW1(config)# interface GigabitEthernet1/0/1
SW1(config-if)# storm-control broadcast level 1.00

Read it as: “if broadcasts received on this port reach 1 percent of the link in any second, drop broadcasts.”

Add a falling threshold so the port does not flap between blocking and forwarding:

SW1(config-if)# storm-control broadcast level 1.00 0.50

Now broadcasts are blocked at 1 percent and forwarding resumes only once they fall below 0.5 percent.

Multicast in packets per second, and unicast as a percent:

SW1(config-if)# storm-control multicast level pps 2k 1k
SW1(config-if)# storm-control unicast level 50.00 40.00

A fixed rate works too, for example storm-control broadcast level bps 10m 5m. Each traffic type takes one threshold setting. Remove it with no storm-control broadcast (or multicast, unicast).

Platform notes. Keywords vary a little across the Catalyst 9000 family. Some newer platforms and releases also offer storm-control unknown-unicast; Cisco says not to configure both unicast and unknown-unicast on the same interface. On C9550 Smart Switches only a single rising threshold is supported (percent or bps), with no falling threshold. On a C9350 stack only one measurement mode can be used at a time. Check the configuration guide for your platform and release before you standardize a template.

Actions and recovery

With no action configured, the switch simply filters (drops) the excess traffic and sends no trap. The port stays up and all other traffic keeps flowing. That is the default, and for most access ports it is the right choice.

You can add one or both of these:

SW1(config-if)# storm-control action trap
SW1(config-if)# storm-control action shutdown

• trap sends an SNMP trap when a storm is detected, in addition to filtering. Pair it with snmp-server enable traps storm-control globally so your NMS hears about it.
• shutdown puts the port into the err-disabled state. Every kind of traffic stops, not just the storming type. You will see messages like:

%STORM_CONTROL-3-SHUTDOWN: A packet storm was detected on Gi1/0/1. The interface has been disabled.
%PM-4-ERR_DISABLE: storm-control error detected on Gi1/0/1, putting Gi1/0/1 in err-disable state

An err-disabled port stays down until you recover it. Manually, after you fix the cause:

SW1(config)# interface GigabitEthernet1/0/1
SW1(config-if)# shutdown
SW1(config-if)# no shutdown

Or automatically, with a timer (default 300 seconds):

SW1(config)# errdisable recovery cause storm-control
SW1(config)# errdisable recovery interval 300

This is the same err-disable recovery you use for port security and BPDU guard. Recovery is disabled for every cause by default. If the storm is still happening, the port comes back, trips again and flaps every interval, so treat auto recovery as a convenience, not a fix.

Verification

show storm-control lists every port with storm control configured. Add an interface and a traffic type to narrow it down:

SW1# show storm-control GigabitEthernet1/0/1 broadcast
Key: U - Unicast, B - Broadcast, M - Multicast
Interface  Filter State   Upper        Lower        Current     Action     Type
---------  -------------  -----------  -----------  ----------  ---------  ----
Gi1/0/1    Forwarding           1.00%        0.50%       0.02%  Trap       B

What to read:

• Filter State: Forwarding is normal. Blocking means the rising threshold was hit and that traffic type is being dropped right now. Link Down means the port is down.
• Upper / Lower: your rising and falling thresholds, in the unit you configured (%, bps or pps).
• Current: the measured rate for the last interval. Compare it with Upper to see how close you are.
• Action: None means filter only; otherwise the configured action.

Column spacing differs a little between platforms and releases, but these fields are the ones to look for.

If you used the shutdown action, find the victims with:

SW1# show interfaces status err-disabled

Port         Name               Status       Reason               Err-disabled Vlans
Gi1/0/1                         err-disabled storm-control

Common mistakes

1. Setting thresholds so low that normal traffic trips them. Every host sends ARP and DHCP broadcasts, and a busy VLAN has a steady background of them. A tiny broadcast level combined with action shutdown turns a normal Monday morning into a pile of err-disabled ports. Watch the Current column with show storm-control for a while before you pick a number.

2. Using action shutdown on an uplink or trunk. Storm control measures traffic arriving on the port. On an uplink, that is the flooding from the whole VLAN. One burst and the switch cuts itself off from the network. Keep uplinks on the default filter action (plus trap if you want alerts).

3. Thinking storm control replaces spanning tree. It does not remove a loop. It only limits how much flooding one port can pass. Loops are the job of spanning tree and BPDU guard. Use storm control as the second layer.

4. Turning on auto recovery and walking away. errdisable recovery cause storm-control brings the port back, but if the loop or bad NIC is still there, the port flaps every interval. Check the logs and fix the cause.

Lab to try tonight

1. One Catalyst switch (or a lab image that supports storm control) and two PCs in VLAN 10 on Gi1/0/1 and Gi1/0/2.
2. On Gi1/0/1, configure storm-control broadcast level 1.00 0.50 and storm-control action trap.
3. Run show storm-control GigabitEthernet1/0/1 broadcast. Note the Current value while the PC is idle.
4. From PC1, generate broadcasts (a ping to the subnet broadcast address, or a traffic generator). Watch Filter State change to Blocking.
5. Stop the traffic and confirm the port returns to Forwarding once Current falls below 0.50%.
6. Add storm-control action shutdown, repeat the test and check show interfaces status err-disabled.
7. Add errdisable recovery cause storm-control with errdisable recovery interval 30 and watch the port come back on its own.

Cheat strip

Frequently asked questions

Q: Is storm control enabled by default on Cisco switches? A: No. Storm control is disabled by default on every port. You enable it per interface and per traffic type with storm-control broadcast, multicast or unicast.

Q: What does the switch do when a storm is detected if I do not configure an action? A: It filters. Traffic of that type above the threshold is dropped, no trap is sent, and the port stays up for everything else. You only get an err-disabled port if you add storm-control action shutdown.

Q: What is the difference between the rising and falling thresholds? A: The rising threshold is where blocking starts. The falling threshold is where forwarding resumes. Setting the falling value lower, for example level 1.00 0.50, stops the port from flipping back and forth when traffic sits right at the limit.

Q: Does storm control stop layer 2 loops? A: No. It caps how much flooded traffic a port forwards, which limits the damage, but the loop is still there. Spanning tree, PortFast with BPDU guard, and good cabling are what prevent loops. Storm control is a backstop.

Q: Will multicast storm control block spanning tree BPDUs? A: No. When the multicast threshold is reached, the switch blocks multicast traffic except control traffic such as BPDUs and CDP frames, so spanning tree keeps running on that port.