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:[EMAIL PROTECTED] > > Sent: Friday, February 01, 2008 1:05 PM > > To: Michel Renfer > > Cc: [email protected] > > 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 [email protected] > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
