CoPP (Control Plane Policing)

This topic is to discuss the following lesson:

1 Like


Interesting topic and good explanation.

From what I understand with control plane policing and protection we create a filter between the interface and the CPU to filter packets handled by the CPU of the router.

Correct me if i ’ m wrong but with your example

which is enabling policing for incoming traffic to the router, an incoming ssh packet for example to the router will not be dropped but will not be under inspection either .

Is this correct?



Hello Kostas

Yes, that is correct. We can filter the number of packets destined to the router itself, and thus, we limit the number of packets that the CPU must process. Keep in mind however that even data plane traffic uses CPU resources (for decapsulating, routing, re-encapsulating etc) as well.

In this lesson, Rene is matching control plane traffic for ICMP, Telnet, OSPF and HSRP. No SSH packets will be matched. This means that no policing will occur on any SSH packets. Only packets that match the configured policy map will be policed.

Even so, the conform and exceed actions are all set to transmit, so there is no policing going on based on this configuration. However, the number of packets that do conform and do exceed can be examined and the bps value and the exceed action can then be adjusted accordingly. Rene explains why this is done in the lesson:

In the policy-map, I add policers for 8000 bps and the conform-action and exceed-action are both set to transmit. These policers will never drop anything but there is a good reason I configure it like this.

When you configure CoPP for the first time, you don’t know how much packets you receive for each protocol. There is a risk that you deny legitimate traffic. It’s best to permit everything. Once you know how much packets are exceeding, change the values and set the exceed action to drop.

I hope this has been helpful!


1 Like


Thank you for the explanation.

I was reading about CoPP and I read on a forum an example on why to use it.

It was mentioned that if for example you want to filter traffic to an outside interface with an access list , and someone manage to send a lot of traffic to that interface , even though the traffic will be dropped as it matches the drop action in the access list ,this will have an impact on CPU .

On the other hand with CoPP you will have a silent drop meaning packets will never reach CPU .

In this example applying an access list to an interface for this purpose isn’t the same as CoPP ?

Or it is correct as an example?

Moreover ,do Access lists sent traffic to CPU while receive Access Lists don’t ?

Thanks again


Geia sou (hello) Kostas

This is a very important aspect that you bring up. There are several things that come into play.

Under normal operation, a networking device that receives control plane traffic will “punt” the packet to the CPU to be processed. The term “punt” is used to describe the action of moving a packet from the fast path to the route processor or CPU for handling. CoPP will block the packet from even reaching the CPU therefore there is no impact on the CPU itself. Take a look at the following diagram taken from this Cisco Documentation:
CoPP functions at the location that is indicated. Packets that match the criteria will never reach the CPU.

Now all of this presupposes that the platform and IOS we are talking about does indeed have the architecture and feature set described. Lower end devices with a single CPU and no specialize ASICs may not support such a feature and may require all packets to be examined and processed by the CPU.

Now if you just apply an ACL to an interface to block specific traffic, then you are going to use more CPU power because the CPU itself is going to be processing those matches. However, keep in mind that the impact on the CPU of ACLs is typically minimal especially on today’s modern network devices. It still save some CPU power because the packet is dropped after simply examining its IP header. If it wasn’t dropped then the CPU would be used extensively to find a matching entry in the routing table and to send it out the appropriate interface, or, in the case of control plane traffic, will receive the packet and so whatever it has to do with it. This is typically much more CPU intensive than a simple match statement on an ACL.

As for the rACLs, this Cisco documentation (in the Introduction section) talks very clearly about these access lists and how they operate.

I hope this has been helpful!


1 Like

Thank you so much for your response.
The documentation really helped me a lot as well.

1 Like


I would like to know if there is similar command like “show policy-map control-plane input class ICMP” that shows the “comformed” and “exceeded” packets, but on nexus c7010 device. I was trying to find out, but i couldn’t find something similar to this command you are using. Thank you in advance.

Hi Angelos,

I don’t have a 7000 to test with but on my 5548 (7.3(1)N1), it does show up with this command:

NX1# show policy-map interface control-plane 
Control Plane

  service-policy  input: copp-system-policy-customized

    class-map copp-system-class-igmp (match-any)
      match protocol igmp
      police cir 1024 kbps , bc 65535 bytes 
        conformed 0 bytes; action: transmit 
        violated 0 bytes;
    class-map copp-system-class-pim-hello (match-any)
      match protocol pim
      police cir 1024 kbps , bc 4800000 bytes 
        conformed 0 bytes; action: transmit 
        violated 0 bytes;
    class-map copp-system-class-bridging (match-any)
      match protocol bridging
      police cir 20000 kbps , bc 4800000 bytes 
        conformed 0 bytes; action: transmit 
        violated 0 bytes;

It doesn’t show up on the 7000 like this?