CoPP (Control Plane Policing)

Lessons Discussion
21

Hello Brahim

Let’s take a look at this command as an example:

R1(config-pmap-c)#police cir 8000 conform-action transmit exceed-action drop

When this policy map is applied, what will happen is:

  • as long as the data rate of arriving data is less than 8000 bits per second, the packets will be permitted.
  • if the arriving data exceeds a rate of 8000 bits per second, then some packets will be dropped so that the rate remains below 8000 bits per second
  • once the rate falls below 8000 bits per second once again, all packets will be transmitted.

I hope this has been helpful!

Laz

1 Like
22

Thank you so much, it’s helpful
I <3 networklessons :raised_hand:

1 Like
23

Hi Everyone, I just have one question. is there any difference between these two statements?

police cir 8000 conform-action transmit exceed-action drop

police 8000 conform-action transmit exceed-action drop

What difference makes using the CIR and not using it?

Thanks!

1 Like
24

Hello Anderson

That’s a good question. Looking at various Cisco documentations, I must conclude that there is no difference in either choice. The following Cisco command reference includes various options for how to use the police command depending upon whether it is in policy-map class configuration mode, whether you are specifying a percentage, or whether you are creating a per-interface policer.
https://www.cisco.com/c/en/us/td/docs/ios/qos/command/reference/qos_book/qos_n1.html#wp1060117

Some use cir others don’t. Others can use either or. When both can be used, the CIR is called CIR, while the value in bps is called the target bandwidth, or the average bandwidth.

Now I have found this Cisco documentation as well, which seems to support my suspicions:

which states that:

For the following examples, we set police to 10 Mbps, conform action to transmit (default), and exceed action to drop (default). At a “high” level we have three variants of the police command that achieve the same result: police value , police cir value , and police rate value . This set of variants is equivalent to: police [cir|rate] value , where cir and rate are optional. With a rate of 10 Mbps, we can build the following command: police [cir|rate] 10m .

Now the big question is why has Cisco done this? Isn’t it confusing? Luckily, the tell us int he same document that:

The variations have emerged in different Cisco IOS software releases over time and as software trains have merged. Within the same software release, three equivalent variants exist. To avoid backwards compatibility issues, we decided to retain the variants. Please note, however, that the software implementing the policing is identical regardless of the CLI variant used.

Hmm… I learned something new today. :sunglasses:

I hope this has been helpful for you too!

Laz

1 Like
25

Thank you very much for the clarification :+1:

1 Like
26

Hi Laz,

pretty sick here with Covid been 7 days now and today first day even able to focus enough to study a little bit. Hopefully on the downhill part now because pretty much sucks.

My questions is about your answer and when this theory you have been talking about here is implemented. By theory I mean you state that it does not reach the CPU but I would like to push a big deeper into specifics.

does it skip the CPU if its even listed? even if its transmit when exceeds? or does it only apply this rule about the CPU when you drop the packet.

Logically I was thinking the later that it only stops it from hitting the CPU when is dropped due to exceeding not just because its listed.

However, from reading the conversation I am not able to discern that for sure.

Thanks,

27

Hello Brian

Hope you feel better soon!

The Cisco documentation I posted before clarifies how and when CoPP takes place. CoPP is used to filter control traffic that is destined to be processed by the CPU. It will reach the CPU if it is permitted by the CoPP policies, and will be dropped if it is denied by those policies. CoPP is also capable of rate-limiting such traffic too, so it can permit or deny based on that as well.

The mentioned documentation states the following:

However, unlike rACLs that only apply to receive destination IP packets, CoPP applies to all packets that punt to the route processor for handling. CoPP therefore covers not only receive destination IP packets, it also exceptions IP packets and non-IP packets. In addition, CoPP is implemented using the Modular QoS CLI (MQC) framework for policy construction. In this way, in addition to simply permit and deny functions, specific packets may be permitted but rate-limited.

I’m not sure if I answered your question sufficiently, but let me know if you have any further inquiries.

I hope this has been helpful!

Laz

28

Hi

I didnt’ understand how analize the bit rate policed by the class-map.

If on H1 I do ping 192.168.1.1 repeat 15, only one packet will be dropped.

copp

Can you help me to understand how can I know that 1710 bytes are policed even if the cir is configured as 8000 ?

Thanks

29

Hello Giovanni

The bit rate policed by the class map is 8000 bits per second. What the show command you shared is showing is the total number of bytes that have been matched since the class-map was created and applied, or since the counters were last reset. So simply saying that 15 packets of 1710 bytes were examined by the class map and only one was dropped does not give us a full picture of the CIR. We don’t know over how much time this took place.

However what we do know is that at some point during the sending of those pings, the total bitrate did momentarily exceed 8000 bps, which is why one packet was dropped.

I hope this has been helpful!

Laz

1 Like
30

Hello rene! In which case would the policy-map be applied to the output address in the control-plane (service-policy output CoPP) ? Could you give me an example please.

I have observed that the policy-map can be applied to a network interface (Gigabit), does it make sense to do that?

thanks!

31

Hello Bruce

In the lesson, Rene enabled the policy-map under the service-policy configuration. Whenever this is done, control plane policing is enabled. Notice what the syslog message says:

%CP-5-FEATURE: Control-plane Policing feature enabled on Control plane aggregate path

The “aggregate path” is essentially all traffic destined to, or sent from any active interface of the router.

Obviously, the input or output keywords determine what traffic is actually being policed. So when would you use the output keyword? Well, remember that control plane policing limits the traffic to and from the router. If you have EIGRP or OSPF running, and you want to limit the number of update messages that may exit a particularly slow link, you can use CoPP for this purpose.

