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

[Chris Griffin]

Yes, much confusion, even in the same document:

http://www.cisco.com/en/US/docs/routers/7600/ios/12.2SR/configuration/guide/dos.html

"CoPP does not support ARP policies. ARP policing mechanisms provide 
protection against ARP storms. "

But further on in the same document:

"Layer 2 Protocols—Traffic used for address resolution protocol (ARP). 
Excessive ARP packets can potentially monopolize MSFC resources, 
starving other important processes; CoPP can be used to rate limit ARP 
packets to prevent this situation. Currently, ARP is the only Layer 2 
protocol that can be specifically classified using the match protocol 
classification criteria."



The testing I did was about a year ago, but as I recall, with our 
default deny any policy, traffic to hosts with no current ARP adjacency 
would fail.  As soon as the glean rate limiter was enabled, traffic 
started to flow normally.  Further tested demonstrated the limitation 
with ACL behavior and due our heavy use of outbound ACLs, we elected to 
track each interface IP in an object group and apply heavy deny policies 
to those bits while allowing glean and other unclassified traffic to hit 
a rate limited permit policy.

Tnx
Chris

On 3/23/2010 8:24 AM, Tim Durack wrote:
> 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.
>

-- 
Chris Griffin                           cgriffin at ufl.edu
Sr. Network Engineer - CCNP             Phone: (352) 273-1051
CNS - Network Services                  Fax:   (352) 392-9440
University of Florida/FLR               Gainesville, FL 32611