Cisco CoPP

Cisco CoPP Best practices

Cisco CoPP Cat6k

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


          cir 10000000 bps, bc 312500 bytes, be 312500 bytes

        conformed 4646556 packets, 411683229 bytes; actions:


        exceeded 0 packets, 0 bytes; actions:


        violated 0 packets, 0 bytes; actions:


        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


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).