[c-nsp] Sup720 CoPP, limits on CPU performance

Tim Durack tdurack at gmail.com
Tue Mar 23 08:24:00 EDT 2010


On Tue, Mar 23, 2010 at 7:29 AM, Chris Griffin <cgriffin at ufl.edu> wrote:
> Anything matching a fixed mls rate limit will bypass copp, which can be a
> useful technique to avoid having to account for glean traffic in your copp
> policies.  Be cautious however, you may get this error message (only on the
> console!) when enabling:
>
> %Packets requiring ARP resolution will be subject to the output ACLs of the
> input VLAN
>
> This basically results in all the glean traffic being subject to non-obvious
> ACL behavior.  This is apparently a limitation in some versions of the PFC
> 3B, but has been fixed in the 3C.  Funny thing is that in our experiments
> not all of our PFC3Bs do it, but based on the fact that we could be required
> to replace one with a version that does have this limitation, we elected to
> avoid using it.

Interesting.

The docs are somewhat confusing on the interaction between mls
rate-limiters and CoPP.

http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/ios/12.2SX/configuration/guide/copp.html

•PFC3 supports built-in special-case rate limiters, which are useful
for situations where an ACL cannot be used (for example, TTL, MTU, and
IP options). When you enable the special-case rate limiters, you
should be aware that the special-case rate limiters will override the
CoPP policy for packets matching the rate-limiter criteria.

http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/ios/12.2SX/configuration/guide/dos.html

•Rate limiters override the CoPP traffic.

http://www.cisco.com/en/US/prod/collateral/switches/ps5718/ps708/white_paper_c11_553261.html

• When combining CoPP and HWRL, HWRL always takes precedence over
CoPP; for example, if HWRL is applied in hardware, CoPP for the same
traffic can only be applied in software. The exception is for HWRL
that is applied after packet rewrite in hardware (for example, only
TTL=1 and MTU failure so far) since control packets are excluded from
this HWRL logic. In general, control plane packets hitting the bridge
adjacency are not affected by TTL and MTU rate limiting.

http://www.cisco.com/web/about/security/intelligence/coppwp_gs.html

"Figure 6. Relationship between Control Plane Policing and
Special-Case Rate-limiters for 6500/7600 Platforms" indicates that
traffic passing through mls rate-limiters proceeds to hit software
CoPP. So if I make a default deny for traffic not matching approved
classes, I would again affect glean traffic.

-- 
Tim:>



More information about the cisco-nsp mailing list