CoPP: Control Plane Policing

The one-sentence mental model

CoPP is a firewall for the router’s own CPU. Data-plane traffic (transit) goes through the ASIC and doesn’t touch the CPU. Control-plane traffic (destined to the router or generated by it) does. A packet flood at the control plane will kill routing protocols, drop SSH sessions, and crash the box, even while transit forwarding still works.

What lives on the control plane

Every one of these hits the CPU:

• Routing protocol packets: OSPF hellos, BGP KEEPALIVEs, EIGRP hellos, IS-IS PDUs.
• First-hop redundancy: HSRP / VRRP / GLBP hellos.
• Management: SSH, Telnet (please no), SNMP, syslog reply, RADIUS.
• Discovery: CDP, LLDP.
• Address resolution: ARP requests + replies to the router’s IP.
• Punt: packets the ASIC couldn’t handle (unknown next-hop, IP option, TTL=1).
• Unicast to me: ICMP to my IP, TCP SYN to a listening port.

Any of these being flooded = CPU pegs = router unresponsive.

The classify → police pattern

CoPP uses the standard MQC (Modular QoS CLI) constructs but binds the policy to the control plane instead of an interface.

Step 1: ACLs to identify traffic

ip access-list extended COPP-ROUTING
  permit ospf any any
  permit tcp any any eq bgp
  permit tcp any eq bgp any
  permit eigrp any any

ip access-list extended COPP-MGMT
  permit tcp any any eq 22
  permit udp any any eq snmp
  permit udp any any eq syslog

ip access-list extended COPP-UNDESIRABLE
  permit icmp any any redirect
  permit ip any host 224.0.0.9         ! RIP (if not run)

Step 2: Class-maps

class-map match-any COPP-CRITICAL
  match access-group name COPP-ROUTING

class-map match-any COPP-NORMAL
  match access-group name COPP-MGMT

class-map match-any COPP-UNDESIRABLE
  match access-group name COPP-UNDESIRABLE

Step 3: Policy-map with police statements

policy-map COPP-POLICY
  class COPP-CRITICAL
    police cir 4000000 conform-action transmit exceed-action transmit
  class COPP-NORMAL
    police cir 1000000 conform-action transmit exceed-action drop
  class COPP-UNDESIRABLE
    police cir 32000 conform-action drop exceed-action drop
  class class-default
    police cir 500000 conform-action transmit exceed-action drop

Numbers are examples: sized to protect the CPU, not to shape a real service. Small cir values are typical.

Step 4: Apply to the control plane

control-plane
  service-policy input COPP-POLICY

Sizing the rates

Rule of thumb: budget each class based on legitimate steady-state × 3-5× to absorb transient bursts.

• Routing critical: even a busy BGP box rarely exceeds a few Mbps of control traffic. police cir 10000000 (10 Mb) is generous.
• Management: SSH + SNMP polls. A few hundred Kbps.
• Undesirable: drop hard, no headroom.
• Class-default: catch everything else. Give it enough headroom that legitimate discovery works, but low enough that a flood can’t hurt.

Tune with show policy-map control-plane input: look at the “packets dropped” counter per class. If CRITICAL is dropping, you sized too low. If UNDESIRABLE is nonzero, you have suspicious traffic.

Verification

show policy-map control-plane input
show policy-map control-plane input class COPP-NORMAL
show platform hardware qfp active feature qos control-plane        ! ASR/ISR 4000 (QFP platforms)

Look for conformed counters growing (normal traffic) and exceeded counters growing (attack traffic being policed).

Common exam / real-world mistakes

1. Missing a class → default catches everything. If your default policer is too tight, legitimate ARP breaks. If too loose, an attacker can flood via the default class. Size it deliberately.
2. Applying to an interface instead of the control plane. CoPP MUST be service-policy input POLICY under control-plane, not under a physical interface.
3. Forgetting broadcast / multicast to me. ARP requests are broadcast; router responds. Need a class covering ARP explicitly on some platforms, or “match protocol arp”.
4. CoPP vs CPPr (Control Plane Protection). CPPr is the newer, subinterface version: it separates host / transit / cef-exception into sub-planes. Some Cisco docs use CPPr and the same MQC constructs.
5. Not testing. Configure conservative rates, deploy in monitor mode (all transmit actions), watch counters for a week, then tighten. Skipping this locks you out during a flood.

Cheat strip

Job         protect router CPU from control-plane floods
Applies to  control-plane (not an interface)
Syntax      MQC: class-map → policy-map → service-policy

Class idea  CRITICAL     routing protocols        never drop
            NORMAL       mgmt (SSH, SNMP, syslog)  rate-limit
            UNDESIRABLE  unknown/spoofed          drop hard
            class-default catch-all                small allow, exceed drop

Size        legit × 3 to 5. Start loose. Watch counters. Tighten.
Verify      show policy-map control-plane input
Newer       CPPr adds host / transit / cef-exception sub-planes