# Control Plane Policing and Protection

> Chapter 15 of the Courseiva ENARSI curriculum — https://courseiva.com/learn/enarsi/control-plane-policing-and-protection

**Official objective:** 4.2 — Configure and verify control plane policing (CoPP)

## Introduction

Without Control Plane Policing, a single malicious internet troll or a simple misconfiguration could lock you out of your own network, crash your critical routers, and bring a whole company's business to a standstill. This chapter explains how to stop attackers and accidents from overwhelming a router's brain (the control plane) so that legitimate traffic always gets through. It is a key skill for the 300-410 exam because it tests your ability to protect the routing infrastructure itself, not just the data flowing through it.

## The Nightclub Bouncer Analogy

A head bouncer at a popular nightclub has a critical job: keep the club running smoothly and safely. The club has a main entrance (the control plane) where the bouncer processes every request to enter, like checking IDs (routing updates from neighbours), managing the guest list (answering pings and SNMP queries), and dealing with troublemakers (stopping malicious traffic aimed at the router itself). The dance floor and bars (the data plane) are where the actual party happens, forwarding packets between customers. The bouncer has a small team, and if they get swamped with thousands of fake IDs or a mob of people trying to rush the door all at once (a control-plane attack), they cannot check anyone properly, and the entire club grinds to a halt.

To prevent this, the bouncer sets up a strict door policy: only certain types of people (specific protocols like OSPF or BGP) are allowed in from trusted sources (specific IP addresses), and anyone else is turned away (dropped). He also sets a limit on how many people he will check per second (rate-limit), so even if a crowd shows up, he can still handle the VIP guests (critical routing protocols) without getting overwhelmed. This is exactly how Control Plane Policing works: it protects the router's brain (CPU) from being overloaded by unwanted or malicious traffic that is trying to enter the control plane, ensuring the router stays stable and its other functions (like routing and management) keep working.

## Core explanation

To understand Control Plane Policing (CoPP), you first need to know what a router's control plane is. Think of a router as having three main parts: the data plane, the control plane, and the management plane. The data plane is the fast path where packets are forwarded from one interface to another without the router's CPU (Central Processing Unit, its main processor) needing to think too much. The management plane is for human access, like SSH (secure shell for remote command line) or SNMP (Simple Network Management Protocol for monitoring). The control plane is the router's brain. It is where the CPU runs routing protocols like OSPF (Open Shortest Path First) and BGP (Border Gateway Protocol) to build the routing table, and it also processes any traffic directed to the router itself, such as pings (ICMP echo requests) or management packets.

The problem is that the control plane is a limited resource. If a router receives thousands of packets per second that are all destined for its own IP address (a control-plane attack, part of a DoS or Denial of Service attack), the CPU spends all its time dealing with those junk packets. It then drops legitimate routing updates from neighbours, which causes the router to lose its routing tables and stop forwarding data properly. CoPP solves this by acting like a security guard for the control plane. It uses an ACL (Access Control List, a set of rules that match packets based on things like source IP, destination port, or protocol) to classify traffic into different classes: for example, critical (OSPF, BGP), normal (SSH, SNMP), and undesirable (unknown or malicious traffic). Then, CoPP applies a policy map that tells the router what to do with each class: either allow it (pass), drop it (discard), or limit its rate (police it to a certain speed).

Why does CoPP exist? Before CoPP, the only way to protect a router's CPU was to use ACLs on every single interface, which is extremely difficult to manage and scale. CoPP provides a single, centralised policy applied at the control plane level, making it much simpler. On the 300-410 exam, you configure CoPP using the 'service-policy' command under the 'control-plane' configuration mode. You first create a class map to match traffic, then a policy map to define the action (police or drop), and then apply that policy map to the control plane. The most common trap Cisco sets in the exam is confusing which direction CoPP applies to: it only filters traffic *destined* for the router (the control plane), not traffic that is just passing *through* the router (the data plane). If you try to use CoPP to filter traffic that the router is simply forwarding, you will fail the configuration. Another key point is that you must be careful not to block your own management access (SSH or Telenet) or critical routing protocols, or you will lock yourself out or break the network.

