Control Plane Policing (CoPP) Configuration

Every Cisco router has a control plane — the part of the system responsible for running routing protocols, processing management sessions, and handling packets destined for the router itself (rather than packets the router simply forwards). The control plane is processed entirely by the router CPU, which has finite capacity. An attacker who floods the router with crafted packets — ICMP, TCP SYN, or spoofed routing protocol updates — can saturate the CPU, causing legitimate routing protocol adjacencies to drop, management sessions to time out, and the router to become unreachable: a targeted denial-of-service attack against the network infrastructure itself.

Control Plane Policing (CoPP) uses Cisco's Modular QoS CLI (MQC) framework to classify traffic destined for the control plane and apply rate limits (policers) to each class. Legitimate routing protocol traffic is permitted at its normal rate; management traffic such as SSH is rate-limited to protect against brute-force floods; and clearly hostile traffic such as packets with invalid source addresses is dropped entirely. The router CPU is protected while normal network operations continue uninterrupted.

CoPP builds on MQC — the same framework used for QoS traffic shaping and policing on data-plane interfaces. If you are unfamiliar with class maps and policy maps, review the MQC Basics lab before this one. For the ACL match syntax used inside class maps, see Applying ACLs, Standard ACLs, and Named ACLs. For the SSH management traffic that CoPP protects, see SSH Configuration. For OSPF and EIGRP adjacency protection that CoPP enables, see OSPF Single-Area Configuration and EIGRP Configuration.

1. Control Plane Policing — Core Concepts

The Three Planes of a Router

Understanding CoPP requires understanding which plane a packet belongs to — only control plane and management plane traffic are policed by CoPP:

Plane	Traffic Type	Examples	Processed By
Data Plane	Transit traffic the router forwards — source and destination are not the router	User HTTP traffic, FTP, video streams passing through the router	Hardware forwarding ASIC (CEF) — does not touch the CPU
Control Plane	Traffic the router generates or receives to maintain network state — routing protocol packets	OSPF Hellos, EIGRP updates, BGP keepalives, STP BPDUs, ARP, ICMP redirects	Router CPU — vulnerable to flooding attacks
Management Plane	Traffic used to manage and configure the router directly	SSH (TCP/22), Telnet (TCP/23), SNMP (UDP/161), NTP (UDP/123), HTTPS/HTTP to the router	Router CPU — also vulnerable; rate-limited by CoPP

How CoPP Works — MQC Applied to the Control Plane

CoPP uses the same three-step MQC process used for interface QoS, but the service policy is applied to the special control-plane interface rather than a physical interface:

  Step 1 — Define ACLs to match traffic types
  ┌────────────────────────────────────────────────────────────────┐
  │  ip access-list extended ACL-OSPF                              │
  │    permit ospf any any                                         │
  │  ip access-list extended ACL-SSH                               │
  │    permit tcp any any eq 22                                    │
  │  ip access-list extended ACL-ATTACK                            │
  │    permit ip 0.0.0.0 0.255.255.255 any   ← RFC 1918 bogons    │
  └────────────────────────────────────────────────────────────────┘
          │
          ▼
  Step 2 — Create class maps that reference the ACLs
  ┌────────────────────────────────────────────────────────────────┐
  │  class-map match-all COPP-OSPF                                 │
  │    match access-group name ACL-OSPF                            │
  │  class-map match-all COPP-SSH                                  │
  │    match access-group name ACL-SSH                             │
  │  class-map match-all COPP-ATTACK                               │
  │    match access-group name ACL-ATTACK                          │
  └────────────────────────────────────────────────────────────────┘
          │
          ▼
  Step 3 — Create a policy map with policers per class
  ┌────────────────────────────────────────────────────────────────┐
  │  policy-map COPP-POLICY                                        │
  │    class COPP-OSPF                                             │
  │      police rate 100000 bps conform-action transmit           │
  │                         exceed-action drop                     │
  │    class COPP-SSH                                              │
  │      police rate 32000 bps  conform-action transmit           │
  │                              exceed-action drop                │
  │    class COPP-ATTACK                                           │
  │      police rate 8000 bps   conform-action drop               │
  │                              exceed-action drop                │
  │    class class-default                                         │
  │      police rate 64000 bps  conform-action transmit           │
  │                              exceed-action drop                │
  └────────────────────────────────────────────────────────────────┘
          │
          ▼
  Step 4 — Apply to the control plane (not a physical interface)
  ┌────────────────────────────────────────────────────────────────┐
  │  control-plane                                                 │
  │    service-policy input COPP-POLICY                            │
  └────────────────────────────────────────────────────────────────┘

CoPP Policer Actions

Action	Conform (within rate)	Exceed (over rate)	Typical Use
`transmit`	✅ Forward packet to CPU	✅ (when set as exceed action) Forward even over-rate traffic	Conform: all legitimate classes. Exceed: only if you want to allow bursts
`drop`	❌ Drop packet before it reaches CPU	❌ Drop over-rate packets	Exceed: all classes (drop traffic over the rate limit). Conform: attack/bogon classes
`set-dscp-transmit`	Mark DSCP and forward — rarely used in CoPP; more common in data-plane QoS		Re-marking traffic before CPU delivery

Critical Design Rules for CoPP

Rule	Explanation
Always include class-default	The `class class-default` at the end of the policy map catches all unclassified control-plane traffic. Without it, unknown traffic hits the implicit permit — configuring an explicit rate limit on class-default is best practice
Order class maps from most specific to least specific	Traffic is matched against class maps in order — the first match wins. Place specific protocols (OSPF, BGP) before broad classes (all TCP, class-default)
Never drop routing protocols completely	Setting a zero rate or drop-only action on OSPF or BGP will kill adjacencies. Always set a generous conform-action transmit for routing protocol classes
Test in audit mode first	Use `show policy-map control-plane` counters to observe which classes are matching and at what rate before enabling drop actions — misconfigured CoPP can cut off management access to the router
CoPP is input-only on control-plane	The `service-policy input` direction on the `control-plane` interface is the standard and most commonly tested direction. Output CoPP (packets generated by the router) exists but is less common

