[c-nsp] 7600 Questions

[Fred Reimer]

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: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Oliver Boehmer
(oboehmer)
Sent: Friday, March 28, 2008 2:41 AM
To: Justin Shore; Mikael Abrahamsson
Cc: user user; cisco-nsp at puck.nether.net
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  cisco-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3080 bytes
Desc: not available
Url : https://puck.nether.net/pipermail/cisco-nsp/attachments/20080328/8ccf4a3f/attachment.bin