Control Plane Policing (CoPP) Tutorial

The IP traffic managed by a device can be divided into four distinct, logical groups:

1. Data plane packets: user-generated packets that are always forwarded by network devices to other end-station devices.

2. Services plane packets: a special case of data plane packets, services plane packets are also user-generated packets that are also forwarded by network devices to other hosts, but that require high-touch handling by the network device (above and beyond normal, destination IP address-based forwarding) to forward the packet. Examples of high-touch handling include such functions as GRE encapsulation, QoS, MPLS VPNs, and SSL/IPsec encryption/decryption…

As we see in the picture below, some traffic of the services plane is “punted” (or “pulled”) to handle in the CPU while other is treated by CEF only. “Punt” is often used to describe the action of moving a packet from the fast path (CEF) to the route processor for handling.

3. Control plane packets: Network device generated or received packets that are used for the creation and operation of the network itself. Control plane packets are always handled by the CPU in the network device route processor. Examples include packets of routing protocols like OSPF, EIGRP, BGP or some other non-routing protocols like CDP…

4. Management plane packets: packets that are used to manage the network. Examples include protocols such as Telnet, SSH, SNMP, NTP…

In normal operation, most of the packets are handled by the routers and switches are data plane packets and the network devices are optimized to handle these packets. Unfortunately, control and management packets are not handled in the route processor (which means router and switch processor) as efficiently as data plane packets. The route processor is critical to network operation. Therefore any service disruption or security compromise to the route processor, and hence the control and management planes, can result in network outages that impact regular operations. An attacker can attack the route processor with these types of traffic which results in devastating to network stability and availability. In fact, some network misconfigurations, software bugs can also overwhelm route processor as well.

Packets handled by the main CPU, referred to as control plane traffic, typically include the following: + Routing protocols. + Packets destined to the local IP address of the router. + Packets from network management protocols, such as Simple Network Management Protocol (SNMP). + Interactive access protocols, such as Secure Shell (SSH) and Telnet. + Other protocols, such as Internet Control Message Protocol (ICMP), or IP options, might also require handling by the switch CPU. + Layer 2 packets such as bridge protocol data unit (BPDU), Cisco Discovery Protocol (CDP), DOT1X, and so on. + Layer 3 protocols such as authentication, authorization, and accounting (AAA), syslog, Network Time Protocol (NTP), Internet Security Association and Key Management Protocol (ISAKMP), Resource Reservation Protocol (RSVP), and so on.

Note: In the figure above, we see some Services plane packets go through CPU instead of CEF. They are special packets (for example, GRE, IPsec, or MPLS VPN) which require to be handled by different software elements in the CPU.

In order to protect route processor, we can use traditional interface access-list but there are some disadvantages:

+ Can only be applied at the interface level. So an access-list must be applied to every individual interface to which the policy needs to be applied. On large routers or switches with many interfaces, this can be an onerous task.
+ An access-list must monitor all coming or leaving packets, not just control plane packets so many resources on the network device to investigate data plane packets are wasted.
+ Can only permit or deny IP packets. It cannot use to rate-limit the traffic.

What is CoPP?

Control Plane Policing (CoPP) is the route processor protection mechanism used in Cisco network devices. The Control Plane Policing (CoPP) feature allows users to configure a QoS filter that only manages the traffic destined to the CPU of Cisco IOS routers and switches. It provides filtering and rate limiting capabilities for control & management plane packets.

Configuration CoPP

Let’s see an example of configuring CoPP before explaining them. This CoPP configuration will rate-limit ping (ICMP) packets to 8000 bits per second (bps):

access-list 100 permit icmp any any
!
class-map CoPP_ICMP
 match access-group 100
!
policy-map CHECK_ICMP
 class CoPP_ICMP
  police 8000 
   conform-action transmit 
   exceed-action drop
!
control-plane
 service-policy input CHECK_ICMP

Ignore the first line with an access-list, we see there are three steps to configure a CoPP:

Step 1: Create a class-map to identify the traffic we want to monitor. It usually includes one or more “match” statements. Each “match” statement is usually based on an access-list. Notice that the name of each class is case-sensitive.
Step 2: Create a policy-map to define what to do with the identified traffic. We can allow (transmit), drop or rate-limit (police) it.
Step 3: Create a service-policy to tell where to apply the policy-map. For CoPP, we must apply under the control plane virtual interface by using the control-plane global command -> only traffic destined for the route processor will be affected by the CoPP policy.

The three steps above are called “Modular QoS CLI configuration” (MQC), a structure that allows users to create traffic polices and attach these polices to interfaces.

