Control Plane Policing (CoPP) on Cisco IOS XE

Every router has a CPU, and that CPU is a shared, finite resource that both keeps the network running (OSPF hellos, BGP updates, your SSH session) and can be trivially overwhelmed by traffic aimed at it. A flood of pings to the router's own interface, a burst of malformed packets that must be punted for inspection, or an SSH brute-force can starve the CPU of the cycles it needs to maintain routing adjacencies. When that happens, the control plane collapses and the network goes down, without a single link failing.

Control Plane Policing (CoPP) is the seatbelt. It is a QoS policy applied to traffic destined for the router itself, rate-limiting each category so no single class of control-plane traffic can consume the whole CPU. This article builds a CoPP policy and then floods the router to watch it drop the attack while protecting everything else. It extends the Infrastructure Security cluster guide.

Data Plane, Control Plane, Management Plane

CoPP only makes sense once you are clear about which traffic it touches.

Data plane

Traffic passing through the router, forwarded in hardware/CEF. Never touches the CPU.

Control plane

Traffic to the router that the CPU must process: routing protocols, ARP, SSH, SNMP, ICMP to its own IP. This is what CoPP protects.

Management plane

The subset used to manage the box: SSH, SNMP, NetConf. A logical slice of the control plane.

The insight that makes CoPP click: a packet destined for the router's own IP cannot be CEF-switched. It has to be handed to the CPU, because the CPU is the destination. That punt is expensive, and it is exactly the mechanism an attacker abuses. CoPP sits at the point where that punted traffic enters the control plane and applies a rate limit before it can pile up.

CoPP Is Just MQC Aimed at the Control Plane

CoPP uses the standard Modular QoS CLI (class-map, policy-map, service-policy) that the QoS cluster covers in depth. The only twist is where you attach it: not an interface, but the special control-plane pseudo-interface.

Step 1: classify the control-plane traffic into categories with ACLs and class-maps.

R1(config)# ip access-list extended COPP-ICMP
R1(config-ext-nacl)#  permit icmp any any
R1(config)# ip access-list extended COPP-SSH
R1(config-ext-nacl)#  permit tcp any any eq 22
R1(config)# ip access-list extended COPP-ROUTING
R1(config-ext-nacl)#  permit ospf any any
R1(config-ext-nacl)#  permit pim any any
!
R1(config)# class-map match-all CM-ICMP
R1(config-cmap)#  match access-group name COPP-ICMP
R1(config)# class-map match-all CM-SSH
R1(config-cmap)#  match access-group name COPP-SSH
R1(config)# class-map match-all CM-ROUTING
R1(config-cmap)#  match access-group name COPP-ROUTING

Step 2: police each class in a policy-map. This is where the security decisions live.

R1(config)# policy-map CoPP-POLICY
R1(config-pmap)#  class CM-ICMP
R1(config-pmap-c)#   police 8000 conform-action transmit exceed-action drop
R1(config-pmap)#  class CM-SSH
R1(config-pmap-c)#   police 32000 conform-action transmit exceed-action transmit
R1(config-pmap)#  class CM-ROUTING
R1(config-pmap-c)#   police 500000 conform-action transmit exceed-action transmit
R1(config-pmap)#  class class-default
R1(config-pmap-c)#   police 32000 conform-action transmit exceed-action transmit

Step 3: attach it, input, to the control plane.

R1(config)# control-plane
R1(config-cp)#  service-policy input CoPP-POLICY

The Thinking Behind the Numbers

The rates are not arbitrary, and the conform/exceed actions encode a threat model:

ICMP: exceed-action dropPing to the router is useful but never urgent. Cap it hard and drop the overflow. This is the ping-flood defence.

SSH: exceed-action transmitYou do not want to lock yourself out during an event. Police it but do not drop; a burst of legitimate admin traffic still gets through.

Routing: high rate, transmitOSPF and PIM are the network's heartbeat. Give them plenty of headroom and never drop them, or CoPP causes the outage it exists to prevent.

class-default: policedEverything you did not classify. A modest cap catches the unexpected, but tune carefully so you do not starve something you forgot to name.

The cardinal rule of CoPP: never drop your routing protocols, and be careful about SSH. A too-aggressive CoPP policy is one of the classic self-inflicted outages, because it drops the very traffic that keeps adjacencies up or keeps you logged in to fix things. Start with exceed-action transmit everywhere, watch the counters for a week to learn your baseline, and only then change the classes you understand to drop.

The Flood, and the Drops