2. Lab Topology & Scenario

NetsTuts_R1 is an edge router running OSPF with its upstream provider router and accepting SSH management sessions from the NOC. An attacker on the internet has been flooding the router with ICMP packets and TCP SYN bursts, causing CPU spikes that briefly drop the OSPF adjacency. CoPP will classify and rate-limit five traffic categories:

                    Internet / WAN
                    203.0.113.2 (ISP)
                          |
                     Gi0/0: 203.0.113.1
                       NetsTuts_R1          ◄── CoPP applied here
                     Gi0/1: 10.0.0.1            (control-plane service-policy input)
                          |
              ────────────────────────────
              |                          |
         10.0.0.10                   10.0.0.20
         NOC Workstation            Internal LAN Host
         (SSH management)

  CoPP Traffic Classes on NetsTuts_R1:
  ┌──────────────────┬────────────────────────────────────┬──────────────┬──────────────────┐
  │ Class            │ Traffic Matched                    │ Rate Limit   │ Exceed Action    │
  ├──────────────────┼────────────────────────────────────┼──────────────┼──────────────────┤
  │ COPP-ROUTING     │ OSPF, EIGRP, BGP (TCP/179)         │ 256 kbps     │ Drop             │
  │ COPP-MGMT        │ SSH (TCP/22), SNMP (UDP/161),      │ 64 kbps      │ Drop             │
  │                  │ NTP (UDP/123)                       │              │                  │
  │ COPP-ICMP        │ All ICMP to the router             │ 32 kbps      │ Drop             │
  │ COPP-ATTACK      │ RFC 1918 bogon sources, fragments  │ 8 kbps       │ Drop             │
  │ class-default    │ Everything else                    │ 64 kbps      │ Drop             │
  └──────────────────┴────────────────────────────────────┴──────────────┴──────────────────┘

3. Step 1 — Define ACLs to Classify Control Plane Traffic

CoPP class maps use match access-group to identify traffic types. Extended named ACLs give each class a descriptive name and allow precise protocol-and-port matching. These ACLs are only used by the CoPP class maps — they are never applied to a physical interface:

NetsTuts_R1>en
NetsTuts_R1#conf t
Enter configuration commands, one per line.  End with CNTL/Z.

! ══════════════════════════════════════════════════════════
! ACL 1: Routing protocol traffic
! ══════════════════════════════════════════════════════════
NetsTuts_R1(config)#ip access-list extended ACL-COPP-ROUTING
NetsTuts_R1(config-ext-nacl)#remark Match OSPF, EIGRP, BGP destined for this router
NetsTuts_R1(config-ext-nacl)#10 permit ospf any any
NetsTuts_R1(config-ext-nacl)#20 permit eigrp any any
NetsTuts_R1(config-ext-nacl)#30 permit tcp any any eq 179
NetsTuts_R1(config-ext-nacl)#40 permit tcp any eq 179 any
NetsTuts_R1(config-ext-nacl)#exit

! ══════════════════════════════════════════════════════════
! ACL 2: Management traffic
! ══════════════════════════════════════════════════════════
NetsTuts_R1(config)#ip access-list extended ACL-COPP-MGMT
NetsTuts_R1(config-ext-nacl)#remark SSH, SNMP, NTP to the router
NetsTuts_R1(config-ext-nacl)#10 permit tcp any any eq 22
NetsTuts_R1(config-ext-nacl)#20 permit udp any any eq 161
NetsTuts_R1(config-ext-nacl)#30 permit udp any any eq 162
NetsTuts_R1(config-ext-nacl)#40 permit udp any any eq 123
NetsTuts_R1(config-ext-nacl)#exit

! ══════════════════════════════════════════════════════════
! ACL 3: ICMP traffic
! ══════════════════════════════════════════════════════════
NetsTuts_R1(config)#ip access-list extended ACL-COPP-ICMP
NetsTuts_R1(config-ext-nacl)#remark All ICMP destined to this router
NetsTuts_R1(config-ext-nacl)#10 permit icmp any any
NetsTuts_R1(config-ext-nacl)#exit

! ══════════════════════════════════════════════════════════
! ACL 4: Attack / bogon traffic — drop-only class
! ══════════════════════════════════════════════════════════
NetsTuts_R1(config)#ip access-list extended ACL-COPP-ATTACK
NetsTuts_R1(config-ext-nacl)#remark RFC 1918 bogons and loopback spoofs
NetsTuts_R1(config-ext-nacl)#10 permit ip 0.0.0.0 0.255.255.255 any
NetsTuts_R1(config-ext-nacl)#20 permit ip 127.0.0.0 0.255.255.255 any
NetsTuts_R1(config-ext-nacl)#30 permit ip 240.0.0.0 15.255.255.255 any
NetsTuts_R1(config-ext-nacl)#exit

BGP requires two ACL entries — rule 30 matches new inbound TCP/179 sessions (peer initiating a connection to this router) and rule 40 matches established sessions where the remote peer's source port is 179 (this router's established outbound BGP sessions returning data). SNMP traps use UDP/162 (rule 30 in ACL-COPP-MGMT) — traps are generated by the router but the source port is still relevant for inbound SNMP managers polling from port 162. The attack ACL matches RFC 1918 source addresses arriving on a WAN interface (a spoofing indicator), loopback addresses (127.x.x.x — never valid as a source on a WAN link), and Class E reserved space (240.x.x.x). For ACL syntax details, see Named ACLs and Wildcard Masks.

4. Step 2 — Create Class Maps

Class maps bind the ACLs defined in Step 1 to named traffic classes. match-all requires all match criteria to be true (logical AND); match-any requires at least one to match (logical OR). For CoPP, a single ACL per class map is typical — the ACL itself consolidates multiple protocol matches with its permit entries:

