[c-nsp] Broadcast storm control

[Daniel Dib]

Hey Michael.

Here is something you can try out. Instead of using CoPP to limit ARP use
the hardwarebased ratelimiters. 

mls rate-limit unicast cef glean 20000 60 - This limits the number of
ARP-packets punted to the RP of the type glean. This will occur when traffic
is sent to a connected host for which the router has no MAC-address. Note
that this does not limit the actual number of ARP-packets passing through
the router. The numbers here are an example and you should try out values
that work for you.

Also check out mls qos protocol arp police 64000 - This will limit the
number of ARP-packets headed to the RP and also through the router. The
values is in kbit/s. Once again find your own value for this limiter.

Kristian Larsson on the list and I are working on a document describing
CoPP and some of the hardwarebased ratelimiters. When we are done we will
probably post it somewhere.

/Daniel

On (2007-11-06 09:05 -0600), Michael Malitsky wrote:

> I have some customers connected to a 6500, and already run stormcontrol
> and portfast.  I'll look into bpduguard as well, thanks.
> 
> However, most of my customers are connected to "router" platforms (the
> one specifically affected is a 7200).  As far as I know none of the
> actual L2 features apply there.  I tried setting up a control-plane
> policy to limit the stream of ARP requests, but it looks like it just
> can't drop the packets fast enough.

CoPP is done in hardware in PFC and can drop packets wire rate, 
so thats not it. There is very many gotchas in CoPP and making those
errors can force CoPP to be in software. E.g. I don't believe you
can match for arp, however you have separate arp policer in PFC
also (just not via CoPP).

> 
> Michael
> 
> > Message: 2
> > Date: Tue, 6 Nov 2007 04:06:57 +0200
> > From: Saku Ytti <saku+cisco-nsp at ytti.fi>
> > Subject: Re: [c-nsp] Broadcast storm control
> > To: Michael Malitsky <malitsky at netabn.com>
> > Cc: cisco-nsp at puck.nether.net
> > Message-ID: <20071106020657.GB10753 at mx.ytti.net>
> > Content-Type: text/plain; charset=us-ascii
> > 
> > On (2007-11-05 18:08 -0600), Michael Malitsky wrote:
> > 
> > > Last week one of my customers DoS'd me - they managed to 
> > create a wire
> > > loop between their switches, with no STP.  The resulting 
> > broadcast storm
> > > killed the CPU on my access router (their default gateway). 
> >  Does anyone
> > > have any pointers or best practices on how I can protect the router
> > > without having access to the switches beyond it?
> > 
> > I run broadcast stormcontrol, porfast (Edge port) and bpdguard
> > automatically on in all edge ports. But I do not run bpdufilter,
> > this way accidentally created loops should be visible by receiving
> > our own BPDU back and port going to errdisable because of that, and
> > all other cases, we'll have to hope that stormcontrol catches it.
> >  In my opinion cisco is lacking some elementary L2 security features,
> > like not being able to limit MAC addresses per port, without also
> > having port-security on and also ability to limit unknown 
> > unicast per port.
> > 
> > -- 
> >   ++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/

-- 
  ++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/