Yes, you can apply a policy map to an interface, but that will only affect user traffic and not control traffic (traffic destined to or sent from the router itself). In order to achieve CoPP, you need to apply the policy map under the control-plane configuration mode.

I hope this has been helpful!

Laz

2 Likes
32

Muchas gracias por su respuesta.
Saludos

1 Like
33

Hi,
I’ve build this BGP lab.

copp_ipv6_lab

I’ve configured CoPP on R2 like this.

ipv6 access-list BGP
 permit tcp 2001::/64 any eq bgp
!
class-map match-all BGP_CLASS
 match access-group name BGP
!         
policy-map COPP
 class BGP_CLASS
  drop    
!        
!         
control-plane
 service-policy input COPP
!

But BGP peering still form with R1, and bgp traffic is not dropped by R2.
Why this happens?

Thanks.

34

Hello Giovanni

Control Plane Policing will apply its filtering to the source and destination addresses of the actual BGP message packets being exchanged, and not of the prefixes being exchanged. This means that if you want to filter BGP messages, you must filter using the IP or IPv6 addresses used to create the BGP peering. By default, those addresses should be the IP addresses of the physical interfaces interconnecting the devices, unless you used the neighbor update-source command to change that address.

So if you want to filter BGP messages, you should indicate the BGP peer addresses in your access list and not the addresses of the loopbacks you have created.

I hope this has been helpful!

Laz

2 Likes
35

HI
I found this post that explain the difference between CoPP and CPPr, with example of configurations.

36

Hello Giovanni

That’s a great resource, thanks for sharing!

Laz

37

Hello,

Are Telnet,ssh,SNMP belong to control plane or MGMT plane, if it is MGMT plane protocol then why we have to limit its packets in the control plane, could you please explain that ?

38

Hello Ahmedlmad

First of all let’s clarify some terminology. As far as networking goes, there are two “planes:” The control plane and the user plane.

The control plane refers to communication that takes place by protocols between networking devices for the purpose of enabling a network to function. OSPF, EIGRP, and BGP are routing protocols that operate exclusively on the control plane. Similarly, STP, CDP, DTP, VTP, and others are also control plane protocols. Other protocols such as FTP, HTTP, IMAP, and POP3 have control plane components that are used to communicate between servers and hosts to enable their functionality. These protocols also have a user plane component as well.

The user plane refers to communication that carries actual user data. The contents of the email that you sent that’s being routed over the Internet is user plane communication. Similarly, the web site you viewed, or your voice and video being sent over the network from your video telephone call is also user plane.

Another way to say the same thing is that control plane traffic has the network device itself (router, switch, firewall, etc) as the source and destination of the traffic. User plane traffic is usually transient traffic through those network devices, and is destined for other hosts.

Now we sometimes use the term “management plane” to refer to those mechanisms used to manage a network. Among those, we have CLI connectivity using SSH and Telnet and monitoring protocols such as SNMP. The management plane is not in the same category as the user and control planes, so it is not mutually exclusive with those other two. Although it sounds the same, it is a different entity.

Now having said that Telnet and SSH have a control plane component as well as a user plane component. The user plane component is composed of the actual characters that you type and is being sent over the network as bits, as well as the responses to the prompts you see on the screen. Similarly, the control plane functions of these protocols involve dealing with encryption, authentication, and successful session management. Similarly, SNMP also has a control plane and user plane component, where the control plane communication has to do with the coordination between the server and the client, while the user plane data is the actual SNMP trap information that is being sent from devices to the server.

So getting to your question, why do we use CoPP to limit the packets of these protocols? Because we are limiting the traffic generated by the control plane components of those protocols.

I hope this has been helpful!

Laz

2 Likes
39

Hello!

My apologies if this has already been answered redundantly in the forums, but I’m currently studying for my ENARSI and I have a question regarding CoPP.

I understand the configuration aspect of it, but in a live production environment, how would you monitor a device locally (a router in this case) to check, or look for a specific traffic type which might be bogging down the CPU so that you could use that information to build your CoPP policy?

Thanks!

Anthony

40

Hello Anthony

That’s an excellent question! There are generally two aspects that must be followed when it comes to implementing CoPP. You must implement CoPP both proactively, as well as reactively.

When you configure proactively, what I mean is that we must always implement CoPP features that are considered best practice before deploying any device on a production network. Some devices, such as those in the Nexus series, have CoPP features preconfigured by default based on best practices, to protect from potentially harmful network traffic patterns or attacks. Cisco has a multitude of guides on what those CoPP features should be. A simple search for “cisco copp best practices” should give you a lot of results, and you can also indicate the platform that you are using as well.

Now once the proactive features are configured, you must work reactively to respond to any further anomalous behaviors you may encounter. Having implemented the proactive component should minimize the need for any reactive activities. However there will always be something that will need some response, that’s where the reactive part comes in, and I think this is what your question is focusing on. So how do we do that?

The process is by no means trivial. It often involves an in-depth analysis of the traffic that traverses your device. This analysis can be done using some CLI commands to sample particular CoPP behaviors. For example, based on this Cisco documentation, the show policy-map control-plane command displays dynamic information about the actual policies applied, giving you a snapshot of the situation at any particular point in time.

Alternatively, a more comprehensive approach would be to use monitoring tools such as NetFlow, SNMP, and syslog, in conjunction with a network monitoring system, to obtain a historical view of network traffic and behaviors.

Like I said before, it’s by no means trivial, but going through this process will give you a clearer picture of what kinds of behaviors can be harmful, in order to determine what countermeasures you should take to resolve them.

I hope this has been helpful!

Laz

1 Like