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

[schilling]

We just had a incident that a person plugged two ends of a long wire
into two ports of a gig mini switch. The miniswitch then comes to our
access, distribution switch, then comes on layer 2 to our catalyst
6500. That crashed our catalyst 6500 w/ sup720 3bxl, IOS 12.2(33)SXI3.

Now we are reviewing the whole process, the access switch uplink was
only  730000 bits/sec and 8900
packets/sec. This kind of traffic was enough to crash the catalyst 6500.

During the storm, we enabled storm-control broadcast 0.01, the
catalyst 6500 was running at 99% CPU. we shutdown that port afraid of
crash it again.

We were thinking of implement storm-control broadcast 0.04 on our
WS-X6724-SFP gig ports.
Use 64 bytes packet and 576 bytes as references
                                                    64 byte
          576bytes
0.04%*1000,1000,1000/(64*8) = 780 pps                     87
0.08%*1000,1000,1000/(64*8) = 1562 pps                   174
0.16%*1000,1000,1000/(64*8) = 3152 pps                   350
0.48%                                           9456 pps
    1051pps

Which one do you think make more sense?

Schilling



On Tue, Aug 24, 2010 at 4:27 AM, Saku Ytti <saku at ytti.fi> wrote:
> 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  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>