Cisco Storm-Control Configuration

This topic is to discuss the following lesson:

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?

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.


1 Like

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.


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.


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.

Hi Ryan,

You could try Ostinato.


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


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.


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


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.

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

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!