cisco:switch:recommended_levels_for_storm_control
Differences
This shows you the differences between two versions of the page.
| Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
| cisco:switch:recommended_levels_for_storm_control [2022/01/16 19:33] – aperez | cisco:switch:recommended_levels_for_storm_control [2022/01/16 20:15] (current) – aperez | ||
|---|---|---|---|
| Line 27: | Line 27: | ||
| 1. Clear the counters | 1. Clear the counters | ||
| - | - switch# | + | |
| 2. Leave the switch working during 24 hours | 2. Leave the switch working during 24 hours | ||
| - | 3. Port by port (physical interfaces) check the amount of broadcast input | + | 3. Port by port (physical interfaces) check the amount of broadcast input packets, multicast input packets and the total input packets. |
| - | packets, multicast input packets and the total input packets. | + | |
| - | + | packets input value (TPI) | |
| - | - Switch#Show interfaces //look for | + | Received broadcasts value (BPI) |
| - | | + | (multicast) value (MPI) |
| - | | + | |
| - | | + | |
| 4. Let's do some mathematics: | 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. | 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. | + | 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 | 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 | ||
| Line 58: | Line 56: | ||
| 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." | 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% | ||
| + | |||
| + | |||
| + | ---- | ||
| + | |||
cisco/switch/recommended_levels_for_storm_control.1642379627.txt.gz · Last modified: 2022/01/16 19:33 by aperez
