6500- Strom control

shah.chintan · ‎10-10-2006

Hi,

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.

cisco_lad2004 · ‎10-10-2006

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.

Sam

raarons · ‎10-10-2006

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

http://www.cisco.com/warp/public/105/rtgupdates.html

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

shah.chintan · ‎10-10-2006

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

Bobby Thekkekandam · ‎10-10-2006

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?

HTH,

Bobby

*Please rate helpful posts.

matthew.mcbride · ‎10-10-2006

Hello,

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.

-m2

cisco_lad2004 · ‎10-10-2006

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.

HTH

Sam