[c-nsp] Storm-Control on server switch uplinks.

[Saku Ytti]

On (2010-08-24 09:50 +0200), Peter Rathlev wrote:
 
> We use broadcast og multicast storm-control on downlinks towards access
> switches, generally at 50% just to make sure a broadcast storm doesn't
> spread too much.

I would run <1% broadcast storm control, preferably entered in pps and
rather low number. On 10GE 7600 receiving <0.34% bps broadcast (L3 or L2
port, doesn't matter) it can still drop IGP on unrelated interface and
cause serious downtime. 
But of course you can use 50% too if you have 50% excess capacity to handle
the storm and you know your devices can handle it. In typical network 1kpps
of broadcast is very high number for even 10GE L2, unless there is some
special application.

> I'm not sure I understand unicast suppresion; it sometimes triggers even
> when I would think it shouldn't. I haven't been able to grab the data

In some switches (e.g. 3550) if multicast triggers, all traffic is
suppressed, not just multicast.
Otherwise, I've not seen unicast blocked unless unicast is exceeded. I
think that the unicast storm-control is quite useless, unknown unicast
storm control would be much more useful.
I've used unicast storm-control in office LAN, to stop infected PC's from
congesting firewall. But I wouldn't run it on my customers as standard, as
our products do not dictate pps limit.

> I'm not sure why one would use it on uplinks, i.e. on the access switch
> side of things. AFAIK storm-control is an ingress thing.

If storm happens behind many edge ports, you could get aggregated rate
multiple times higher than individual access port limit. So you might want
to limit edge port to 1 unit and core to say 5 units.

-- 
  ++ytti