! ── Class map: routing protocols ─────────────────────────
NetsTuts_R1(config)#class-map match-all COPP-ROUTING
NetsTuts_R1(config-cmap)#description Routing protocol traffic - OSPF EIGRP BGP
NetsTuts_R1(config-cmap)#match access-group name ACL-COPP-ROUTING
NetsTuts_R1(config-cmap)#exit

! ── Class map: management plane ──────────────────────────
NetsTuts_R1(config)#class-map match-all COPP-MGMT
NetsTuts_R1(config-cmap)#description Management - SSH SNMP NTP
NetsTuts_R1(config-cmap)#match access-group name ACL-COPP-MGMT
NetsTuts_R1(config-cmap)#exit

! ── Class map: ICMP ───────────────────────────────────────
NetsTuts_R1(config)#class-map match-all COPP-ICMP
NetsTuts_R1(config-cmap)#description ICMP to router - ping traceroute
NetsTuts_R1(config-cmap)#match access-group name ACL-COPP-ICMP
NetsTuts_R1(config-cmap)#exit

! ── Class map: attack / bogon ─────────────────────────────
NetsTuts_R1(config)#class-map match-all COPP-ATTACK
NetsTuts_R1(config-cmap)#description Spoofed and bogon source addresses
NetsTuts_R1(config-cmap)#match access-group name ACL-COPP-ATTACK
NetsTuts_R1(config-cmap)#exit

The class map name (e.g., COPP-ROUTING) is what appears in the policy map and in show policy-map control-plane output. Descriptive names make verification output immediately readable without needing to cross-reference ACL numbers. The implicit class class-default does not need to be created — it exists automatically and catches all traffic that does not match any named class.

5. Step 3 — Build the CoPP Policy Map

The policy map assigns a policer to each class. The policer defines the rate limit in bits per second (bps), plus conform and exceed actions. Class order within the policy map matters — the router evaluates classes top to bottom and the first match wins:

NetsTuts_R1(config)#policy-map COPP-POLICY
NetsTuts_R1(config-pmap)#description CoPP — control plane protection policy

! ── Class 1: Drop known attack traffic immediately ────────
NetsTuts_R1(config-pmap)#class COPP-ATTACK
NetsTuts_R1(config-pmap-c)#police rate 8000 bps
NetsTuts_R1(config-pmap-c-police)#conform-action drop
NetsTuts_R1(config-pmap-c-police)#exceed-action drop
NetsTuts_R1(config-pmap-c-police)#exit
NetsTuts_R1(config-pmap-c)#exit

! ── Class 2: Routing protocols — generous rate ────────────
NetsTuts_R1(config-pmap)#class COPP-ROUTING
NetsTuts_R1(config-pmap-c)#police rate 256000 bps
NetsTuts_R1(config-pmap-c-police)#conform-action transmit
NetsTuts_R1(config-pmap-c-police)#exceed-action drop
NetsTuts_R1(config-pmap-c-police)#exit
NetsTuts_R1(config-pmap-c)#exit

! ── Class 3: Management traffic ───────────────────────────
NetsTuts_R1(config-pmap)#class COPP-MGMT
NetsTuts_R1(config-pmap-c)#police rate 64000 bps
NetsTuts_R1(config-pmap-c-police)#conform-action transmit
NetsTuts_R1(config-pmap-c-police)#exceed-action drop
NetsTuts_R1(config-pmap-c-police)#exit
NetsTuts_R1(config-pmap-c)#exit

! ── Class 4: ICMP — allow pings but rate-limit floods ─────
NetsTuts_R1(config-pmap)#class COPP-ICMP
NetsTuts_R1(config-pmap-c)#police rate 32000 bps
NetsTuts_R1(config-pmap-c-police)#conform-action transmit
NetsTuts_R1(config-pmap-c-police)#exceed-action drop
NetsTuts_R1(config-pmap-c-police)#exit
NetsTuts_R1(config-pmap-c)#exit

! ── Class 5: Default — rate-limit everything else ─────────
NetsTuts_R1(config-pmap)#class class-default
NetsTuts_R1(config-pmap-c)#police rate 64000 bps
NetsTuts_R1(config-pmap-c-police)#conform-action transmit
NetsTuts_R1(config-pmap-c-police)#exceed-action drop
NetsTuts_R1(config-pmap-c-police)#exit
NetsTuts_R1(config-pmap-c)#exit

NetsTuts_R1(config-pmap)#exit

The COPP-ATTACK class is placed first in the policy map — bogon traffic is identified and dropped before the router wastes CPU evaluating it against any other class. Routing protocols (COPP-ROUTING) receive the highest rate (256 kbps) with a transmit conform action — an over-aggressive rate limit here would drop OSPF Hellos and collapse adjacencies, which would be worse than the original attack. The class class-default at the end is mandatory — without it, unclassified traffic (ARP, DHCP, and unknown protocols) hits the implicit permit with no rate limit.

Rate sizing guidance: The rates in this lab (8–256 kbps) are illustrative starting points for a lightly loaded router. In production, use show policy-map control-plane in monitor-only mode first (all conform-action transmit, no drops) and observe the actual traffic rates hitting each class over a 24-hour period. Set your rate limits at 2–3× the observed peak to absorb legitimate bursts without dropping real traffic.

6. Step 4 — Apply the Policy to the Control Plane

The policy map is applied to the special control-plane interface — not a physical interface. This is the fundamental difference between CoPP and regular interface QoS. Only input direction is required for standard CoPP (protecting the CPU from inbound floods):

! ── Enter control-plane configuration mode ────────────────
NetsTuts_R1(config)#control-plane

! ── Apply the policy inbound (traffic arriving at the CPU)
NetsTuts_R1(config-cp)#service-policy input COPP-POLICY

NetsTuts_R1(config-cp)#exit

NetsTuts_R1(config)#end
NetsTuts_R1#wr
Building configuration...
[OK]
NetsTuts_R1#