## Real-world context

Imagine you are a network engineer for a large e-commerce company. It is the day before Black Friday, and your core router is receiving a sudden flood of packets destined for its own IP address — maybe a new employee accidentally pointed a monitoring tool at the wrong device, or a competitor is launching a low-level DoS attack. Without CoPP, the router's CPU hits 100% usage in seconds, it stops processing BGP updates from your upstream provider, and the entire site goes offline. You have just lost millions of pounds in revenue.

Here is exactly how you would use CoPP to prevent this: First, you log in to the router via SSH (being very careful not to lock yourself out) and enter global configuration mode. You create a class map called 'CRITICAL-TRAFFIC' that matches on ACL entries allowing only OSPF (protocol 89) and BGP (TCP port 179) from known neighbour IPs. You create another class map called 'MGMT-TRAFFIC' matching SSH (TCP port 22) and SNMP (UDP port 161) from your company's management subnet. You then create a third class map called 'BAD-TRAFFIC' matching everything else destined for the router (using a 'match any' condition).

Next, you build a policy map called 'CONTROL-PLANE-POLICY' that specifies actions: for CRITICAL-TRAFFIC, you set a police rate of 500 kbps (kilobits per second) with a conform action of 'transmit' and an exceed action of 'drop'. This means if OSPF packets come in faster than 500 kbps (which should never happen normally), they get dropped. For MGMT-TRAFFIC, you set a police rate of 100 kbps. For BAD-TRAFFIC, you set a police rate of 10 kbps and set the exceed action to drop. Finally, you apply this policy to the control plane using the 'service-policy input CONTROL-PLANE-POLICY' command under the 'control-plane' configuration mode. Now, if the flood hits, the router will simply drop the excess packets, keeping the CPU at a safe level. You also set up logging so you get an alert if the police counters increase, letting you know an attack is happening without it taking the network down.

## Exam focus

The 300-410 exam loves to test Control Plane Policing. Expect at least one or two multiple-choice questions and possibly a scenario-based question where you must identify the correct configuration steps. The exam will not ask you to type the commands from memory, but it will test your understanding of the sequence and the meaning of each command.

Key concepts they test:
- **Where to apply CoPP**: The command 'service-policy input [policy-name]' is applied under the 'control-plane' configuration mode. A common trap is applying it under an interface — that is wrong.
- **Direction**: CoPP only polices traffic *input* to the control plane (traffic destined for the router), not traffic passing through.
- **Class map types**: They will test that you use 'match access-group' or 'match protocol' correctly inside a class map. You might see a distractor using 'match ip address' instead of 'match access-group'.
- **Police actions**: Understand 'conform-action transmit' and 'exceed-action drop'. They may ask what happens when traffic exceeds the police rate.
- **The three planes**: Be ready to distinguish control plane (routing protocols, CPU processing), data plane (forwarding), and management plane (SSH, SNMP).

Common traps:
- Thinking CoPP can filter data-plane traffic — it cannot.
- Applying the policy globally instead of under 'control-plane'.
- Using the wrong ACL direction (e.g., using 'in' instead of 'out' on the ACL, but actually CoPP uses 'input' only).
- Forgetting that you must include your own management traffic in the policy, otherwise you could lock yourself out.
- Not knowing that 'police' is the command used under the policy map, not 'rate-limit' (which is older and not used for CoPP).

The correct answer pattern in a multiple-choice question is usually: 'Create class maps, then a policy map, then apply it under control-plane with service-policy input.' Memorise that order.

## Step by step

