Storm control on Cat4500

Answered Question
Feb 19th, 2010

I am looking at storm control on a Cat4500 and I have just read something in the configuration guide that has spooked me:

http://www.cisco.com/en/US/partner/docs/switches/lan/catalyst4500/12.2/25ewa/configuration/guide/bcastsup.html#wp1026636

When storm control is enabled on an interface, the switch monitors packets received on the interface and determines whether or not the packets are broadcast. The switch monitors the number of broadcast packets received within a one-second time interval. When the interface threshold is met, all incoming data traffic on the interface is dropped. This threshold is specified as a percentage of total available bandwidth that can be used by broadcast traffic. If the lower threshold is specified, all data traffic is forwarded as soon as the incoming traffic falls below that threshold.

http://www.cisco.com/en/US/partner/docs/switches/lan/catalyst4500/12.2/25ewa/configuration/guide/bcastsup.html#wp1037058

Hardware does not provide support for multicast suppression on the WS-X4515, WS-X4014, and WS-X4013+ supervisor engines. One consequence of using software-based broadcast suppression on these modules is that all incoming data packets are dropped. Irrespective of your selecting to configure broadcast suppression only, multicast packets are filtered as well on stub and blocking gigabit ports. The non blocking gigabit ports that do provide broadcast suppression in hardware also do not filter multicast packets.

(my highlighting)

Does it really mean that ... all data traffic is dropped, including unicast?  If so, that makes storm-control probably more dangerous than not having storm-control, and certainly not something you would want on your distribution layer.  It makes it really only useful on access ports.  If this is the case, I would think twice about implementing it, and I would be very careful where I implemented it.  I could kill the network stone dead simply by connecting a broadcast generator ... which is really what storm control is supposed to avoid.

Kevin Dorrell

Luxembourg

I have this problem too.
0 votes
Correct Answer by Lei Tian about 6 years 9 months ago

Hi Kevin,

If it is software based storm control, when reach the threshold all data traffic will be dropped (include broadcast, multicast and unicast). If it is hardware based storm control, only broadcast packets are dropped when threshold is hit.

Hardware based storm control is supported on all ports after supIV.

HTH,

Lei Tian

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (2 ratings)
Loading.
Correct Answer
Lei Tian Fri, 02/19/2010 - 03:34

Hi Kevin,

If it is software based storm control, when reach the threshold all data traffic will be dropped (include broadcast, multicast and unicast). If it is hardware based storm control, only broadcast packets are dropped when threshold is hit.

Hardware based storm control is supported on all ports after supIV.

HTH,

Lei Tian

Kevin Dorrell Fri, 02/19/2010 - 04:43

OK Lei, thank you for confirming that.  I have flagged "correct answer", but it's not really the answer I wanted to hear!

So, my conclusion is that I should not put storm control anywhere near my (layer-2) core, especially on the interconnect between my two data centres.  In the limit, I might put it on the distribution switches on the trunk links to the access switches.  That way I only risk losing one closet at a time.  But it does nothing to protect my core-distribution layer.

I wonder if I can do it with an input service-policy and policing.  Maybe that would work for layer-3 broadcasts, but not layer-2.  I shall do some experiments.

Kevin Dorrell

Luxembourg

Lei Tian Fri, 02/19/2010 - 05:12

Hi Kevin,

Thanks for the rating

I agree with you that storm control feature might not a good feature on core or distribution switches; it is a per port base feature, deploy storm control on the access switch and use policing to protect your distribution switches.

Some platforms allow you do /* Style Definitions */ table.MsoNormalTable {mso-style-name:"Table Normal"; mso-tstyle-rowband-size:0; mso-tstyle-colband-size:0; mso-style-noshow:yes; mso-style-parent:""; mso-padding-alt:0in 5.4pt 0in 5.4pt; mso-para-margin:0in; mso-para-margin-bottom:.0001pt; mso-pagination:widow-orphan; font-size:10.0pt; font-family:"Times New Roman"; mso-fareast-font-family:"Times New Roman"; mso-ansi-language:#0400; mso-fareast-language:#0400; mso-bidi-language:#0400;} classification based on L2 MAC acl, so you can police L2 traffic as well.

thanks,

Lei Tian

Kevin Dorrell Mon, 03/01/2010 - 00:53

Comments please ?....

So, I came to the conclusion it is dangerous to put storm-control on my distribution layer.  Briefly, I have access switches uplinked to a pair of 4500s in the distribution layer.  I wanted to protect the distribution layer by putting storm-control on the distribution downlink ports.  But, storm-control on the 4500 has the unfortunate behavior that when the broadcast limnit is reached, it drops all traffic, including unicasts.  I want to limit the MAC broadcasts and multicasts without impacting the unicast traffic in any way.

So, I am going to try something unconventional: to implement storm-control with an input service policy:

mac access-list extended bc+mc

  deny any 0180.c200.0000 0000.00ff.ffff

  permit any 0100.0000.0000 feff.ffff.ffff

class-map bc+mc

  match access-group name bc+mc

policy-map limit-mac-bc

  class bc+mc

    police 50000000 125000 conform transmit exceed drop

interface Fa6/4

  serivice-policy input limit-mac-bc

Has anyone here ever tried that solution?  Should it work?  I am trying it out on an access port, before risking it on the distribution layer.  But for some reason I am not seeing anything hitting the bc+mc class.  Plenty of traffic on the class-default, but none on the bc+mc.  I shall keep you posted.

BTW, I have been careful with my access-list so as not to police link-control frames (0180.c2xx.xxxx), but I don't know whether that was necessary.  Do the link-control frames get processed before the service-policy, or after?

Any thoughts anyone?

Kevin Dorrell

Luxembourg

P.S.  Just had a duh! moment.  The MAC access list applies only to non-IP traffic, and I suppose that it so even if you are using it as part of a class-map.  So, I need to make my bc+mc class a match any instead of a match all, and add an IP access list that identifies IP broadcasts and multicasts.  That looks easy at first (224.0.0.0 15.255.255.255 and host 255.255.255.255), but it is rather more difficult to identify directed broadcasts generically.  Mmmm ... re-think.  KJD.

Added P.S.

Lei Tian Mon, 03/01/2010 - 17:33

Hi Kevin,

IP traffic cannot be classified by MAC access-list. link-control traffic will not be affected by policy-map policing; it is switch processed  by RP; need COPP to police control plane traffic.

Broadcast like DHCP, ARP should be able to police in COPP, not sure about direct broadcast.

HTH,

Lei Tian

Kevin Dorrell Tue, 03/02/2010 - 00:35

Thanks for that information Lei.  I shall feed it into my thinking process and see what I come up with in a couple of days.

I shall have to pay special attention to the subnet broadcasts, especiually if there is an ip helper-address.

Kevin Dorrell

Luxembourg

Actions

This Discussion