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

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 classification based on L2 MAC acl, so you can police L2 traffic as well.

thanks,

Lei Tian

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.

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

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