After applying the service policy, CoPP is immediately active — there is no additional enable command. The control-plane global configuration mode is unique: it accepts only service-policy input (inbound to CPU) and service-policy output (generated by the router CPU). To remove CoPP entirely: control-plane then no service-policy input COPP-POLICY. Warning: if you accidentally drop management traffic (SSH) with an overly restrictive policy, you may lose access to the router — always test on a console session or with a recovery plan in place.

7. Step 5 — Audit Mode (Monitor Before Enforcing)

Best practice is to deploy CoPP in audit mode first — all classes use conform-action transmit and exceed-action transmit so no traffic is dropped. This lets you observe what is hitting each class and at what rate before enabling drops. Configure a separate audit policy map for this purpose:

! ── Create an audit-only policy — no drops, just counting ─
NetsTuts_R1(config)#policy-map COPP-AUDIT
NetsTuts_R1(config-pmap)#class COPP-ATTACK
NetsTuts_R1(config-pmap-c)#police rate 8000 bps
NetsTuts_R1(config-pmap-c-police)#conform-action transmit
NetsTuts_R1(config-pmap-c-police)#exceed-action transmit
NetsTuts_R1(config-pmap-c-police)#exit
NetsTuts_R1(config-pmap-c)#exit

NetsTuts_R1(config-pmap)#class COPP-ROUTING
NetsTuts_R1(config-pmap-c)#police rate 256000 bps
NetsTuts_R1(config-pmap-c-police)#conform-action transmit
NetsTuts_R1(config-pmap-c-police)#exceed-action transmit
NetsTuts_R1(config-pmap-c-police)#exit
NetsTuts_R1(config-pmap-c)#exit

NetsTuts_R1(config-pmap)#class COPP-MGMT
NetsTuts_R1(config-pmap-c)#police rate 64000 bps
NetsTuts_R1(config-pmap-c-police)#conform-action transmit
NetsTuts_R1(config-pmap-c-police)#exceed-action transmit
NetsTuts_R1(config-pmap-c-police)#exit
NetsTuts_R1(config-pmap-c)#exit

NetsTuts_R1(config-pmap)#class COPP-ICMP
NetsTuts_R1(config-pmap-c)#police rate 32000 bps
NetsTuts_R1(config-pmap-c-police)#conform-action transmit
NetsTuts_R1(config-pmap-c-police)#exceed-action transmit
NetsTuts_R1(config-pmap-c-police)#exit
NetsTuts_R1(config-pmap-c)#exit

NetsTuts_R1(config-pmap)#class class-default
NetsTuts_R1(config-pmap-c)#police rate 64000 bps
NetsTuts_R1(config-pmap-c-police)#conform-action transmit
NetsTuts_R1(config-pmap-c-police)#exceed-action transmit
NetsTuts_R1(config-pmap-c-police)#exit
NetsTuts_R1(config-pmap-c)#exit
NetsTuts_R1(config-pmap)#exit

! ── Apply audit policy — observe for 24 hours ─────────────
NetsTuts_R1(config)#control-plane
NetsTuts_R1(config-cp)#service-policy input COPP-AUDIT
NetsTuts_R1(config-cp)#exit

! ── After observation, swap to enforcement policy ─────────
! NetsTuts_R1(config)#control-plane
! NetsTuts_R1(config-cp)#no service-policy input COPP-AUDIT
! NetsTuts_R1(config-cp)#service-policy input COPP-POLICY

After running COPP-AUDIT for 24 hours (or during a known attack), run show policy-map control-plane and check the exceed counters on each class. A class with high exceed counts means your rate limit is below the normal traffic level — increase the rate before switching to the enforcement policy. Zero exceed counts mean the rate is sufficient and drops will not affect normal operations.

8. Verification

show policy-map control-plane

NetsTuts_R1#show policy-map control-plane
Control Plane

  Service-policy input: COPP-POLICY

    Class-map: COPP-ATTACK (match-all)
      0 packets, 0 bytes
      5 minute offered rate 0000 bps, drop rate 0000 bps
      Match: access-group name ACL-COPP-ATTACK
      police:
          rate 8000 bps, burst 1500 bytes
        conformed 0 packets, 0 bytes; actions: drop
        exceeded 0 packets, 0 bytes; actions: drop
        conformed 0000 bps, exceeded 0000 bps

    Class-map: COPP-ROUTING (match-all)
      1847 packets, 184700 bytes
      5 minute offered rate 12000 bps, drop rate 0000 bps
      Match: access-group name ACL-COPP-ROUTING
      police:
          rate 256000 bps, burst 8000 bytes
        conformed 1847 packets, 184700 bytes; actions: transmit
        exceeded 0 packets, 0 bytes; actions: drop
        conformed 12000 bps, exceeded 0000 bps

    Class-map: COPP-MGMT (match-all)
      312 packets, 28672 bytes
      5 minute offered rate 4000 bps, drop rate 0000 bps
      Match: access-group name ACL-COPP-MGMT
      police:
          rate 64000 bps, burst 4000 bytes
        conformed 312 packets, 28672 bytes; actions: transmit
        exceeded 0 packets, 0 bytes; actions: drop
        conformed 4000 bps, exceeded 0000 bps

    Class-map: COPP-ICMP (match-all)
      48 packets, 4800 bytes
      5 minute offered rate 1000 bps, drop rate 0000 bps
      Match: access-group name ACL-COPP-ICMP
      police:
          rate 32000 bps, burst 1500 bytes
        conformed 48 packets, 4800 bytes; actions: transmit
        exceeded 0 packets, 0 bytes; actions: drop
        conformed 1000 bps, exceeded 0000 bps

    Class-map: class-default (match-any)
      89 packets, 7992 bytes
      5 minute offered rate 2000 bps, drop rate 0000 bps
      Match: any
      police:
          rate 64000 bps, burst 4000 bytes
        conformed 89 packets, 7992 bytes; actions: transmit
        exceeded 0 packets, 0 bytes; actions: drop
        conformed 2000 bps, exceeded 0000 bps

