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

[Peter Rathlev]

On Tue, 2010-08-24 at 11:27 +0300, Saku Ytti wrote:
> 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.

We chose the 50% based on the fact that we didn't exactly know how much
broadcast/multicast was "normal"; we have since been measuring (via
SNMP/Cacti) this level and will probably adjust downwards.

You're right about the spare capacity needing to be there. We naively
concluded that a loop induced storm would tend to settle down as long as
there's some kind of limit imposed.

I guess it's time to adjust things now. :-)

> I think that the unicast storm-control is quite useless, unknown
> unicast storm control would be much more useful.

Hm... I thought "storm-control unicast" was exactly for _unknown_
unicast. Otherwise it seems a little retarded (excuse my french).
Blocking/policing unicast as such isn't really helpful, is it?

If it really is just unicast (and not unknown unicast) I understand now
why the 3560G blocked traffic.

It would like the 6500 to support "storm-control action shutdown" by the
way. It can be EEM scripted of course, but that's a kludge.

> 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.

Agreed.