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.
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.
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.
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?
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.
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.
Question We run asr9001 with XR 6.1.3, and we have a very long delay to
login w/ SSH 1 or 2 to the device compare to IOS device. After
investigation, the there is 1s delay between the client KEXDH_INIT and
the server (XR) KEXDH_REPLY. After debug ssh serv...
Introduction The purpose of this document is to demonstrate the Open
Shortest Path First (OSPF) behavior when the V-bit (Virtual-link bit) is
present in a non-backbone area. The V-bit is signaled in Type-1 LSA only
if the router is the endpoint of one or ...
Hi, I am seeing quite a few issues with patch install and wanted to
share my experience and workaround to this. Login to admin via CLI, then
access root with the “shell” command Issue “df –h” and you’ll probably
see the following directory full or nearly ...