Cisco CoPP Best practices
Cisco CoPP Cat6k
http://events.cisco.hu/2014/techtorial/doc/lavarga_v1.0.pdf
Hi All,
Thanks for all the valuable input!
I wrote up a CoPPs policy, and deployed it in a non-limiting fasion
and monitored for a while. Once happy we enabled the policers and its
working fine, however the software counters are going up, and it’s not
clear to me why that is.
Further down is the config, immediately below is partial the output
from an example 7600 (as the CoPPs policy is quite long):
abr1#show policy-map control-plane input
Control Plane
Service-policy input: Control-Plane-Filter-In
Hardware Counters:
class-map: CoPP-Limit-and-Permit-Critical (match-any)
Match: access-group name CoPP-Limit-and-Permit-BGP
Match: access-group name CoPP-Limit-and-Permit-BGPv6
Match: access-group name CoPP-Limit-and-Permit-RSVP
Match: access-group name CoPP-Limit-and-Permit-LDP
Match: access-group name CoPP-Limit-and-Permit-OSPF
Match: access-group name CoPP-Limit-and-Permit-OSPFv3
Match: access-group name CoPP-Limit-and-Permit-HSRP
Match: access-group name CoPP-Limit-and-Permit-BFD
police :
10000000 bps 312000 limit 312000 extended limit
Earl in slot 6 :
631028621 bytes
5 minute offered rate 86968 bps
aggregate-forwarded 631028621 bytes action: transmit
exceeded 0 bytes action: transmit
aggregate-forward 79648 bps exceed 0 bps
Software Counters:
Class-map: CoPP-Limit-and-Permit-Critical (match-any)
4646556 packets, 411683229 bytes
5 minute offered rate 54000 bps, drop rate 0000 bps
Match: access-group name CoPP-Limit-and-Permit-BGP
4035626 packets, 367873184 bytes
5 minute rate 48000 bps
Match: access-group name CoPP-Limit-and-Permit-BGPv6
2101 packets, 174550 bytes
5 minute rate 0 bps
Match: access-group name CoPP-Limit-and-Permit-RSVP
0 packets, 0 bytes
5 minute rate 0 bps
Match: access-group name CoPP-Limit-and-Permit-LDP
173745 packets, 13108073 bytes
5 minute rate 1000 bps
Match: access-group name CoPP-Limit-and-Permit-OSPF
77045 packets, 8382206 bytes
5 minute rate 1000 bps
Match: access-group name CoPP-Limit-and-Permit-OSPFv3
0 packets, 0 bytes
5 minute rate 0 bps
Match: access-group name CoPP-Limit-and-Permit-HSRP
358039 packets, 22145216 bytes
5 minute rate 2000 bps
Match: access-group name CoPP-Limit-and-Permit-BFD
0 packets, 0 bytes
5 minute rate 0 bps
police:
cir 10000000 bps, bc 312500 bytes, be 312500 bytes
conformed 4646556 packets, 411683229 bytes; actions:
transmit
exceeded 0 packets, 0 bytes; actions:
transmit
violated 0 packets, 0 bytes; actions:
drop
conformed 54000 bps, exceeded 0000 bps, violated 0000 bps
I’m not sure why traffic like BGP would match into both the hardware
and software policiers, when its such a simple match statement (I am
assuming that because the packet count under the software counters is
much lower than the ACL match, so the rest were policied by
hardware?):
I am trying to write a CoPP template for some 7600s running as PEs. It
> would be handy if they were running a similar CoPP configuration to
> that on our Juniper PEs we are going to be connecting these 7600’s too
> so we have consistent CoPP across that domain of equally exposed
It’s not going to be consistent, CoPP does work, but can’t really compete with over decade newer Trio kit.
> CoPP on 7600’s can’t police ARP but one can use the MLS HWRL for that.
> The HWRLs can also handle other protocols like HSRP and CoPP can’t
> police multicast in hardware, so do people usually police ARP and HSRP
> using the MLS HWRLs instead of CoPP?
Pretty sure HSRP works just fine. For multicast, you just need to allow all multicast in CoPP (otherwise it’s processed by software CoPPP, which you don’t
want) and then limit in mls rate-limit.
> The HWRLs support other protocols too that ARE supported in CoPP in
> hardware, so are there any other protocols that people prefer to
> police using the HWRLs?
Example please, I cannot recall overlap.
> With regards to ACLs, do people really have giant access lists of
> peers they allow BGP to/from? The 7600 I am piloting this on has over
Yes. Two, one low rate for SYN and one for other BGP, alas. However if your master configuration data is not network, but database, then it does not really matter how complex or simple the network configuration is, as it’s generated automatically from database.
If it’s pure CLI jockey network, it can be a challenge.
But even this is isn’t as good as it should be, as each neighbour would need to have their own policer, like Cisco LPTS or Juniper ddos-protection can do.
But this is one of those things where you’ll rather carry a risk than overcomplicate the configuration.
> any any eq 179″ as above then I feel I need to police, unless I can
> guarantee at the edge I have filtered out traffic on TCP 179 from
> everywhere it shouldn’t be coming from. What approach to others take
> here? Why?
I have opted for simplicity, I have CoPP class for internal signalling stuff, which is critical, another for important customer/peer stuff, like BGP, and another for unimportant stuff (ping, udp traceroute…)
> What do people do with unusual traffic like IP fragments? I am
> discarding them. Thoughts?
If you can get away discarding fragments hitting control-plane, do it. If not, police it.
> What about packets with IP options set, I am allowing record-route
> only and dropping the rest. Thoughts?
No on expects IP options to work in the Internet, there is mls command to police them, I would do that, even for transit
> ICMP, I’m just proposing to allow the follow:
> ip access-list extended CoPP-Limit-and-Permit-ICMP permit icmp any
> any echo permit icmp any any echo-request permit icmp any any
> unreachable permit icmp any any ttl-exceeded permit icmp any any
> packet-too-big deny icmp any any
>
> Again, any thoughts there?
Never use ‘deny’ in PFC3 CoPP ACLs. It’s not needed, and it may not be supported and may cause negative match and stop of evaluation (i.e. won’t fall to next classs).
