This topic is to discuss the following lesson:
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
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:
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
Thank you so much for your response.
The documentation really helped me a lot as well.
kostas
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.
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
@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
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