1. **Identify control plane traffic** — First, determine which traffic is destined for the router itself, not traffic being forwarded. This includes routing protocol packets (OSPF, BGP, EIGRP), management packets (SSH, SNMP, telnet), and ICMP (ping) to the router's IP addresses. This step is critical because CoPP will only affect these packets.
2. **Create class maps for traffic classes** — Use 'class-map' commands to define different categories of control plane traffic, such as 'CRITICAL' for OSPF/BGP, 'MANAGEMENT' for SSH, and 'UNDESIRABLE' for unknown traffic. Each class map uses 'match access-group' or 'match protocol' to identify the specific packets.
3. **Create a policy map with actions** — Use 'policy-map' to define what each class of traffic should do. For each class, apply a 'police' statement that sets a rate limit (e.g., 500 kbps) and defines the action when the traffic is within the limit ('conform-action transmit') and when it exceeds the limit ('exceed-action drop'). This is the core of the protection.
4. **Apply the policy to the control plane** — Enter 'control-plane' configuration mode and apply the policy map using 'service-policy input [policy-name]'. This tells the router to enforce the policy on all traffic entering the control plane from any interface. Without this step, the policy map is not active.
5. **Test and verify the policy** — Use 'show policy-map control-plane' to verify the policy is applied and to see statistics on how many packets have been dropped or allowed. Test from a management workstation that SSH still works, and check that OSPF neighbours remain up. If you locked yourself out, you may need console access to fix the policy.

## Comparisons

### Control Plane Policing (CoPP) vs Interface ACL

**Control Plane Policing (CoPP):**
- Applied once to the control plane globally.
- Filters only traffic destined for the router's CPU.
- Uses class maps and policy maps to define actions.

**Interface ACL:**
- Applied per interface individually.
- Filters all traffic entering that interface, regardless of destination.
- Uses permit/deny statements only, no rate limiting.

### Control Plane vs Data Plane

**Control Plane:**
- Handles routing protocols (OSPF, BGP).
- Processes traffic destined for the router itself.
- Uses the router's CPU, which is limited.

**Data Plane:**
- Forwards packets from one interface to another.
- Handles traffic not destined for the router.
- Uses dedicated hardware (ASICs) for high speed.

### Police (rate-limit) Action vs Drop Action

**Police (rate-limit) Action:**
- Allows packets up to a configured rate.
- Drops packets only when the rate is exceeded.
- Useful for allowing some traffic (e.g., SSH, pings) while blocking floods.

**Drop Action:**
- Drops all matching packets immediately.
- No traffic of that class is ever allowed.
- Appropriate for known malicious traffic that should never reach the CPU.

## Diagram

_This flowchart shows how traffic is classified by destination and then either allowed or rate-limited by Control Plane Policing before reaching the CPU._

```mermaid
flowchart TD
    A[Traffic enters router interface] --> B{Is traffic destined for router CPU?}
    B -- Yes --> C[Control Plane Policing checks policy]
    C --> D[Class map matches traffic]
    D --> E{Police rate exceeded?}
    E -- No --> F[Allow (transmit) to CPU]
    E -- Yes --> G[Drop packet]
    B -- No --> H[Data plane forwards packet normally]
```

## Common misconceptions

