Well, it's kind of both: "CoPP is actually applied at two different levels on the Cisco Catalyst 6500 Series. The first level is the hardware-based forwarding engine mitigation, and the second level is the software CoPP. Forwarding engines are programmed with the same global CoPP policy even though they each police traffic independently, so the route processor CPU could ultimately be presented N times the configured traffic rate, where N denotes the number of forwarding engines (active PFCs and DFCs) present in a Cisco Catalyst 6500 Series chassis. In Figure 3, after each forwarding engine has independently mitigated a line-rate attack in hardware, CoPP is enforced in software at interrupt level to make sure that only the exact rate configured in the control-plane policy is processed by the route processor. This should be taken into account when configuring a control-plane policer."
Hardware will take care of most of it, but it still does software policing. Even if you don't have many ingress points on a system (multiple DFC's and the central PFC) my understanding is that software must still "re-police" the traffic once the hardware is done with it. That can, I suppose, cause issues depending on how you have it configured. If there are multiple ingress points, say during a DDoS attack, then depending on how many it could cause issues. Here's another doc that explains CoPP on various platforms: http://www.cisco.com/en/US/prod/collateral/iosswrel/ps8802/ps6970/ps1838/pro d_white_paper0900aecd804ac831.pdf Some other points from that document: "Omitting the policy parameters in a class causes the class to be handled by software-based CoPP. Use the police command and set the policy parameters to ensure the class is handled by hardware-based CoPP. "With PFC3A, egress QoS and CoPP cannot be configured at the same time. In this situation, CoPP is performed in software, and a warning message is generated. "In the rare situation where a large QoS configuration is being used, it is possible that the system may run out of TCAM space. When this scenario occurs, CoPP may be performed in software." HTH, Fred Reimer, CISSP, CCNP, CQS-VPN, CQS-ISS Senior Network Engineer Coleman Technologies, Inc. 954-298-1697 -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Oliver Boehmer (oboehmer) Sent: Friday, March 28, 2008 2:41 AM To: Justin Shore; Mikael Abrahamsson Cc: user user; [email protected] Subject: Re: [c-nsp] 7600 Questions Justin Shore <> wrote on Friday, March 28, 2008 4:31 AM: > Mikael Abrahamsson wrote: >> On Thu, 27 Mar 2008, Justin Shore wrote: >> >>> Also, you should skip the Sup720-3BXL and get the RSP720-3CXL for >>> the same $$. And you should also get your 67xx linecards with DFCs >>> that match the Sup as well. It's worth the added expense. >> >> Why do you think that it's worth the added expense initially? >> >> I'd say it's worth it when you start to approach 5-10MPPS (due to CFC >> worst case limit of ~15 MPPS) but not before. > > It depends on how you're using your linecards. For some people it's a > matter of the performance capabilities of the FE. For anyone with a > 6500/7600 carrying full Internet tables or having their chassis > publicly accessible on the Internet, it's a matter of offloading CoPP > onto the DFC. Otherwise CoPP happens in software on the MSFC. You > may in fact be less susceptible to being DoSed without CoPP enabled > in chassis without DFCs. Otherwise you're opening up a path straight > to the CPU. I don't think this is true. CoPP on the 6500/7600 is implemented in hardware (assuming "mls qos" is enabled): on the PFC within the Sup as well as on the DFCs (if there are any). Please take a look at the CoPP chapter in http://www.cisco.com/en/US/prod/collateral/switches/ps5718/ps708/prod_wh ite_paper0900aecd802ca5d6.html which describes the CoPP architecture on this platform. oli _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
