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. _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