This output shows normal operation — COPP-ROUTING is passing 1,847 packets (OSPF Hellos and LSAs) at 12 kbps, well within the 256 kbps rate. All exceeded counters are zero, confirming no legitimate traffic is being dropped. COPP-ATTACK shows 0 packets — no bogon-sourced traffic has arrived yet. During an active ICMP flood attack, the COPP-ICMP exceeded counter would increment rapidly while the conformed counter stabilises at the rate limit.

show policy-map control-plane — During an ICMP Flood Attack

NetsTuts_R1#show policy-map control-plane
    Class-map: COPP-ICMP (match-all)
      82941 packets, 8294100 bytes
      5 minute offered rate 890000 bps, drop rate 858000 bps
      Match: access-group name ACL-COPP-ICMP
      police:
          rate 32000 bps, burst 1500 bytes
        conformed 2981 packets, 298100 bytes; actions: transmit
        exceeded 79960 packets, 7996000 bytes; actions: drop
        conformed 32000 bps, exceeded 858000 bps

Under attack: 890 kbps of ICMP is arriving at the control plane. CoPP allows only 32 kbps (conformed) through to the CPU — the remaining 858 kbps (exceeded) is dropped before it reaches the processor. The router CPU is protected and routing protocol adjacencies remain stable. This is CoPP working exactly as designed.

show policy-map control-plane input — Direction-Specific

NetsTuts_R1#show policy-map control-plane input
! ── Same output as above — the input keyword filters to the
! ── inbound direction only. Useful when both input and output
! ── policies are configured.

clear counters — Reset Policy Map Counters

! ── Reset all interface and policy-map counters ───────────
NetsTuts_R1#clear counters

! ── Confirm counters reset before running a test ──────────
NetsTuts_R1#show policy-map control-plane
! All packet/byte counters will show 0 after the reset

show running-config | section control-plane

NetsTuts_R1#show running-config | section control-plane
control-plane
 service-policy input COPP-POLICY

show class-map — Verify Class Map Definitions

NetsTuts_R1#show class-map
 Class Map match-all COPP-ATTACK (id 1)
   Match access-group name ACL-COPP-ATTACK

 Class Map match-all COPP-ROUTING (id 2)
   Match access-group name ACL-COPP-ROUTING

 Class Map match-all COPP-MGMT (id 3)
   Match access-group name ACL-COPP-MGMT

 Class Map match-all COPP-ICMP (id 4)
   Match access-group name ACL-COPP-ICMP

 Class Map match-any class-default (id 0)
   Match any

Verification Command Summary

Command	What It Shows	Primary Use
`show policy-map control-plane`	All CoPP classes — packet/byte counts, offered rate, drop rate, conformed/exceeded counters per class	Primary verification — confirm CoPP is active and check which classes are dropping traffic
`show policy-map control-plane input`	Inbound CoPP policy only — same data filtered to input direction	When both input and output policies exist; isolates inbound protection stats
`show class-map`	All class map definitions — name, match type (match-all / match-any), and match criteria	Confirm class maps reference the correct ACLs and use the correct match logic
`show policy-map`	All policy map definitions — class names, police rates, conform/exceed actions (without live counters)	Audit policy configuration — verify rates and actions before applying
`show ip access-lists`	ACL match counters — shows how many packets each ACL entry has matched	Confirm CoPP ACLs are classifying the expected traffic types. ACL counters increment when the class map matches. See ACL Overview.
`show running-config \| section control-plane`	Control plane configuration — confirms service policy is applied and in which direction	Quick check that CoPP is applied — does not show live counters
`clear counters`	Resets all interface and policy-map counters to zero	Reset before a controlled test to get clean baseline data

9. Troubleshooting CoPP Issues

Problem	Symptom	Cause	Fix
SSH management access lost after CoPP applied	Cannot SSH to the router — connection times out or is refused immediately after enabling the policy	COPP-MGMT rate limit is too low for the SSH handshake burst, or the ACL-COPP-MGMT does not correctly match TCP/22 to the router's management IP, or SSH traffic is falling into class-default which has a very restrictive rate	Use console access to troubleshoot. Run `show policy-map control-plane` — check exceeded counters on COPP-MGMT and class-default. Increase the COPP-MGMT rate or temporarily set exceed-action transmit. Verify ACL-COPP-MGMT with `show ip access-lists ACL-COPP-MGMT` — confirm TCP/22 entries are matching
OSPF adjacency drops after CoPP applied	OSPF neighbours drop within 40 seconds (Dead interval) of applying CoPP — router sees `%OSPF-5-ADJCHG: ... Down: Dead timer expired`	COPP-ROUTING rate limit is too low to pass the volume of OSPF Hellos and LSA flooding, or the ACL-COPP-ROUTING does not include `permit ospf any any`, so OSPF packets fall into class-default and are dropped there	Increase COPP-ROUTING rate to 512 kbps or higher. Verify with `show ip access-lists ACL-COPP-ROUTING` that the ospf permit entry is incrementing. If ospf matches are zero, the ACL syntax is wrong — check `permit ospf any any` (not `permit ip`). See OSPF Neighbor States for adjacency troubleshooting.
CoPP not matching any traffic — all counters at zero	`show policy-map control-plane` shows 0 packets across all classes despite active routing protocols and management sessions	The service policy is applied in the wrong direction (output instead of input), or the policy map references class maps that do not exist (typo in class map name), or the ACLs are empty / incorrectly defined	Check `show running-config \| section control-plane` — confirm `service-policy input` (not output). Check `show class-map` — confirm class maps exist and reference ACLs by exact name. Run `show ip access-lists` to see if the CoPP ACLs have any permit entries
Routing protocol traffic hitting class-default	COPP-ROUTING counters show zero packets; class-default counters are very high	The ACL-COPP-ROUTING does not match the routing protocol packets — common cause is using `permit ip any any` instead of `permit ospf any any`, or a missing EIGRP entry	Run `show ip access-lists ACL-COPP-ROUTING` and check which lines have non-zero match counts. Add missing protocol entries (`permit ospf any any`, `permit eigrp any any`). Clear counters and re-test
Attack traffic not being dropped	CPU utilisation remains high despite COPP-ATTACK being configured — `show processes cpu` still shows CPU at 99%	Attack traffic does not match the COPP-ATTACK ACL — the source addresses in the attack are not RFC 1918 / bogon ranges, or the attack is using valid public IP sources. Alternatively, the COPP-ATTACK class is positioned after another class that matches first	Capture a sample of attack traffic with `debug ip packet` (filtered) to identify source addresses and protocol. Update ACL-COPP-ATTACK to match the actual attack signature. Confirm COPP-ATTACK is the first class in the policy map (checked with `show policy-map COPP-POLICY`)
IOS rejects `police rate` syntax	IOS returns `% Invalid input detected` when entering `police rate 256000 bps`	Some older IOS versions use a different policer syntax — the `rate` keyword was introduced in later MQC versions. Older IOS uses `police [bps] [burst-bytes] conform-action ... exceed-action ...` on a single line	Use the older single-line syntax: `police 256000 8000 conform-action transmit exceed-action drop`. The values are: CIR in bps, normal burst in bytes, then actions inline. Check IOS version with `show version`

