Cisco Support Community
Showing results for 
Search instead for 
Did you mean: 

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. And see here for current known issues.

New Member

6500- Strom control


I have configured storm control for broadcast and multicast on GE interaface of 6509.

Now My question is if let say there is countinuous storm and due to that there will be continuous drop ( strom is above threshold which is configured) , i may loose some genuine packet like HSRP (multicast) packet.

I tried to configure SNMP trap for the same but i got to know 6500 doesnt have "storm-control action trap" command and cant configure this.

Can any body tell me how can i achive this trap to send to my SNMP server for this strom control behaviour.


Re: 6500- Strom control

Hi Shah

very good question !

I started thinking about implemnting QOS so control traffic ( routing, BGP , HSRP etc..) is always guranteed bandwidth...but I am not sure yet which woudl take precendence. Storm control or QOS ? I guess it is one to be tested.


New Member

Re: 6500- Strom control

May be worth testing, but if I were worried about discarding important traffic I wouldn't touch storm control with a barge pole. According to my understanding, if the level of traffic (broadcast or multicast) exceeds the configured percentage of interface bandwidth, all traffic of that type is dropped until the offered rate drops below it again. This will guarantee that important traffic gets dropped during this period.

This really does seem to me to be a "last resort" method to prevent complete meltdown, and I would set the trigger levels quite high if I ever implemented it.

If you want better control over broadcast and multicast storms, I think QoS must be the way to go. One place to start may be here

which describes how IOS marks "important" traffic by default with precedence 6. How you use this to prioritise ingress traffic on a storm-affected interface depends on various factors, beyond the scope of this question.

Hope this helps

New Member

Re: 6500- Strom control

You are right that all traffic will get dropped until offered rate drops below configured one so will gurantee that control traiffc like hsrp hello also will get dropped.

Even you implement higher levels if it comes to that limit , your important traffic get droped othewise dont required to configure at all.

Can some body give some configuration for Qos for this issue which i can try and see HSRP traffic doesnt get drop even storm is there.

I will be happy to test this issue with current lab setup

Cisco Employee

Re: 6500- Strom control

Hi all,

a couple of points:

1) Storm control is not QoS aware. The algorithm simply compares a running count of multicast and broadcast traffic to the time interval, so if the threshold is exceeded, broadcast and/or multicast traffic will be dropped regardless of cos/dscp markings.

2) As said, Storm Control does not differentiate between data and control traffic (except BPDUs), so there is a chance of dropping important control traffic. I can't think of any control traffic that uses broadcasts, so as long as you just enable broadcast storm control, you should be fine.

Additionally, on a more subjective note, even with multicast storm control enabled, if you do lose an HSRP peer or OSPF neighbor, is that worse than propagating a broadcast/multicast storm that can potentially bring down the whole VLAN or Network?



*Please rate helpful posts.

New Member

Re: 6500- Strom control


Interesting discussion. Correct me if I'm wrong but I believe RIPv1 utilizes broadcasts for routing updates. There are a few others I believe such as IPX for example. Some points I wish to make (take them for what they're worth):

1. If your topology is set up in the traditional hierarchical model (i.e. access, distribution, core layers) then it makes the most sense to enable storm control on the access port that connects directly to hosts. Generally, these ports are not part of the HSRP or GLBP process so multicast packets shouuld not be affected if storm control is enabled in this fashion.

2. On the other hand, if you are researching the possibility of introducing storm control at the distribution layer, where HSRP is running, then there obviously is a risk of dropping control traffic when thresholds are exceeded.


Re: 6500- Strom control

Hi there

best bet here is to use QOS, and ensure the standard traffic or default queue is dropped if it exceeds a certain BW or % of interface BW. granted, it will drop both broadcast as well as genuine traffic....but at least your control traffic will be safe.



CreatePlease login to create content