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..
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