Control Plane Protection in Cisco IOS

CoPP – Control Plane Protection or better Control Plain Policing. It is the only option to make some sort of flood protection or QoS for traffic going to control plane.

In the router normal operation the most important traffic is control plain traffic. Control plane traffic is traffic originated on router itself by protocol services running on it, destined to other router device on the network. In order to run properly, routers need to speak with each other. They speak with each other by rules defined in protocols and protocols are running in shape of router services.

Examples for this kind of protocols are routing protocols like BGP, EIGRP, OSPF or some other non-routing protocols like CDP etc..

CoPP

Control Plane Policing is QoS applied on ingress sub-interfacess towards Route Processor

When router is making BGP neighbour adjacency with the neighbouring router, it means that both routers are running BGP protocol service on them. BGP service is generating control plane traffic, sending that traffic to BGP neighbour and receiving control plane traffic back from the neighbour.

Usage of Control Plane Protection is important on routers receiving heavy traffic of which to many packets are forwarded to Control Plane. In that case, we can filter traffic based on predefined priority classes that we are free to define based on our specific traffic pattern.

By using CoPP, we can make a part of control plane traffic prioritised so that it can be efficiently processed by control plane in timely manner. Some other less important control traffic will be dropped on the entrance to control plane or slowed down by using buffering. We can use QoS techniques in the entrance to Router Processor (showed in the image above), enabling us to drop or even better, to throttle some less important control traffic flows. In this way whole valid control plane traffic gets through but some flows slower that others.


Route Processor Virtual Interfaces

Control Plane Protection extends QoS feature to the control plane by considering the Route Processor to be additional virtual interface attached to the router. All traffic redirected to the Route Processor is classified into three categories corresponding to three sub-interfaces of the virtual interface:

1. Control-plane host sub-interface

This interface is receiving all control plane traffic that is destined for one of the router interfaces. This is usually management traffic and routing protocols traffic. Most control plane protection features operate on this sub-interface, so this sub-interface provides most features, such as policing, port filtering, and per-protocol queue thresholds.

Class-map type port-filter allows for automatically dropping of packets destined for the TCP/UDP ports not currently open in the router. The operating system automatically detects all open ports, and you can manually configure some exceptions. This can significantly reduce load on device CPU during flooding attacks.

If traffic destined to Route Processor is not TCP/UDP, that kind of control traffic ends up on the CEF exception sub-interface.

Per-protocol queue thresholds set selective queue limits for packets of different protocols, such as ICMP, BGP, OSPF, etc. We have in our example below policy-map ICMP_RATE_LIMIT which will catch all ICMP packets and do some rate policing on them.

2. Control-plane transit sub-interface

This sub-interface is handles transit IP traffic that is not able to be handled by faster hardware CEF mechanism. This usually happens when a packet must be routed out of Ethernet interface and there is no ARP mapping done already for that MAC. In this case we will be switching in the processor by making ARP lookup to find the next-hop MAC address.

3. Control-plane CEF exception sub-interface

Like the name says, packet that causes an exception in CEF switching ends up here. Example of this kind of traffic is non-IP traffic destined to router itself, CDP, OSPF updates, and ARP packets.


How Control Plane Protection works and how is configured

There are two ways of doing this. We can apply separate rate-limiting policy to any of the sub-interfaces or apply one aggregate policy for all sub-interfaces which is knows as classic control plane policing. Using both the sub-interface and aggregate policy is possible but can be unstable on some IOS versions thus is not recommended. In our configuration example below we will configure separate rate-limiting policy to each of the sub-interfaces.

Before packets reach one of specific control plane sub-interfaces, they are processed with more different ingress features. Packets are going through input access-list, uRP checks and aggregate control-plane policy if one is configured. After this, packets are forwarded to sub-interface-specific policy, the packets are then queued onto the respective interface input queue and handled via selective packet discard policy.


Configuration Example

Here’s the example of Control Plane Protection. I’ll just put the example here and the explanation, bullet by bullet at the bottom.

The class-map type port-filter is really cool. It allows to match some of the ports (like 2323 and 2424 in our example). The best part is that you are able to match all closed ports on the router dynamically and drop packets destined to non-listening ports before the router process them and responds with ICMP unreachable or TCP RST packet.

  • In the first part of the example above, we are blocking all closed ports except TCP 2323 and 2424.
class-map type port-filter match-all CLOSED_PORTS
  match closed-ports
  match not port tcp 2323
  match not port tcp 2424

policy-map type port-filter HOST_PORT_FILTER
  class CLOSED_PORTS
    drop
  • In the next part we matching ICMP traffic and limiting that traffic going toward the host sub-interface, which means to the Route Processor.
ip access-list extended ICMP
  permit icmp any any
 
class-map ICMP
  match access-group name ICMP
 
policy-map ICMP_RATE_LIMIT
  class ICMP
    police rate 10 pps burst 5 packets
  • Next example is checking transit fragmented traffic matched with an access-list. Fragmented transit traffic will be limited to 1000000 packet per second rate on the transit sub-interface with some burst.
ip access-list extended FRAGMENTS
  permit ip any any fragment
 
class-map FRAGMENTS
  match access-group name FRAGMENTS

policy-map TRANSIT_RATE_LIMIT
  class FRAGMENTS
  police rate 1000000 pps burst 200000 packets
  • At the end of the example all other packets resulting in CEF exceptions are limited to 400 packets per second.
policy-map CEF_EXCEPTION_RATE_LIMIT
  class class-default
  police rate 400 pps burst 20 packets
  • In the last few lines we are applying service policies to all three sub-interfaces. With this step we are actually applying the Control Plane Protection.
control-plane host
  service-policy input ICMP_RATE_LIMIT
  service-policy type port-filter input HOST_PORT_FILTER
 
control-plane transit
  service-policy input TRANSIT_RATE_LIMIT
 
control-plane cef-exception
  service-policy input CEF_EXCEPTION_RATE_LIMIT

 

 

Leave a Reply

%d bloggers like this: