Cisco Storm-Control Configuration

Lessons Discussion
1

This topic is to discuss the following lesson:

2

question, on the last sentence you said the default action is exceeding traffic will be dropped. but you can also use to shutdown the interface or send a trap.

if you configure to send a trap, the exceeding traffic will not be dropped? just only to inform you that it exceeds?

because on the selection of action, its only “Shutdown” and “Trap”. theres no “Drop the exceeding traffic”.

or it works this way that, it will drop the exceeding traffic, you just need to choose the 2nd option on what to do with it? is it you’ll shutdown the interface or send a trap?

3

Hi John,

In both cases, the exceeding traffic will be dropped. The only difference is the “extra” action that we perform. Do you want to shut the interface or only send a SNMP trap? That’s it.

Rene

1 Like
4

Hey Rene,

Just wondering. Is it better to program both sides of a trunk for storm control? It seems to me that one side of the link is good enough. Also I assume that it’s OK to assign this to a port-channel? When I do so I notice that it writes the storm control parameters to both the trunk and port channel which I would expect.

Thanks

5

Hi Michael,

I guess this depends on which end of the trunk you expect to have a broadcast storm :slight_smile: There’s no harm configuring this on both (or all) your switches. Configuring this on an etherchannel is no problem. Make sure you do this on the logical interface, not one of the member physical interfaces or it will be suspended.

Rene

6

Anyone know a good tool on Windows/Linux to generate a Broadcast, Unicast and Multicast Storm?
Would be great to test this on my switches.

7

Hi Ryan,

You could try Ostinato.

Rene

8

Hi Rene

I was packet sniffing a server switch port where remote users to this server have experienced very slow responses to http requests, on one occasion when I was sniffing the server switch port the Http responses (HTTP/1.1 200 OK) started to increase to over 30 secs on occasions, I did notice a high amount of broadcasts and multicasts with 62% of frames on the sniffer trace (13 mins duration) was either a broadcast or multicast. I want to insert a broadcast/unicast storm control is there a rule of thumb to configure a percentage level of broadcasts/ multicast prior to them being dropped??

Also do you have a service to analyse wireshark sniffer traces I would like a second opinion on my sniffer findings.

Many Thanks

Simon

9

Hi Simon,

Before you implement storm-control, I would start by taking a closer look at the broadcast/multicast traffic that you captured. 62% is a lot so you might want to make sure nothing strange is going on.

Anywhere above 10-20% is considered high.

Storm-control might work but it’s more of a band-aid solution :slight_smile:

I don’t offer any wireshark analysis. Not that I don’t want to but any 1-on-1 work is very time consuming.

Rene

10

Hi Rene,
Great Article :slight_smile:
What is the meaning of the sentence “default action will drop exceeding traffic”. Exceeding traffic means exceeding Broadcast/Multicast/Unknown Unicast traffic will be drop ?? and regular traffic will not, right ?? Thanks

br/zaman

11

That’s right, for example if you configure:

SwitchA(config-if)#storm-control broadcast level 30

Then broadcast traffic above 30% will be dropped, that’s it.

1 Like
12

Can you explain exactly what the Unicast element is? What makes a unicast “unknown”? :slight_smile:

13

Hello Chris

Unknown unicast traffic is essentially unicast traffic for which a switch does not have the destination MAC address already in its CAM table. Such traffic will require flooding from all of its ports thus adding to the severity of a potential broadcast storm.

I hope this has been helpful!

Laz

1 Like
14

A post was merged into an existing topic: Unicast Flooding due to Asymmetric Routing

15

Where is the best place to apply storm-control?
Interface facing to users’ PC?
Interface trunk up link from switch to other switch?
Should I apply to switch for server farm?

16

Hello Ratha

Storm control should be applied on any interface that has the potential to receive any kind of packet storm. Here are some guidelines to keep in mind:

  1. In general, it’s always best to apply it as close as possible to the source of the storm. That may mean applying it on interfaces facing user PCs, although there is minimal risk of a storm from a single device.
  2. This is a feature that is often applied after a broadcast storm is detected, however, it may be good practice to apply it proactively to mitigate against the possibility of a storm in the future.
  3. When applied proactively, care should be taken to set the thresholds as they may begin to block legitimate traffic.
  4. Storm control should be applied in situations where there is heavy use of multicast.

I hope this has been helpful!

Laz

17

Am I correct to say that you can also shut the interface AND send a SNMP trap.

18

Hello David

Unfortunately, I don’t have a switch readily available that supports storm control, so I am unable to try this out. The CML switch I have available doesn’t support it. However, looking at related Cisco documentation, the command is described as follows:

Switch(config-if)# storm-control action {shutdown | trap}

This syntax seems to indicate that either the interface will go into error-disable state, OR an SNMP trap will be generated. Both options cannot be configured simultaneously using this command.

However, if you want to be able to do both, you should be able to set the shutdown option and then configure SNMP traps for the state of interfaces independently as shown in the following lesson:

Just to be clear, I have not tested this, but it could be a good exercise to try out to confirm this functionality.

I hope this has been helpful!

Laz

19

Can we use this to control bandwidth usage of the end devices which is consuming too much bandwidth creating performance issues for others in the environment where there is no QoS ?
Also what other techniques can we use to control broadcast optional to storm control in general ?

20

Hello Ripal

Storm control can only be applied to broadcast, multicast and unknown unicast traffic. It does not affect normal unicast traffic. So this feature cannot be used to control the general bandwidth usage of end devices.

Well, some techniques you can use to specifically control broadcast storms include the use of:

  • Access lists
  • Using the rate-limit command on interfaces, although this falls under QoS

Some other features that indirectly reduce broadcast storms include:

  • Spanning tree, which prevents layer 2 loops and the resulting broadcast storm that would ensue
  • Making smaller network segments by creating more VLANs
  • Pruning unnecessary VLANs
  • implementing IGMP snooping for multicast environments

I hope this has been helpful!

Laz