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<cgrif...@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 cgrif...@ufl.edu
Sr. Network Engineer - CCNP Phone: (352) 273-1051
CNS - Network Services Fax: (352) 392-9440
University of Florida/FLR Gainesville, FL 32611
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