Key Points & Exam Tips

CoPP protects the router CPU from denial-of-service attacks by rate-limiting traffic destined for the control plane (routing protocols) and management plane (SSH, SNMP, NTP). Transit data-plane traffic is not affected — it is forwarded by hardware and never touches the CPU.
CoPP uses the MQC framework: define ACLs → create class maps referencing those ACLs → build a policy map with a policer per class → apply to control-plane with service-policy input.
The service policy is applied to the control-plane global configuration interface — not a physical interface. This is the key syntax distinction from interface-based QoS.
Always include class class-default in the policy map with an explicit rate limit — without it, all unclassified control-plane traffic passes with no restriction.
Place the attack/drop class first in the policy map so malicious traffic is classified and dropped before the router evaluates it against legitimate protocol classes.
Never set a zero rate on routing protocol classes — dropping OSPF or BGP traffic collapses adjacencies and causes a network-wide outage. Set routing protocol rates generously (256 kbps or higher) and always use conform-action transmit.
Deploy in audit mode first (all exceed-actions set to transmit, no drops) and observe show policy-map control-plane counters over 24 hours before enabling drop actions. This prevents accidentally blocking legitimate traffic.
BGP requires two ACL entries — one for inbound connections to TCP/179 and one for established sessions where the source port is 179 — because BGP peers initiate connections from both directions.
show policy-map control-plane is the primary verification command — read the conformed and exceeded counters per class to confirm traffic is being classified correctly and rate limiting is not over-aggressive.
On the exam: know the three-step MQC process for CoPP, the control-plane application syntax, why class-default must be explicitly rate-limited, and how to read show policy-map control-plane output to distinguish normal from attack traffic.

Next Steps: CoPP rate-limits traffic reaching the CPU but does not inspect the content of management sessions. Harden SSH access further with ACL-based restrictions at SSH Configuration and AAA with Local and RADIUS. For OSPF authentication to prevent routing protocol spoofing attacks that could bypass CoPP classification, see OSPF Single-Area Configuration Lab. For logging CoPP drop events to a syslog server, review Syslog Configuration Lab and show logging. For monitoring CPU utilisation before and after CoPP, use show version and show processes cpu sorted. For complementary data-plane rate limiting on switch ports, see Storm Control & Traffic Shaping.

TEST WHAT YOU LEARNED

1. What is the fundamental difference between how CoPP and a standard interface ACL protect a router from a flood attack?

A. They are equivalent — an inbound ACL on the WAN interface that drops flood traffic achieves the same CPU protection as CoPP B. CoPP works at Layer 2 and protects against MAC flooding; interface ACLs work at Layer 3 and protect against IP floods C. An interface ACL drops or permits all traffic entering that one physical interface — it cannot rate-limit, and it must be applied per interface. CoPP is applied once to the control-plane and rate-limits traffic from all interfaces arriving at the CPU, using policers that allow normal volumes while dropping flood-level excess — providing protection regardless of which interface the attack arrives on D. Interface ACLs protect the control plane; CoPP protects the data plane by rate-limiting transit forwarding traffic

Correct answer is C. A standard interface ACL is binary — permit or deny — and must be duplicated on every interface where the attack could arrive. It also cannot distinguish between a legitimate 1 kbps ICMP ping and a 100 Mbps ICMP flood — both are either permitted or denied entirely. CoPP uses policing (a token-bucket rate limiter) to allow traffic up to a defined rate and drop only the excess. It is applied globally to the control-plane, so it protects the CPU from floods arriving on any interface — WAN, LAN, or management. A well-designed CoPP policy allows normal ICMP (conforming) while dropping the flood-level excess without blocking legitimate pings.

2. After applying a CoPP policy, OSPF adjacencies drop within 40 seconds. `show policy-map control-plane` shows high exceeded counters on COPP-ROUTING. What is the most appropriate fix?

A. Increase the police rate on the COPP-ROUTING class — the current rate limit is dropping legitimate OSPF Hellos and LSAs faster than the Dead interval, causing the adjacency to expire. Increase to 512 kbps or higher and re-verify that exceeded counters drop to zero during normal operation B. Remove OSPF from the COPP-ROUTING class entirely — routing protocols should be in class-default, not a specific class C. Change the COPP-ROUTING conform-action from transmit to drop and the exceed-action from drop to transmit — this inverts the logic and allows burst OSPF traffic through D. Reduce the OSPF Hello interval to 1 second so that more Hellos are sent and some survive the rate limit

