Recommended Levels for Storm Control

[johnlloyd_13]

hi,

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

[Georg Pauwen]

Hello,

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."

[johnlloyd_13]

hi georg,

i saw that post and like i said i don't have the time to monitor each port/switch and make computations.

[Giuseppe Larosa]

Hello @johnlloyd_13 ,

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%

Hope to help

Giuseppe

[paul driver]

Hello
When first using storm control enable BC/MC at a high value rate (99.00) so to capture the traffic levels traversing the ports, as when you have a good base line you can then set a value more applicable to your switch(s)

[Joseph W. Doherty]

As others have noted, there's really no general recommendation for storm control values.

One principle reason for this, when storm control kicks in, it generally will also drop "good" traffic regardless of whether "bad" traffic is, or is not, exceeding the threshold settings.

The real purpose of storm control is to try to keep you network from having a complete meltdown, but it's far from ideal.

The best you might be able to do is set the threshold values above your typical load.

BTW, another problem with setting the thresholds is every network will have it's own values for what will cause a meltdown.

[johnlloyd_13]

hi,

i tried to lab this up between 2x 3560 switches and got some follow up questions.

i tried to simulate some ARP broadcast and created an STP loop in SW-2 ports f0/1 and f0/2.

i can still see high traffic on the SW-1 ingress trunk link f0/24. i thought it blocked broadcast and multicast traffic?

will other legitimate traffic still pass through on the trunk link? i.e. traffic from other VLANs, MGMT traffie.

or is it mixed with the broadcast and multicast categories?

SW-2#sh cdp n

Capability Codes: R - Router, T - Trans Bridge, B - Source Route Bridge

                  S - Switch, H - Host, I - IGMP, r - Repeater, P - Phone

Device ID        Local Intrfce     Holdtme    Capability  Platform  Port ID

SW-1             Fas 0/24          174           S I      WS-C3560- Fas 0/24

SW-1#

*Mar  1 03:09:01.733: %STORM_CONTROL-3-FILTERED: A Broadcast storm detected on Fa0/24. A packet filter action has been applied on the interface.

*Mar  1 03:09:08.804: %STORM_CONTROL-3-FILTERED: A Multicast storm detected on Fa0/24. A packet filter action has been applied on the interface.

SW-1#sh storm-control

Interface  Filter State   Upper        Lower        Current

---------  -------------  -----------  -----------  ----------

Fa0/24     Blocking          0.50%        0.50%       29.47%  

SW-1#sh storm-control broadcast

Interface  Filter State   Upper        Lower        Current

---------  -------------  -----------  -----------  ----------

Fa0/24     Blocking          0.50%        0.50%       29.72%  

SW-1#sh storm-control multicast

Interface  Filter State   Upper        Lower        Current

---------  -------------  -----------  -----------  ----------

Fa0/24     Blocking          0.50%        0.50%       69.24%  

SW-1#sh storm-control unicast 

Interface  Filter State   Upper        Lower        Current

---------  -------------  -----------  -----------  ----------

Fa0/24     Forwarding        0.50%        0.50%        0.00%  

SW-1#sh int f0/24

FastEthernet0/24 is up, line protocol is up (connected)

  Hardware is Fast Ethernet, address is 0016.c756.619a (bia 0016.c756.619a)

  MTU 1500 bytes, BW 100000 Kbit, DLY 100 usec,

     reliability 255/255, txload 1/255, rxload 79/255

  Encapsulation ARPA, loopback not set

  Keepalive set (10 sec)

  Full-duplex, 100Mb/s, media type is 10/100BaseTX

  input flow-control is off, output flow-control is unsupported

  ARP type: ARPA, ARP Timeout 04:00:00

  Last input 00:00:12, output 00:00:00, output hang never

  Last clearing of "show interface" counters never

  Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0

  Queueing strategy: fifo

  Output queue: 0/40 (size/max)

  5 minute input rate 31296000 bits/sec, 22667 packets/sec

  5 minute output rate 0 bits/sec, 0 packets/sec

     97026686 packets input, 13517132127 bytes, 0 no buffer

     Received 96751917 broadcasts (25422711 multicasts)

     0 runts, 0 giants, 0 throttles

     1 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored

     0 watchdog, 25446375 multicast, 0 pause input

     0 input packets with dribble condition detected

     1025007 packets output, 419177247 bytes, 0 underruns

     0 output errors, 0 collisions, 1 interface resets

     0 babbles, 0 late collision, 0 deferred

     0 lost carrier, 0 no carrier, 0 PAUSE output

     0 output buffer failures, 0 output buffers swapped out

[johnlloyd_13]

hi,

just a follow up question. i'll be applying storm control feature in our core switching fabric and got some few questions:

1. since this is an "inbound" filtering feature, do i just configure one one side, i.e. on the core/distro switch trunk?

access sw < trunk > collapse core/distro

2.is it recommended to apply this on the core switch to PE router uplink? or is this only applicable on switch to switch trunks?

[Giuseppe Larosa]

Hello @johnlloyd_13 ,

about your questions :

>>1. since this is an "inbound" filtering feature, do i just configure one one side, i.e. on the core/distro switch trunk?

in the worst case you can have an issue on access layer with some device claiming to be root bridge so I would apply it on both sides of the inter switch link

>> 2.is it recommended to apply this on the core switch to PE router uplink? or is this only applicable on switch to switch trunks?

Here, it depends from the type of MPLS service that you have bought for L3 VPN a storm of BUM cannot come from PE, but for a VPLS if BUM flooding is not kept under control on the SP side (using storm control) you should apply it.

Of the L2 services only the most modern EVPN should be able to avoid flooding on their own.

Hope to help

Giuseppe