Recommended Levels for Storm Control
i've been searching for some “best practice” or recommendations to configure storm control in a cisco switch.
we got a lot of sites and don't have the luxury of time to compute/customize these levels in our switching environment for each site.
can i just use a template with a level of 50% for broadcast, multicast and unicast and hope for the best?
is this value “too big” or “too small” to catch an anomaly?
interface gx/x switchport mode trunk storm-control broadcast level 50 storm-control multicast level 50 storm-control unicast level 50
I don't think there are recommended or best practice values. Below is a cut and paste answer from TAC I found in another blog post…
“I noticed you want a recommended threshold for the broadcast and multicast storm control. Unfortunately there is no a recommended threshold level because that will depend of the normal broadcast traffic on your network.
A way to determine that could be perform the following tasks during a normal day (common/usual traffic flow and amount patterns).
1. Clear the counters
switch#clear counters
2. Leave the switch working during 24 hours
3. Port by port (physical interfaces) check the amount of broadcast input packets, multicast input packets and the total input packets.
Switch#Show interfaces // look for packets input value (TPI) Received broadcasts value (BPI) (multicast) value (MPI)
4. Let's do some mathematics:
To get unicast packets you do TPI - BPI, TPI - BPI = UPI Normal percentage of broadcast = (BPI/TPI) * 100 Normal percentage of multicast = (MPI/TPI) * 100 Normal percentage of unicast = (UPI/TPI) * 100
That could give you an idea of the daily unicast, multicast and broadcast percentage on your network and could help you to set the proper threshold.
Now the formulas that I am giving you will give a general idea, just to have a projection, nevertheless, the error range is great.
In order to know the real values, you will require to monitor the traffic during a month or 2 getting the same statistics and perform and statistical analyze based on average and variance to get a closer real-life value. Also probably your network experienced seasons that some times could be on a low
traffic season and some times could be on a high traffic season. The traffic analysis is a task that requires getting constant traffic samples to adapt the thresholds to the real life and of course based on the statistical
analysis you will be able to determine the range you need to add to the threshold. For example, let's say you noticed the broadcast traffic is a 12% and the error range is between +2.76 and -2.76, so the value I will use on the threshold will be in the range 15% to 18%.
Please do not think the formula is the best way to determine the threshold, they are just to give a general idea but a deeper research should be done to determine that properly.”
I have seen customer networks working fine with 1 % of broadcast storm control on access ports just to accomodate for ARP request traffic.
The greater is the IP subnet the more broadcast traffic is needed but for /24 or more specific 1% of broadcast storm-control should work well on access ports.
About multicast traffic the first question is your network is using multicast streams of any form ? if the answer is yes you need to accomodate space for this legitimate traffic . If you use multicast a reasonable threshold for multicast can be 10%.
Unicast storm-control 60% or more
We have to remember that:
- the feature works on received traffic on the port not on outbound traffic on 1 second time intervals
- the feature is not smart and it is not able to discriminate good traffic and bad traffic
With low / aggressive thresholds storm control on access ports can make the difference between the capability to access remotely the distribution switches at the beginning of a bridging loop to shut down some links or the need to have someone on site to remove cables or even power off a distribution switch in an attempt to break the loop.
This happened before introduction of VSS many years ago.
On a L2 uplink trunk port of course thresholds cannot be so low as they carry traffic for multiple VLANs
B 15%
M 30%
U 60%