Storm-Control Design Guidelines

Unanswered Question
Dec 5th, 2008

Hi there

Although we use Features like spanning-tree portfast bpduguard and spanning-tree guard root, we had a Broadcast-Loop taking down Headquarters last month. As far as we can see it, using Storm-Control would have prevented this loop, which is why we now want to activate this Feature. But the Documentation which we found is a little bit thin. Open questions are for example:

- Where do we activate Storm-Control:

-- On each and every port in the Campus? Don't we risk then that a Storm in one Vlan which is Switched between our Distribution Switches takes down the Link between the Distr. and taking down the whole Access Branch?

-- On every Access-Port? Is there any way of enabling Storm-Control globally for a Switch or do we really have to blow up our Configs even more (not a problem, but a bit ugly nevertheless)

-- On all Uplinks from Distribution to Access-Switches (loosing one Access-Switch in the Case of a Storm would be acceptable for us)

- Does Storm-Control only work on incoming traffic? If a Storm comes in at gi0/1 and gets flooded to gi0/2, will gi0/2 also be taken down or only gi0/2' neighbour? If it is unidirectional and applying Storm-Control only to Uplinks is ok - should we enable it on both Sides of the Distribution<->Access Links or is it enough to enable it on the Distribution Side? From a Keeping-The-Configs-Sane-And-Clean-Side, this would be the most appealing way to do it.

- What are reasonable Levels for Storm-Control? We prefer a dregraded but still working network to false Shutdown-Reactions, even if we work with errdisable recovery - so we think of going with a very high level like 50%. Does this make any sense?

- What would be a good Level for Unicast Storm-Control? Is reacting on Unicast a good thing at all?

- Can we configure two levels: e.g. on 5% send a trap, on 50% go to Errdisable? Is there any way to send a syslog instead of a snmp trap?

What we look for is a Design Guideline for Storm-Control, but all we found were Configuration Guides. Is there any Document which would answer the questions above? Or does anyone in here have some good advices on Storm-Control

Thx in advance and Greetings from Switzerland


(Targeted Hardware: c6500 native ios, c3560, c2960)

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (1 ratings)
Giuseppe Larosa Fri, 12/05/2008 - 11:25

Hello Mullzk,

we have deployed broadcast control in campus with C6500 Native IOS at the distribution layer and C4500 at the access layer.

We have it configured at 1.00 % level on all interfaces GE or TenGiga.

On uplinks it is combined with loop guard and configured both on both ends of each uplink

On GE access ports it is combined with BPU guard and STP portfast.

We had an issue with a 10GE link triggering bridging loops and the feature has been effective in providing us time to access the switches understand what was happening and shutting down the troubled link.

I think this is the added value of combining storm control with some STP features.

My understanding is that on IOS switches storm control works outbound:

after each bridging loop we see a huge increase in output drops that couldn't happen on TenGiga links that are still low used:

storm-control broadcast level 1.00

You can also on C6500 IOS define storm control for multicast and (unknown) unicast (flooding)

Hope to help


mullzkBern_2 Thu, 12/09/2010 - 15:32

Hi Martin

Yes, we implemented it, but we learned on the way

- Storm-Control works only on incoming traffic

- Storm-Control can't be configured globally, you have to enter the commands for every interface (using int range xy helps)

- You can't configure different levels for different actions. Yes, it would be nice, but it is not necessary.

- The actions are not only trap and shutdown, but also (and default) dropping packets which are beyond the threshold. So if you configure for example storm-control broadcast level 10.00, your network wont get down in case of a loop, as broadcast-packets get silently dropped if they reach 100mbps (on a Gigabit-Link), leaving 900mbps to real traffic. 

- Storm-Control is a feature focused on the Access-Layer. Nexus 7000 does not know the feature, Cat 6500 just cap the traffic but can't take any other action, not even sending a trap (we enabled it nevertheless, but the main thing is on the Access-Switches)

- We use action shutdown on all access-ports.

- We do not use action shutdown on uplinks anymore. We used to do so, with the same thresholds as on the Access-Ports. Then we had a condition with > 100mbps broadcast on one port-channel-uplink (4gigabit), which did not trigger stormcontrol on this link. But the distribution-switch flooded this traffic to all its gigabit-uplinks as well, causing them to shut down, although the loop was on another place in the network. using action trap only (and capping the storm-traffic), this would not have happened. shutting down access ports is ok, but uplinks have to much collateral damage.

hope this helps, although proper design guidelines from cisco still would be a great thing.
greetings from berne


This Discussion