Storm control

Cisco Catalyst switches provide a feature termed "storm control," which allows an administrator to suppress excessive inbound unicast, multicast, or broadcast traffic on layer two interfaces. This can be handy to protect against broadcast storms resulting from spanning tree misconfiguration, or even unicast storms created by malfunction host NICs.

On each interface, a maximum threshold can be configured in bits or packets per second, or as a percentage of the interface bandwidth. If incoming traffic of the specified type exceeds its threshold during a polling interval (one second), traffic is blocked until the incoming rate drops below the configured falling interval. Consider the following traffic graph:

graph.png

In interval T0, inbound traffic is accepted as its rate never exceeds the rising threshold. In T1, the rising threshold is exceeded, and the switch makes a note to block incoming traffic for the next interval. In T2, traffic is blocked, but the switch continues to monitor the incoming rate. Although the rate has fallen below the rising threshold, it still exceeds the falling threshold, so the switch will continue to block traffic for the next interval.

During T3, traffic stays below the falling interval, so the switch removes the blocking for T4. Although traffic in T4 exceeds the falling threshold again, traffic will not be blocked for the next interval as the rising threshold hasn't been exceeded.

Configuring storm control on an interface is simple. At a minimum you'll need to specify a traffic type (unicast, multicast, or broadcast) and a rising threshold:

Switch(config-if)# storm-control broadcast level bps 1m 500k

In the above example, we have configured storm control for broadcast traffic with a 1 Mbps rising threshold and a 500 Kbps falling threshold. Note that specifying a falling threshold is optional; if omitted, the falling threshold will default to the value of the rising threshold (effectively removing it).

show storm-control displays interfaces configured with storm control and the state of each:

Switch# show storm-control
Interface  Filter State   Upper        Lower        Current
---------  -------------  -----------  -----------  ----------
Fa0/5      Forwarding         1m bps     500k bps        0 bps

Observe how the output changes when the upper (rising) threshold for broadcast traffic is exceeded:

Switch# show storm-control
Interface  Filter State   Upper        Lower        Current
---------  -------------  -----------  -----------  ----------
Fa0/5      Blocking           1m bps     500k bps    2.08m bps

Additionally, the switch will generate a log message notifying administrators of the detected storm:

%STORM_CONTROL-3-FILTERED: A Broadcast storm detected on Fa0/5. A packet filter action
has been applied on the interface.

When the incoming rate drops below the lower (falling) threshold, the interface filter returns to forwarding:

Switch# show storm-control
Interface  Filter State   Upper        Lower        Current
---------  -------------  -----------  -----------  ----------
Fa0/5      Forwarding         1m bps     500k bps   48.81k bps

Lastly, the storm-control action trap command can be used under interface configuration to send SNMP traps in the event of a storm rather than the default behavior of blocking incoming traffic.

About the Author

Jeremy Stretch is a networking engineer and the maintainer of PacketLife.net. He currently lives in the Raleigh-Durham area of North Carolina. Although employed full-time out of necessity, his true passion lies in improving the field of network engineering around the world. You can contact him by email or follow him on Twitter.

Comments

just in the right time; we've just had an issue caused by a faulty NIC which forced all WAN links to flap among others, indicating how vulnerable could an enterprise be when features like this are ignored..

Another excellent example of the powers at layer 2.

Thanks Stretch!

Hi Jeremy,

which method or tool do you use for testing the storm-control broadcast? Any information/hint for me?

Thanks Norbert Boehm

@Norbert: I like iperf for stress testing. In fact, I used it to test the configuration shown in this article. You can create a static ARP mapping some IP to FF:FF:FF:FF:FF:FF to test broadcasts at layer two.

Super informative bro!..thanks

Is there any guidance on sensible values to use for the thresholds?

Coming from a large network, I can tell you that the hardest part is finding a sensible value that works in your enterprise for broadcast and multicast storm control. I have found the best bet is to start with a low number and work your way up, also look at traffic patterns and captures on that switch, which is also helpful in determining a faulty nic, or misconfigured MLB multicast device,

The time graph is a great illustration, I liked this post.

hey gr8 topic...cheers bro...

Storm-control can process both ingree and egress traffic???

hi guys,
vijay - as I know, it works only for ingress. if your traffic is comming from core, this won't help you.

Paul - did you find any post with sensible values ??

thnx

Try psense 1.2.3, with CARP + LoadBalance (Failover Mode), and a rule permit any/any from LAN to WAN. You will get a pretty broadcast storm to test...

Be carefull a TenGigabit network can be also vulnerable with this snowball...

"storm-control action trap" doesn't change default behaviour and blocking does happen when storm is detected. all it does is adding notification using SNMP traps that storm is in progress.

Am I reading this correctly? If is set the "storm-control broadcast level 30.00" without the additional "falling threshold" parameter the command is pretty much useless. Is this correct?

thank you.

How did you find out the "polling interval" is 1 second? thx

Leave a Comment


Register to comment as a member. You'll look cooler.

Optional; will not be displayed publicly or given out.

No commercial links. Only personal (e.g. blog, Twitter, or LinkedIn) and/or on-topic links, please.
What is the decimal equivalent of 0xA061?