I haven’t looked into Broadcast / Multicast rate limiting in a long time. Cisco IOS SX has a newish feature (at least to me) called Storm Control. Here are some quick notes to myself. Feel free to join in :
- works for broadcast, multicast and unicast on a physical interface. Not a logical interface.
- Storm control can be known as traffic suppression and
- monitors packets passing from interface to switching bus
- counts number of packets per type with 1 second interval
- suppression thresholds in three types:
- traffic rate in packets per second
- traffic rate in bits per second
- bandwidth as a percentage of the physical interface
- note that hardware counters are rarely precise ( silicon is ‘weird’ like that ) so measuring accuracy is poor subject to platform.
- use of rising / falling suppression levels is unusual in IOS.
- storm control features (eg errdisable recovery) may show up the IOS CLI in low end but are not implemented.
storm-control {broadcast | multicast | unicast} level {level [level-low] | bps bps [bps-low] | pps pps [pps-low]} storm-control action {shutdown | trap}
Switch# configure terminal Switch(config)# interface gigabitethernet0/1 Switch(config-if)# storm-control unicast level 87 65
- sets an 87% percent rising level and 65 % falling level.
Experiences
From this post on Cisco support forums: Storm-Control Design Guidelines
- 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)
About Greg Ferro
My experience and two cents for anyone looking for comments about usage in the wild. Rolled storm-control out to a data center with 6500s at the core/agg and 3750s for access supporting a few thousand hosts. Used trapping as the action where supported. There is no one right answer to setting the levels, as each environment is unique, but here’s a possible starting point: for host-facing ports, 20% and for interswitch trunks / bladecenter uplinks, 30%.
Make sure your NMS can escalate the traps so you’re aware that the storm-control algorithm tripped. Also, NMS alert system should be able to manage a trap flood without alerting you on every single one; you’ll get flooded with storm-control traps during a topology loop which can bury your e-mail client, really annoying if e-mail is part of your crisis communications methodology.
Some storm-control events are normal at the 20% / 30% level I suggested as a starting level, i.e. false positives. Specifically noticed Check Point firewall HA pairs would trip storm-control periodically; cluster members talk via multicast. Did not notice any negative effect on the firewalls as a result, but something to keep in mind.
We found during topology loops that we were able to maintain control of the switches via normal means (SSH, SNMP) and keep packet loss to a minimum. Kept the network “up”…did not lose L3 routing adjacencies, plus based on the traps, we gained some insight into which VLAN and possibly port was the source of the loop, allowing for quicker remediation.
Storm-control is not a replacement for CoPP, but potentially easier to standardize / template and less risky to implement.
Watch out for storm control policing your control plane traffic when you set it too aggressively.
Hi,
I m trying to implement storm control, on the equipement in the society where i work, everything is working fine but I want to understand how does sotrm work, i verified the CPU of my switch (where storm is configured),once with stream broadcast at 250M (less than my threshold set at 35% of my giga interface) i found a value of 99% in my cpu wich is normal due to broadcast, but when i send broadcast trafic at 500M or 700M i found a cpu very low, in my spirent test center i found that storm is working in Tx i have 700 and in Rx i have only 350, i have read that storm suppress all the trafic but i found all the time the threshold on my interfaces, Is there anyone who could help to understand properly the algorithm of storm
thkx
check this out:
http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/ios/12.2SXF/native/configuration/guide/storm.html#wp1039559
Before implementing this the “fine print” should be read very very very carefully.
Especially stuff like this:
-You can configure traffic storm control on an EtherChannel (a port channel interface).
particularly interesting and important:
-Do not configure traffic storm control on ports that are members of an EtherChannel. Configuring traffic storm control on ports that are configured as members of an EtherChannel puts the ports into a suspended state.
-When multicast suppression is enabled, traffic storm control suppresses BPDUs when the multicast suppression threshold is exceeded on these modules[..]
_the summary_ would be…read the fine print.. the whole fine print… for whatever device you decide to implement this