- **Misconception:** CoPP can filter any traffic going through the router, like blocking YouTube for employees. **Reality:** CoPP only filters traffic that is destined for the router's control plane (the CPU itself), not traffic that is being forwarded from one interface to another. (Beginners confuse the control plane with the data plane. They think if a packet enters one interface and leaves another, it still 'touches' the control plane, but in modern routers it is forwarded in hardware without involving the CPU.)
- **Misconception:** Applying a CoPP policy will block all traffic that does not match an explicit 'permit' statement in the ACL. **Reality:** CoPP uses a policy map that specifies actions for each class. If traffic does not match any class, the default action is to drop it, but you can also create a default class to allow it. (This is a common trap because ACLs often have an implicit 'deny all' at the end. People assume CoPP works the same way, but the policy map's treatment of unmatched traffic can be configured.)
- **Misconception:** You should apply CoPP globally to the router to protect all interfaces equally. **Reality:** CoPP is applied to the control plane itself, which implicitly covers all interfaces. There is no 'global' application; you just enter 'control-plane' mode and apply the policy there. (New learners search for a global command and think 'service-policy' under 'control-plane' is just another global setting, missing the specificity that it only polices the control plane input.)
- **Misconception:** Once you configure CoPP, you do not need to worry about ACLs on interfaces anymore for security. **Reality:** CoPP is an additional layer of protection for the CPU, but you still need ACLs and firewall rules on interfaces to protect the data plane and to filter traffic that is just passing through. (It feels like a 'set and forget' solution, but CoPP only solves one specific problem. Beginners think it replaces all other filtering.)
- **Misconception:** CoPP slows down the router because it has to inspect every packet. **Reality:** CoPP is designed to be lightweight and is processed efficiently by the router. It actually prevents slowdowns that would be caused by CPU overload from attacks. (People intuitively think that adding any inspection adds overhead, but in reality, CoPP reduces overhead by dropping unwanted traffic early.)

## Key takeaways

- Control Plane Policing (CoPP) protects only traffic *destined for* the router's CPU, not traffic passing through the router.
- You configure CoPP by creating a class map, a policy map, and then applying it under 'control-plane' mode using 'service-policy input'.
- Always include your management traffic (SSH, SNMP) in a 'permit' class to avoid accidentally locking yourself out of the router.
- The 'police' command in the policy map sets a rate limit; traffic exceeding this rate is dropped, protecting the CPU from overload.
- CoPP replaces the need for ACLs on every interface to protect the control plane, simplifying security management.
- On the 300-410 exam, watch for traps that confuse control-plane policing with data-plane filtering, and remember the configuration order: class-map, policy-map, then service-policy.
- If you do not explicitly allow routing protocols like OSPF or BGP in your CoPP policy, your router will lose its neighbours and routes.
- The default action for traffic not matching any class in a CoPP policy map is to drop it, so always include a class for allowed traffic.

## FAQ

**Will CoPP block my SSH session to the router?**

Only if you do not include SSH traffic in your CoPP policy. Always create a class map that matches SSH from your management subnet with a 'permit' action, or at least a high enough police rate that your own session is not dropped.

**What is the difference between CoPP and an ACL on an interface?**

An ACL on an interface filters traffic that is passing through that interface, whether it is destined for the router or not. CoPP only filters traffic that is destined for the router's CPU, regardless of the interface it comes in on.

**Can CoPP stop a DDoS attack from the internet?**

CoPP can protect the router's CPU from being overwhelmed by DDoS traffic aimed at the router itself, but it cannot stop DDoS traffic that is aimed at a server behind the router, as that traffic goes through the data plane.

**What happens if I do not configure a class for routing protocols in CoPP?**

If you apply a CoPP policy that only allows management traffic and drops everything else, your OSPF or BGP neighbours will time out and the router will lose its routes, causing a network outage.

**Do I need to apply CoPP to every interface?**

No. You apply it once to the 'control-plane' globally, and it automatically polices traffic from all interfaces that is destined for the CPU.

**Can I use CoPP to rate-limit ICMP pings to the router?**

Yes. You can create a class map matching ICMP (protocol 1) and then police it to a low rate, so that ping floods do not overwhelm the CPU but a single ping still works for testing.

## Check your understanding

1. **What is the purpose of Control Plane Policing?**

   Answer: It protects a router's CPU from being overwhelmed by excessive or malicious traffic destined for the control plane, ensuring routing stability.

2. **Under which configuration mode do you apply the CoPP policy?**

   Answer: You apply it under the 'control-plane' configuration mode using the 'service-policy input' command.

3. **What happens to traffic that exceeds the configured police rate in a CoPP policy?**

   Answer: The router drops the excess traffic based on the 'exceed-action' configured, which is typically 'drop'.

4. **Can CoPP filter traffic that is being forwarded from one interface to another?**

   Answer: No. CoPP only filters traffic that is destined for the router itself, not traffic passing through the data plane.

5. **Why is it critical to include management traffic (like SSH) in a CoPP policy?**

   Answer: If you do not include it, the default action might drop your management session, locking you out of the router permanently.

---

Interactive version with quiz and diagrams: https://courseiva.com/learn/enarsi/control-plane-policing-and-protection