CoPP (Control Plane Policing)

This topic is to discuss the following lesson:

1 Like

Hello

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?

Thanks

Kostas

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!

Laz

2 Likes

Hello

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

Kostas

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:
image
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!

Laz

3 Likes

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

1 Like

Hello,

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?

Rene

Hi Guys,

I understand that there is a IP prec class for control traffic but how would you typically implement this?

Also, is it also best practice to provide QoS for your management plane traffic too?
Thanks,
Gareth.

Hello Gareth

What you are describing is Control Plane Protection (CPPr) which is considered an extension of Control Plane Policing (CoPP). Cisco puts it this way:

The Control Plane Protection feature is an extension of the policing functionality provided by the existing Control-Plane Policing feature. The Control-Plane Policing feature allows Quality of Service (QoS) policing of aggregate control-plane traffic destined to the route processor. The Control Plane Protection feature extends this policing functionality by allowing finer policing granularity.

CoPP is covered in the CoPP lesson, but CPPr is not covered in any lesson here. You can find out more about it at the following Cisco documentation:

I hope this has been helpful!

Laz

Thanks Laz - most helpful as always.

1 Like

Please help as I am trying to use CoPP to deny in coming NTP query. The command below doesn’t work, is there anything missing?

class-map match-all CLASS-MAP-NTP
match access-group name DENY_NTP

policy-map CoPP-Policy
class CLASS-MAP-NTP
 
ip access-list extended DENY_NTP
 deny udp any any eq ntp

control-plane
 service-policy input CoPP-Policy

Hello Kenneth

Your access list has a deny statement for NTP packets, which means the class map will not match anything from the access list. The access list should have a permit statement.

I suggest you follow the steps in the following lesson:

The example in this lesson is for Telnet, ICMP, OSPF and HSRP traffic, but you can simply reproduce the same thing by replacing these with NTP information.

I hope this has been helpful!

Laz

Correct me if i am wrong, for access list I need to permit udp any any eq ntp so that the class map will be match and I added a ‘drop’ under policy-map CoPP-Policy so that it will drop all incoming NTP query? Thanks.

class-map match-all CLASS-MAP-NTP
 match access-group name DENY_NTP

policy-map CoPP-Policy
 class CLASS-MAP-NTP
   **drop**

ip access-list extended DENY_NTP
 **permit** udp any any eq ntp

Hello Kenneth

Yes, you are correct. The access lists should permit the traffic that you want to match, so that the class map that references that access list will match it. Then, in the policy map (that calls that class map) should then take the action that you want on that matched traffic. In your case, it would be to drop the traffic.

I hope this has been helpful!

Laz

1 Like

@ReneMolenaar
Can you do an example where you match ARP traffic and drop if it exceeds xxx pps

Thank you!

Hello Sine

In order to apply CoPP for ARP packets, you will not be able to use an access list, since ARP packets operate at Layer 2. However, you can create a class map that will match ARP packets using the following command:

R1(config)#class-map ARP
R1(config-cmap)#match protocol arp

You can then apply a policy-map like so to limit ARP pps at 10:

R1(config)#policy-map COPP
R1(config-pmap)#class ARP
R1(config-pmap-c)#police rate 10 pps conform-action transmit exceed-action drop
R1(config-pmap-c)#exit

You can then apply this policy-map as a service policy in the control plane configuration mode just like in the lesson.

You can find out more information about the required policing commands at the following Cisco link:

I hope this has been helpful!

Laz

2 Likes

Can you use the same “Class Map” for different “Policy Map.”?

What would happen if the Policy Map each has “police cir 1000k bc 1500” and the same “Class Map” for example, which policy would take effect?

Hello Jeffrey

Yes, it is possible to use the same class-map in two or more different policy maps. These are modular entities and are defined so that they can be reused, and mixed and matched in this way.

I’m not sure I understand this question. You mean if there were two policy maps with the config you mention, and the same class-map is used in both? Both would be used. But I think I’m not understanding the question. Can you clarify?

I hope this has been helpful!

Laz

Thank you for your lesson.
I have just one question, what represent CIR => cir 8000 bits
débit ? or that mean every 8000 bits will apply the action right?

Thank you,

Best regards,
Brahim