Correct answer is A. High exceeded counters on COPP-ROUTING mean the volume of routing protocol traffic is exceeding the configured rate limit — legitimate OSPF Hellos and LSA flooding are being dropped. OSPF will drop an adjacency after the Dead interval (default 40 seconds) if no Hellos are received. The fix is to increase the police rate to accommodate the actual OSPF traffic volume. Use audit mode (exceed-action transmit) temporarily to measure the real offered rate, then set the enforcement rate at 2–3× that value. Reducing the Hello interval (option D) would increase OSPF traffic volume, worsening the problem. Inverting conform/exceed actions (option C) makes no sense — conform means within-rate traffic, which should always be transmitted for routing protocols.

3. Where is a CoPP service policy applied, and why is this different from a QoS policy on a physical interface?

A. CoPP is applied under interface Loopback0 — the loopback represents the router's own IP address and therefore all control-plane traffic B. CoPP is applied under each physical interface with service-policy input — it must be duplicated on every interface to provide full protection C. CoPP is applied globally under ip traffic-export — this intercepts all traffic before routing decisions are made D. CoPP is applied under the control-plane global configuration mode with service-policy input. This is a virtual interface representing traffic destined for the router CPU regardless of which physical interface it arrives on — a single application protects all interfaces simultaneously. A physical interface service policy only polices traffic on that specific interface and has no effect on CPU-bound traffic arriving elsewhere

Correct answer is D. The control-plane configuration mode is unique to CoPP. It is not a physical interface — it represents the internal path between all interfaces and the router CPU. Traffic destined for the router (routing protocol updates, SSH sessions, pings to the router) from any physical interface all converge at the control plane. Applying a service policy here once protects the CPU regardless of attack entry point. A QoS policy on a physical interface (e.g., Gi0/0) only affects traffic on that interface — an attacker could simply use a different interface. The loopback interface is a routing construct, not a traffic interception point. control-plane is the correct and only IOS mechanism for CoPP.

4. A CoPP policy has five classes in this order: COPP-ATTACK, COPP-ROUTING, COPP-MGMT, COPP-ICMP, class-default. An OSPF Hello packet with a spoofed source address that matches both ACL-COPP-ATTACK and ACL-COPP-ROUTING arrives. Which class processes it?

A. COPP-ROUTING — routing protocol classification takes precedence over attack classification regardless of order B. COPP-ATTACK — CoPP policy map processing uses first-match logic, identical to ACL processing. COPP-ATTACK is first in the policy map, so the packet is matched there and the policer drops it. COPP-ROUTING is never evaluated for this packet C. Both classes process the packet simultaneously — the most restrictive action (drop) wins D. class-default — when a packet matches multiple classes, it falls through to the default class

Correct answer is B. MQC policy maps use first-match processing — exactly like ACLs. The router evaluates each class map in the order they appear in the policy map, and the first class whose match criteria are satisfied wins. All remaining classes are skipped for that packet. This is precisely why placing COPP-ATTACK first in the policy map is critical — spoofed routing protocol packets (which might also match COPP-ROUTING) are caught and dropped by COPP-ATTACK before they get a chance to match the more permissive COPP-ROUTING class. If the order were reversed (COPP-ROUTING first), a spoofed OSPF packet would be classified as legitimate routing traffic and permitted through — defeating the attack protection.

5. What does the `class class-default` entry in a CoPP policy map match, and what happens if it is omitted?

A. class class-default matches only IPv4 traffic — IPv6 and non-IP protocols are always dropped. Omitting it has no effect on IPv4 CoPP operation B. class class-default is the same as class COPP-ATTACK — both drop unrecognised traffic. Omitting it is safe because unknown traffic is automatically dropped C. class class-default matches all traffic that did not match any named class earlier in the policy map. If it is omitted from the policy map, unclassified traffic (ARP, DHCP, CDP, and unrecognised protocols destined for the CPU) passes to the CPU with no rate limit — an attacker using a protocol not in any named class could still flood the CPU unrestricted D. class class-default is automatically configured with a drop action when CoPP is applied — explicit configuration is not needed

Correct answer is C. class class-default is the MQC catch-all — it matches every packet that did not match a preceding named class. In a CoPP context, this includes protocols not explicitly classified: ARP (used for neighbour resolution), CDP (Cisco Discovery Protocol), DHCP requests destined for the router, and any future or unknown protocols. If class-default is omitted from the policy map, these packets still reach the CPU — but with no policing at all. An attacker who identifies that their traffic type is not in any named CoPP class can still flood the CPU unconstrained. Always include class-default with a conservative rate limit (e.g., 64 kbps with exceed-action drop) as a safety net. Unlike interface ACLs, MQC policy maps do not have an implicit deny — unmatched traffic is forwarded without any restriction unless class-default explicitly controls it.

6. Why does the ACL for BGP in a CoPP policy require two entries — one matching destination port 179 and one matching source port 179?

A. BGP uses UDP/179 for keepalives and TCP/179 for updates — the two entries cover both transport protocols B. One entry covers BGP for IPv4 (AFI 1) and the other covers BGP for IPv6 (AFI 2) — both address families use the same port but must be classified separately C. BGP uses port 179 as both source and destination simultaneously — IOS requires two entries to cover the bidirectional session D. BGP sessions use TCP/179 as the destination port when a peer initiates a new connection to this router (entry 1: permit tcp any any eq 179). On an established session, the remote peer may send data from its source port 179 — particularly when this router originally initiated the connection and the peer is responding from port 179 (entry 2: permit tcp any eq 179 any). Both directions of the TCP session must be classified to prevent BGP keepalives from falling into class-default and being rate-limited too aggressively

Correct answer is D. BGP uses TCP port 179. When a BGP peer connects to this router, the incoming SYN packet has destination port 179 (the well-known BGP port on this router) and an ephemeral source port above 1024. Entry 1 (permit tcp any any eq 179) matches these inbound connection attempts. However, when this router initiated the BGP session to the peer, the peer is listening on port 179 — the peer's responses come back with source port 179 and a destination port that is the ephemeral port this router chose. Entry 2 (permit tcp any eq 179 any) catches these return packets. Without both entries, half the BGP TCP traffic for certain session setups falls into class-default and may be rate-limited too aggressively, causing BGP hold-timer expiry. BGP is purely TCP (never UDP) — it uses TCP for reliable delivery of routing updates.

