[c-nsp] ARP flooding prevention

[Peter Rathlev]

Hi Michel,

Using CoPP protects the RP, i.e. traffic that the PFC decides has to be
punted to the MSFC. Here's a simplified and somewhat wrong picture of
how the forwarding paths work:

Interfaces                          RP

Gi4/1 ------\   +-----+   CoPP   +------+
Gi4/2 -------+--| PFC |----------| MSFC |
GE3/1/2 ----/   +-----+          +------+

Decisions about hardware forwarding, made by the PFC, never reaches the
MSFC. If the PFC cannot decide how to forward it though, it sends the
packets along the "control-plane" to the MSFC. (This is not entirely
correct terminology, but it should be okay for this purpose.)

This "punting", as it's called, is what can be policed with CoPP. Things
like ARP lookup, routing protocol traffic, ICMP packets to the RP (e.g.
pinging an interface address), VTY access, logging, non hardware
assisted tunnels and so on are all examples of things the PFC can't
handle by itself and has to have the MSFC do. It's the PFC doing the
CoPP, so it's done "in hardware" and what is policed does not stress the
RP of course.

Regarding your question: Yes, the PFC can also do policing per
interface. You can create policies similar to the CoPP policies and
attach them to the interfaces. You can of course also use simple
access-lists if you just want to block something specific.

Most of the things you can do in service policies are done in hardware,
but beware that some types of policies (e.g. weird policy based routing
or other things that won't fit in the TCAM) results in more punting and
thus just make things worse.

You can read more about Sup720 QoS Policing with interface examples and
much more here:

http://www.cisco.com/en/US/customer/products/hw/switches/ps700/products_
tech_note09186a00801c8c4b.shtml

http://tinyurl.com/c8el4

Regards,
Peter


On Fri, 2008-02-01 at 13:49 +0100, Michel Renfer wrote:
> Ok, thanks all for feedback. It seems that the configurations are always
> generic for the whole router. It is possible to add limiting only for a
> specific interfaces?
> 
> cheers,
> michel
> 
> > -----Original Message-----
> > From: Peter Rathlev [mailto:peter at rathlev.dk]
> > Sent: Friday, February 01, 2008 1:05 PM
> > To: Michel Renfer
> > Cc: cisco-nsp at puck.nether.net
> > Subject: Re: [c-nsp] ARP flooding prevention
> > 
> > Agreed, CoPP with a service-policy and maybe also using the "mls
> > rate-limit unicast cef glean <pps>" and so on.
> > 
> > Just remember that to limit these things is to limit the services that
> > the supervisor is meant to deliver. You can easily put yourself in a
> > situation where the DoS scenario becomes a problem earlier because of
> > your rate-limiting, and then it's irrelevant that your supervisor is
> > only at 50% cpu.
> > 
> > Look at this for CoPP for Sup720:
> >
> http://www.cisco.com/en/US/customer/products/sw/iosswrel/ps1838/product
> > s_feature_guide09186a008052446b.html
> > http://tinyurl.com/9sutt
> > 
> > And for MLS rate-limiting for Sup720:
> >
> http://www.cisco.com/en/US/customer/prod/collateral/switches/ps5718/ps7
> > 08/prod_white_paper0900aecd802ca5d6.html
> > http://tinyurl.com/297d48
> _______________________________________________
> 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/