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