Policy in place. Now a real attack: a Linux host floods the router's interface with ping -f (flood ping, as fast as the host can send):

j@llmbits:~$ sudo ping -f -w 6 192.168.99.1
....(thousands of dots)....
--- 192.168.99.1 ping statistics ---
414 packets transmitted, 39 received, 90.5797% packet loss, time 5991ms

90.6 percent packet loss. That is not the network failing. That is CoPP working exactly as designed, dropping the flood so it cannot reach and overwhelm the CPU. The 39 packets that got through are the ones that fit under the 8000 bps ICMP cap; everything above it was discarded at the control-plane edge.

The router's own view confirms it precisely:

R1#show policy-map control-plane input class CM-ICMP
 Control Plane

    Service-policy input: CoPP-POLICY

    Class-map: CM-ICMP (match-all)
      Match: access-group name COPP-ICMP
      police:
          cir 8000 bps, bc 1500 bytes
        conformed 597 packets, 58506 bytes; actions:
          transmit
        exceeded 3817 packets, 374066 bytes; actions:
          drop
        conformed 5000 bps, exceeded 12000 bps

597 packets conformed and were transmitted to the CPU. 3817 packets exceeded the rate and were dropped before they got there. That is the entire value proposition on one screen: the flood was absorbed at the policer, the CPU never saw the bulk of it, and OSPF (in its own high-rate class) kept running untouched throughout. During this whole test the routing adjacency to R2 never dropped.

Watch conformed 5000 bps, exceeded 12000 bps: the attacker was pushing roughly 17,000 bps of ICMP at a class capped at 8000, and the policer sorted the 5000 that fit from the 12000 that did not.

CPPr: Finer Control

Basic CoPP treats all control-plane traffic as one aggregate. Control Plane Protection (CPPr) subdivides it into three sub-interfaces for more surgical policy:

Host

Traffic to the router's own addresses: SSH, SNMP, ICMP, routing to a local interface.

Transit

Transit traffic that still needs punting (e.g. IP options).

CEF-exception

Packets CEF cannot handle: TTL-expired, unroutable, keepalives.

CPPr lets you police TTL-expiry punts (a common attack and a common traceroute side effect) separately from your SSH sessions. For most enterprises, aggregate CoPP is sufficient; CPPr earns its keep on high-value edge routers.

Pitfalls

Forgetting a protocol. If you police class-default aggressively and forget to classify, say, BGP or BFD, you can starve it. Enumerate every control protocol you actually run before tightening class-default.
Dropping ARP. ARP is control-plane traffic. An overly broad drop policy that catches ARP will break connectivity in ways that look baffling.
Platform differences. On many Catalyst and ASR platforms a default CoPP policy already exists in hardware. Layering your own on top requires understanding what is already there. Check before you assume the control plane is unprotected.
Testing in production. Build with exceed-action transmit, observe the counters, then tighten. A drop policy deployed blind is a coin flip.

FAQ

Does CoPP affect traffic passing through the router?

No. CoPP only sees traffic destined for the router itself (the control plane). Transit data-plane traffic is untouched.

Will CoPP stop a DDoS?

It protects the router's CPU from being overwhelmed by control-plane-directed attack traffic, which keeps the box up and routing. It does not stop a volumetric DDoS aimed through the router at a victim; that is a different problem (scrubbing, uRPF, upstream filtering).

What rate should I use?

There is no universal number. Baseline your real traffic first (transmit-only policy, watch conformed), then set the cap comfortably above normal but below what would hurt the CPU.

Can CoPP lock me out?

Yes, if you drop SSH or your routing protocols too aggressively. This is the number-one CoPP mistake. Police management traffic with transmit, not drop.

Key Takeaways

CoPP protects the router's CPU from control-plane traffic (packets destined to the router that must be punted).
It is standard MQC (class-map, policy-map) attached to the control-plane pseudo-interface with service-policy input.
In the lab a flood ping hit 90.6% loss and the policer showed 597 conformed / 3817 dropped, absorbing the attack while OSPF stayed up.
The conform/exceed actions are a threat model: drop excess ICMP, but only police (never drop) SSH and routing.
Never drop your routing protocols. An over-aggressive CoPP policy causes the outage it was meant to prevent.
Build with exceed-action transmit, baseline the counters, then tighten. CPPr adds host/transit/CEF-exception granularity when you need it.

Next: Unicast RPF to drop spoofed traffic at the edge, or the Infrastructure Security cluster guide.

Control Plane Policing (CoPP): Protecting the CPU