The syntax of class-map, policy-map and police commands are shown below:

Router(config)# class-map [match-any | match-all] class-map-name Router(config-cmap)# match [access-group | protocol | ip prec | ip dscp] ! Router(config)# policy-map {policy_map_name} Router(config-pmap)# class {class-map-name} Router(config-pmap-c)#police {rate-bps | cir {cir-bps [burst-bytes] [bc burst-bytes]| percent percent [burst-ms] [bc burst-ms]} } Router(config-pmap-c)#conform-action {drop | transmit} Router(config-pmap-c)#exceed-action {drop | transmit}

Notes:

For the command “police …”:
– For rate-bps, specify average traffic rate in bits per second (b/s). The range is 64000 to 10000000000.
– For cir cir-bps, specify a committed information rate (CIR) in bits per second (b/s). The range is 32000 to 10000000000.
– For burst-bytes (optional), specify the normal burst size in bytes, which indicates how much the cir can be exceeded. The range is 8000 to 16000000.
– For bc burst-bytes (optional), specify the conformed burst (bc) or the number of acceptable burst bytes. The range is 8000 to 16000000.
– For burst-ms (optional), enter the conform burst size in milliseconds. The range is 1 to 2000. The default is 250 ms.
– For bc burst-ms (optional), specify the conformed burst (bc) in milliseconds. The range is 1 to 2000.

The “conform-action” specifies the action to take on packets that conform to the rate limit while the “exceed-action” specifies the action to be taken on packets when the packet rate is greater than the rate specified in the maximum-burst-bytes argument. Drop is the default action for traffic that exceeds or violates the committed police rate.

We can write “conform-action” and “exceed-action” in the same line with “police” command (i.e: “police 8000 conform-action transmit exceed-action drop” but we prefer to separate them for easier reading).

If you test the configuration above on a router and ping to any interface of the router from another device then we will see this result:

The “show policy-map control-plane” can be used to verify that the ping packets were matched by our policy-map:

To clear CoPP policy-map statistics, use the clear control-plane * command:

Router# clear control-plane *

Advanced configuration of CoPP

Packets that match a deny rule are excluded from that class and cascade to the next class (if one exists) for classification. This is in contrast to packets matching a permit rule, which are then included in that class and no further comparisons are performed. Let’s see an example:

ip access-list extended CoPP_Telnet
 deny tcp host 192.168.1.1 any eq telnet      ! Allow this traffic unconstrained
 permit tcp any any eq telnet                 ! Rate-limit this traffic
!
class-map Telnet_class
 match access-group name CoPP_Telnet
!
policy-map CoPP_Telnet_policy
 class Telnet_class
  police cir 8000
   conform-action transmit
   exceed-action drop
!
control-plane
 service-policy input CoPP_Telnet_policy
!

This CoPP allows host with source address of 192.168.1.1 to forward Telnet packets to the control plane without constraint while all remaining Telnet packets are policed at the specified rate. A strange thing here is we have to “deny” source 192.168.1.1 in the ACL so that it is excluded from “class-map Telnet_class”. It will be matched by the “class-default” which is implemented implicitly at the end of the policy-map. This default class will match all the traffic and allows them by default.

When more than one class of traffic is defined within a policy-map, the order of classes is important, as traffic is compared against successive classes, top-down, until a match is recorded. Once a packet has matched a class, no further comparisons are made. If no match is found after processing all classes, packets automatically match the always-defined class, class-default. The class class-default is special in MQC because it is always automatically placed at the end of every policy map. Match criteria cannot be configured for class-default because it automatically includes an implied match for all packets. Only a traffic policy can be configured for class-default.

In each class-map, we can use “match-all” or “match-any” if there are more than one match statement.
+ match-any means only one of the match statements needs to be met, and
+ match-all means all the match statements must be met to bind the packet to the class. Therefore “match-any” is equivalent to “OR” operator while “match-all” is equivalent to “AND” operator in programming. If neither match-all nor match-any is specified, which defaults to match-all.

In the example below, traffic must match both ACLs 10 & 20 to be filtered:

class-map match-all BGP
 match access-group 10
 match access-group 20

Reference: https://tools.cisco.com/security/center/resources/copp_best_practices

+ When you’re constructing ACLs to be used for CoPP, traffic that is “permitted” translates to traffic that will be inspected by CoPP, and traffic that is “denied” translates to traffic that CoPP bypasses.

If we apply the service-policy in output direction with the “service-policy output {policy-name}” command, only traffic DESTINED TO or GENERATED from control plane of the local device will be filtered. With this command, the device will also go into silent mode, which will not generate an error when discarding a packet.