Control Plane Policing (CoPP) is a feature we’ve had for quite a few years in the IOS, and we use it to protect the control plane of our routers. Now we have our integrated services routers (ISRs). It’s really designed to let us manage the flow of traffic that is controlled by the route processor on your device. This could be within the actual router itself or it could be on line cards. What we’re trying to do here is prevent unnecessary traffic from overwhelming the route processor, which by the way is its own logical receive interface. Now to do this, to protect it from denial-of-service attacks and to provide packet quality-of-service, CoPP has to treat the control plane like a separate entity, but its own input and output ports – ingress and egress, it’s really a receive interface. So you have a set of rules that can be established and associated with the inbound and outbound ports of the control plane. Now these rules only get applied after the packet has been determined to have the control plane as its destination or if a packet is exiting the control plane on its logical egress interface. After that, you can configure a service policy to prevent unwanted packets from progressing after a certain rate limit has been reached. For instance, you can limit all TCP send packets that are destined for the control plane at a maximum rate of 1 Mbps.
CoPP has several features, it lets you configure quality-of-service filters to manage traffic flow on the control plane packets and protect the control plane of your router and switch against reconnaissance attacks and denial-of-service attacks. The newer features CPP – Control Plane Protection – is actually an extension of the policing functionality of the existing CoPP feature. However, Control Plane Protection offers finer granularity. So what happens is you can take that single receive interface and you divide it up into multiple subinterfaces so you can get granular protection that way.
There is also a Control Plane Logging where you can filter and rate limit the packets that are going to the control plane of the router, and you can also discard malicious and error packets if you want to. The Control Plane Logging feature lets you log packets that these features drop or permit as well. It will provide the logging mechanism you need to deploy, monitor, and troubleshoot the features of CoPP in an effective and efficient manner.
The benefits of the traditional CoPP feature are four-fold. You get protection against denial-of-service attacks. It’s an easier to deploy because you use the existing modular QoS CLI or MQC infrastructure with its class maps, policy maps, and service policy. You have a consistent implementation strategy across all your Cisco hardware. That’s going to improve the reliability, security, and availability of your network.
Cisco CPP
Now the CPP or it’s also known as CPPR – Control Plane Protection – is a newer feature that may not be supported at one of your earlier integrated services routers, let’s say generation one. Its going to extend the CoPP functionality by allowing classification of the control plane traffic based on packet destination and data that’s provided by the forwarding plane. It basically allows you to throttle for each category of packets. It allows rate limiting for each traffic class on an individual basis, it’s easy to configure, it still uses that same policy language that we talked about a minute ago – the MQC Infrastructure. It provides better platform reliability, security, and availability. And it offers CPU protection which can be very important especially for things like routing. So, we basically take the one logical interface to the control plane, which we use to call the receive interface, and break it up into three subinterfaces. Typically, we’re really only concerned with the host subinterface.
Deploying CoPP and CPP
Here we can see our deployment of CoPP and CPPR, where we have different traffic classes.
| Traffuc Class | Rate (pps) | Conform Action | Exceed Action |
|---|---|---|---|
| Routing Protocols (OSPF and so on) |
N/A | Transmit | Transmit |
| Management (HTTP, SSH and so on) |
250 | Transmit | Drop |
| Reporting (Syslog and so on) |
50 | Transmit | Drop |
| Monitoring (SNMP and so on) |
75 | Transmit | Drop |
| Spanning Tree | 25 | Transmit | Drop |
| Undesirable | 10 | Drop | Drop |
| Default (anything else) | 10 | Transmit | Drop |
There are routing protocols – OSPF, EIGRP, BGP. There is the management traffic class – HTTP, Secure Shell, for example. There is the reporting traffic class with things like Syslog. There is the monitoring traffic class with things like SNMP. There is the spanning tree traffic class, there is an undesirable traffic class, and then there is the default (anything else) traffic class. And we can see that we can rate limit certain things other than the routing protocols. If the conform action matches our policy, if it conforms to the policy that we set, then we can transmit certain things, we can drop certain things. If it exceeds a certain threshold, we can transmit or drop. So we have a lot of flexibility and power here to provide solutions for our real world network implementation.
Routing protocol integrity
We also want to provide integrity and authenticity to make sure that the packets that are exchanged between routing peers or neighbors are not modified in transit nor are they being hijacked with unauthorized peers. So we want to make sure that we have integrity of those packets, also that we can authenticate these peers. So this is going to happen whenever routing updates are exchanged in OSPF, EIGRP, BGP, IS-IS, and RIP version 2. Well, what are we doing here? This is a countermeasure against deliberate, malicious hijacking of routing updates to corrupt routing tables and unauthorized access to our routers, that can be route diversion or rerouting. If you can reroute hosts to a different gateway, or a different DNS, server or a different rogue DHCP server, you can wreak all kinds of havoc in a network. This is also a countermeasure against man-in-the-middle attacks, and like I mentioned, rogue default gateways. Now I’ve mentioned some protocols here, but there are also IP version 6 protocols – IPv6, you got support for OSPF Version 3 – OSPFv3 and RIP Next Generation – RIP NG.
Cisco AutoSecure
Cisco AutoSecure is a pretty neat feature that’ll lockdown the control plane. It’ll implement protection mechanisms for the data and management plane as well. For the control plane, It disables unnecessary and potential insecure services, things that we don’t really use anymore, like Finger. It’ll also lockdown HTTP and CDP. On the management plane, it secures admin access to the router. It’ll look for the existence of strong passwords, a minimum length, AAA, and Secure Shell, and others. On the data plane, it’ll disable unnecessary and potentially insecure interface services. It’ll remove IP redirects, IP proxy ARP, things like that. There are two modes of operation for Cisco’s AutoSecure. It’s done at the CLI. You can do interactive, where it actually prompts the user. So you could just lockdown, for example particular planes like, let’s say, just lockdown the management plane or the control plane. Or you could do the non-interactive option where it will apply all the Cisco defaults.
Our Recommended Premium CCNA Training Resources
These are the best CCNA training resources online:
Click Here to get the Cisco CCNA Gold Bootcamp, the most comprehensive and highest rated CCNA course online with a 4.8 star rating from over 30,000 public reviews. I recommend this as your primary study source to learn all the topics on the exam.
Want to take your practice tests to the next level? AlphaPreps purpose-built Cisco test engine has the largest question bank, adaptive questions, and advanced reporting which tells you exactly when you are ready to pass the real exam. Click here for your free trial.