7. An engineer wants to verify CoPP is working during a live ICMP flood. Which output field in `show policy-map control-plane` most directly confirms the flood is being suppressed?

A. The drop rate and exceeded packets/bytes counters on the COPP-ICMP class — a rapidly incrementing exceeded counter with a high drop rate (e.g., 858000 bps) confirms flood traffic is being dropped before reaching the CPU, while the conformed counter stabilising at the rate limit confirms legitimate ICMP is still passing through B. The offered rate on class-default — if it is low, the flood is being suppressed C. The conformed packets counter on COPP-ATTACK — if this is incrementing, the attack is being caught D. The 5-minute offered rate alone — if it is above 32 kbps on COPP-ICMP the flood is occurring but not necessarily being suppressed

Correct answer is A. The key fields during an active attack are the exceeded counters and drop rate on the relevant class. The conformed counter stabilising at the rate limit (e.g., 32000 bps for COPP-ICMP) confirms the policer is working — exactly the configured rate passes through. The exceeded counter incrementing rapidly and the drop rate matching the flood volume confirm that excess traffic is being dropped before reaching the CPU. The offered rate alone (option D) only tells you the total attack rate, not whether it is being dropped. The class-default offered rate (option B) would be low if ICMP is correctly classified in COPP-ICMP, but a low class-default rate doesn't directly confirm ICMP suppression. The COPP-ATTACK conformed counter (option C) would increment if ICMP packets have bogon sources — but normal flood traffic with valid source IPs would be in COPP-ICMP, not COPP-ATTACK.

8. What is the purpose of deploying CoPP in audit mode before enabling drop actions, and how is audit mode configured?

B. Audit mode lets you observe which classes are matching traffic and at what rate without dropping anything. It is configured by setting both conform-action transmit and exceed-action transmit on all classes — the policer still counts packets and measures rates, but forwards everything regardless of whether it exceeds the limit. After 24 hours of observation, the conformed and exceeded counters reveal whether the configured rates are too low (high exceeded counts) or appropriately sized (zero exceeded counts) A. Audit mode uses police rate 0 bps to disable all rate limiting — this passes all traffic and resets counters every 60 seconds for statistical sampling C. Audit mode is a separate IOS feature enabled with control-plane audit enable — it runs in parallel with the enforcement policy and does not require a separate policy map D. Audit mode applies the CoPP policy to a loopback interface first — if the loopback functions normally, the policy is then moved to the control-plane

Correct answer is B. Audit mode is not a special IOS feature — it is simply a design practice where you configure the policy map with exceed-action transmit instead of exceed-action drop. The policer still operates and counts packets in the conformed and exceeded buckets, but it forwards traffic in both cases instead of dropping over-rate traffic. This gives you full visibility into the real traffic rates hitting each class without any risk of accidentally blocking legitimate traffic. After observing the exceeded counts over a representative period (ideally 24 hours including peak traffic), you can tune the rate limits and switch the exceed-action to drop. This approach prevents the most common CoPP mistake: setting a rate limit that is correct for normal traffic but too low to absorb legitimate protocol bursts, which would cause routing adjacency drops as soon as the enforcement policy is applied.

9. Which of the following traffic types is not processed by CoPP and why?

A. OSPF Hello packets — these are control-plane packets and are processed by CoPP B. SSH sessions to the router's management IP — these are management-plane packets and are processed by CoPP C. HTTP traffic passing through the router from a client to a web server — this is data-plane (transit) traffic. The source and destination are not the router itself. Transit traffic is forwarded by the hardware ASIC using Cisco Express Forwarding (CEF) and never touches the CPU. CoPP only processes traffic destined for the router CPU — transit traffic is invisible to CoPP D. SNMP polls to the router's management IP — these are management-plane packets and are processed by CoPP

Correct answer is C. CoPP protects the router CPU by policing traffic that is punted to the CPU for processing. Transit traffic — packets where the router is simply an intermediate forwarder, not the source or destination — is handled entirely in hardware by CEF (Cisco Express Forwarding) and the forwarding ASIC. These packets are never sent to the CPU and therefore are never subject to CoPP. An HTTP stream from a client (10.1.0.10) to a web server (10.2.0.10) through the router is transit traffic — the router looks up the destination in the FIB, rewrites the Layer 2 header, and forwards the packet without CPU involvement. Only packets destined for the router (routing protocol updates, management sessions, ICMP to the router's own IPs) reach the control plane and are subject to CoPP policing.

10. After applying CoPP, `show policy-map control-plane` shows 0 packets matched across all classes including class-default, despite active OSPF and SSH sessions. What is the most likely cause?

A. The router has no routing protocol configured — OSPF must be running for control-plane traffic to exist B. CoPP counters only update every 5 minutes — wait for the next polling interval C. The class maps are using match-all — change to match-any so the single ACL criterion is sufficient to match D. The service policy was applied with service-policy output instead of service-policy input — output CoPP polices traffic generated by the router CPU heading out to interfaces, not inbound control-plane traffic arriving at the CPU. Verify with show running-config | section control-plane and correct to service-policy input COPP-POLICY

Correct answer is D. Zero matches across all classes including class-default (which matches everything) is the strongest indicator that the policy is applied in the wrong direction. The control-plane interface supports both service-policy input (polices traffic arriving at the CPU from the network) and service-policy output (polices traffic generated by the CPU heading to the network). If service-policy output was configured, inbound OSPF Hellos, SSH packets, and all other control-plane traffic would completely bypass the policy — producing the zero-counter symptom. Run show running-config | section control-plane to check. If output is shown, remove it (no service-policy output COPP-POLICY) and apply in the correct direction (service-policy input COPP-POLICY). match-all vs match-any (option C) is irrelevant when only one match criterion exists per class map — a single criterion is satisfied by either logic.

Back to Home