Protecting the Network Control Plane
Learn how Cisco IOS control-plane protection works, including CoPP, CPPr, routing authentication, policy design, validation, and troubleshooting.
The control plane is the processing domain that keeps a network operating. It handles protocol exchanges and decisions used to discover neighbors, learn topology, calculate reachability, and maintain network state. Protecting it prevents excessive or unauthorized traffic from consuming the CPU and disrupting routing.
This lesson covers Control Plane Policing (CoPP), Cisco Control Plane Protection (CPPr), and routing-protocol authentication. It assumes familiarity with basic security terms, IPv4 routing, ACLs, Cisco IOS configuration modes, SSH, and Cisco Express Forwarding (CEF).
Understand the Network Planes
A network device commonly performs three related but distinct jobs:
- Control plane: Processes device-to-device signaling and protocols needed for discovery, topology learning, reachability, and network operation.
- Data plane: Forwards ordinary user and application packets according to installed forwarding information.
- Management plane: Provides administrative access for configuration, monitoring, and operational control, such as SSH.
| Plane | Primary function | Typical traffic | Main security concern | Representative protection |
|---|---|---|---|---|
| Control plane | Maintains topology, reachability, and device operation | Routing updates, ARP processing, neighbor discovery, keepalives, and exception packets | CPU or memory exhaustion and unauthorized protocol information | CoPP, CPPr, routing authentication, infrastructure ACLs |
| Data plane | Forwards ordinary transit traffic | User application packets forwarded using the FIB and adjacency information | Unauthorized access, spoofing, and resource abuse | Interface ACLs, anti-spoofing, segmentation, and QoS |
| Management plane | Provides administrative control and monitoring | SSH, AAA, SNMP, logging, and device-management sessions | Unauthorized access and management-service floods | Secure SSH, AAA, management ACLs, and rate limiting |
The boundaries are useful, but not every CPU-processed packet is a routing update. Some management traffic and some transit traffic require CPU attention even though they are not ordinary control-protocol messages.
Examples of control-plane and CPU-bound traffic
- OSPF, EIGRP, BGP, or other routing-protocol updates and keepalives.
- ARP requests, replies, and related address-resolution processing.
- Neighbor-discovery messages and device-to-device protocol signaling.
- Packets with expired TTL values, which may require an ICMP response.
- Packets containing IP options or other features that cannot be handled by the normal hardware-forwarding path.
- SSH and other packets addressed to the router that require local CPU processing.
- Packets punted from CEF because they represent a forwarding exception.
CPU-bound traffic means packets that must be examined or processed by the device CPU instead of being handled entirely by hardware forwarding. This traffic is an important protection boundary because the CPU has finite processing capacity.
Why Protect the Control Plane?
Routing and convergence depend on CPU-based protocol processing. A router must receive and process routing messages, maintain neighbor relationships, calculate or install routes, and respond to operational events. If excessive packets consume CPU or memory, ordinary forwarding may continue temporarily while control functions degrade.
CPU exhaustion can cause:
- Delayed routing updates and slow topology changes.
- Lost routing adjacencies because keepalives or protocol messages are not processed in time.
- Poor convergence after a link or device failure.
- Unavailable or unreliable SSH and other management access.
- Incorrect, stale, or unavailable forwarding information.
- Increased packet loss, instability, or complete loss of network connectivity.
Overload can be accidental, such as a routing loop, a broadcast storm, a new monitoring system, or an unexpectedly large number of exception packets. It can also be intentional:
- A flood of routing-protocol packets or forged neighbor messages.
- A flood of SSH or other management-access attempts.
- Malformed packets designed to trigger expensive processing.
- Large numbers of packets requiring CEF exceptions or special handling.
- Attempts to introduce unauthorized routing information.
Control-plane protection reduces the impact of these events, but it does not replace secure management, interface ACLs, anti-spoofing, or routing authentication.
Control Plane Policing (CoPP)
Control Plane Policing (CoPP) is a Cisco IOS mechanism that applies QoS policing to packets handled by the route processor or device CPU. CoPP is normally configured with the Modular QoS CLI (MQC) framework:
- An ACL or other match condition identifies traffic.
- A class map groups matching packets into a named traffic category.
- A policy map assigns an action, such as policing, to each class.
- The policy is attached to the aggregate control-plane interface with a service policy.
A class map identifies traffic through match statements. Depending on the platform and IOS release, classification can use protocol, source or destination address, an ACL, DSCP, or other supported conditions.
A policer permits traffic up to a configured rate and applies an action to excess traffic. Conforming traffic can be transmitted to the CPU. Exceeding traffic can be dropped or, where supported and appropriate, remarked. The rate must be high enough for legitimate operation but low enough to limit abuse.
CoPP policy categories
A practical policy usually separates traffic into categories rather than applying one broad rule:
- Critical routing and infrastructure protocols: Routing updates, neighbor messages, and required infrastructure signaling. These need carefully sized allowances.
- Management traffic: Authorized SSH and other required administrative services. Management should be limited without preventing normal administration.
- Normal control traffic: ARP, discovery, keepalives, and other expected device-operation traffic.
- Undesirable traffic: Untrusted, spoofed, malformed, or unnecessary traffic that should be dropped or strictly limited.
- Default class: Traffic not matched by an explicit class. Its treatment should be deliberate rather than accidental.
Place essential protocol classes before broad default-drop or default-police behavior. For example, an SSH class can restrict a flood of connection attempts while allowing normal authorized sessions.
Illustrative CoPP policy
ip access-list extended COPP-SSH
permit tcp any host 192.0.2.1 eq 22
class-map match-any COPP-SSH-CLASS
match access-group name COPP-SSH
policy-map COPP-POLICY
class COPP-SSH-CLASS
police 64000 conform-action transmit exceed-action drop
class class-default
police 1000000 conform-action transmit exceed-action drop
control-plane
service-policy input COPP-POLICYSSH flood example
Suppose a router receives a large number of TCP connections destined for SSH. Without protection, each attempt may consume CPU resources for connection handling and authentication processing. An ACL can identify TCP port 22 traffic destined for the router, and a CoPP class can police that traffic.
- Packets within the configured allowance continue to the CPU.
- Excess packets are discarded according to the policy.
- Authorized administrators can continue to connect when their traffic stays within the normal allowance.
- Class counters and CPU utilization show whether the limit is appropriate.
CoPP is not an access-control mechanism by itself. Use it with management-plane protection, secure SSH configuration, AAA, routing authentication, interface ACLs, and anti-spoofing controls.
Cisco Control Plane Protection (CPPr)
Cisco Control Plane Protection (CPPr) extends CoPP by permitting more granular classification of CPU-bound and exception traffic. CoPP protects the aggregate control plane. CPPr separates that aggregate into three logical subinterfaces so different traffic types can receive different policing treatment.
- Host subinterface: Packets addressed to a router's physical or logical interface that require CPU processing. Examples include routing protocols, ARP-related processing, and management traffic such as SSH.
- Transit subinterface: Packets that would otherwise be forwarded through the device but require CPU intervention before continuing. Packets using IP options are an example.
- CEF-exception subinterface: Packets punted from Cisco Express Forwarding for a network-operation exception. Examples include keepalives and packets whose TTL expires.
CPPr lets an administrator apply different limits to host, transit, and CEF-exception traffic. For example, management and routing traffic can be allowed on the host category, suspicious transit packets requiring CPU examination can be restricted more aggressively, and TTL-expired traffic can receive a separately sized allowance.
| Subinterface | Traffic direction or purpose | Examples | Policy objective |
|---|---|---|---|
| Host | Traffic addressed to the device and requiring CPU processing | Routing updates, ARP, neighbor messages, SSH | Protect essential local services while limiting management and protocol abuse |
| Transit | Traffic that is being forwarded but needs CPU intervention | Packets using IP options or other special forwarding features | Restrict expensive or suspicious transit exceptions |
| CEF-exception | Traffic punted from CEF for an operational exception | Keepalives, TTL-expired packets, and related exception traffic | Allow normal exceptions while preventing exception floods |
control-plane host
service-policy input HOST-COPP-POLICY
control-plane transit
service-policy input TRANSIT-COPP-POLICY
control-plane cef-exception
service-policy input CEF-EXCEPTION-COPP-POLICY| Feature | Traffic scope | Classification granularity | Configuration attachment point | Primary use case |
|---|---|---|---|---|
| CoPP | Aggregate traffic reaching the control plane | Classes based on protocols, addresses, ACLs, DSCP, and supported match criteria | Aggregate control-plane interface | Establish an overall CPU traffic policy |
| CPPr | CPU-bound host, transit, and CEF-exception traffic | Separate policy treatment for three logical processing paths | Host, transit, and CEF-exception control-plane subinterfaces | Add separation and precision when one aggregate policy is insufficient |
Routing-Protocol Authentication
A device that accepts unauthenticated routing updates may trust a rogue router as if it were a legitimate neighbor. The rogue device could advertise a more attractive route, inject false topology information, or repeatedly form and drop adjacencies.
Unauthenticated route advertisements can:
- Alter routing tables and redirect traffic through an unauthorized device.
- Create black holes by advertising unreachable destinations.
- Enable traffic inspection or interception by causing traffic to take an attacker-controlled path.
- Destabilize the network through repeated topology changes.
Routing protocol authentication requires valid authentication information before routing exchanges are accepted. Depending on the protocol and platform, this may use a shared password or cryptographic message authentication. Legitimate adjacent routers must use compatible authentication parameters.
Authentication is configured per routing protocol and often per interface or neighbor relationship. Secure key handling matters: protect configuration access, avoid exposing secrets in operational documents, use consistent key identifiers where applicable, and rotate keys through a controlled process. Modern platform and protocol guidance may favor stronger cryptographic options than legacy MD5 where supported.
OSPF message-digest example
interface GigabitEthernet0/0
ip ospf message-digest-key 1 md5 EXAMPLE-KEY
ip ospf authentication message-digestAn unauthorized device that lacks the required authentication parameters should fail to establish a valid adjacency or have its updates rejected. Legitimate neighbors with matching settings remain operational.
Authentication validates the origin or integrity of routing exchanges; it does not limit packet rates and does not fully protect the CPU from denial-of-service floods. Use authentication together with CoPP or CPPr and appropriate interface controls.
Control-Plane Policy Design
Build a baseline before enforcing policing. Record normal protocol rates, expected management activity, trusted peer addresses, required services, and traffic patterns during convergence and failure recovery. This prevents a policy from treating a legitimate event as an attack.
| Traffic class | Examples | Trust level | Recommended action | Validation metric |
|---|---|---|---|---|
| Critical routing and infrastructure protocols | Routing updates, neighbor messages, ARP, required keepalives | Trusted peers and required local services | Explicitly permit and police with a rate sized for convergence | Neighbor state, update counters, convergence behavior |
| Authorized management | SSH and approved monitoring access | Restricted administrative sources | Permit and rate-limit; combine with management ACLs and AAA | Successful sessions, class drops, login latency |
| CEF exceptions | TTL expiration and other punted packets | Variable; often externally generated | Apply a separate allowance when CPPr is available | Exception counters and CPU utilization |
| Unwanted or spoofed traffic | Forged protocol packets, malformed packets, unnecessary services | Untrusted | Drop or strictly police; reinforce with ACLs and anti-spoofing | Drop counters, source analysis, logs |
| Default traffic | Unclassified CPU-bound packets | Unknown | Use an intentional default policy after required classes are defined | Default-class rate and drops |
- Identify trusted routing peers and required management sources.
- Classify essential protocols before broad default behavior.
- Start with conservative limits that preserve legitimate operation.
- Deploy in stages, preferably during a maintenance window.
- Monitor counters, drops, CPU utilization, logs, management reachability, and routing-neighbor status.
- Document the policy, assumptions, thresholds, and rollback procedure.
- Revise the policy when protocols, management services, traffic patterns, or topology change.
Validation Commands
Review policy behavior together with device health and routing state. A low drop count does not prove that the policy is correct, and a high drop count is not automatically a problem if the traffic is unwanted.
show policy-map control-plane
show policy-map control-plane host
show policy-map control-plane transit
show policy-map control-plane cef-exception
show processes cpu sorted
show ip ospf neighbor
show ip ospf interface- Check packet and drop counters for each class.
- Compare CPU utilization before and after deployment.
- Confirm that routing adjacencies remain stable during normal traffic and convergence.
- Test that authorized administrators can still establish SSH sessions.
- Investigate unexpected sources, matches, or default-class activity.
Troubleshooting
Routing neighbors repeatedly reset after CoPP is enabled
- Likely causes: Routing packets were omitted, the rate or burst allowance is too low, or packets were classified unexpectedly.
- Diagnostic actions: Check policy drops, neighbor state, protocol logs, ACL matches, class-map matches, and peer addresses.
- Resolution: Add or correct the required routing class and size the limit from observed operational demand.
Legitimate SSH sessions are slow or fail
- Likely causes: The management rate is too low, the ACL is too broad, or the default class drops management packets.
- Diagnostic actions: Review SSH and default-class counters; confirm the destination address, TCP port, and expected sources; measure normal concurrent administration.
- Resolution: Refine classification and increase only the validated allowance while retaining source restrictions.
CPU remains high even though CoPP is configured
- Likely causes: The policy does not match the overload, the traffic is generated internally or uses another path, permitted rates are too generous, or an unnecessary service is exposed.
- Diagnostic actions: Inspect process CPU usage and control-plane counters; identify packet types and sources; review enabled management and routing services.
- Resolution: Correct classification, reduce exposure with complementary controls, and tune the appropriate class.
Routing authentication prevents adjacency formation
- Likely causes: Keys, key identifiers, authentication modes, interface settings, or key-chain timing do not match; authentication was configured on only one peer.
- Diagnostic actions: Compare both routers' interface and routing-protocol settings, review neighbor output and logs, and confirm the correct interfaces participate in the routing process.
- Resolution: Make authentication settings consistent across legitimate peers and verify adjacency recovery.
Exam-Relevant Notes
- The control plane maintains network operation; the data plane forwards ordinary traffic; the management plane supports administration.
- CoPP applies QoS policing to aggregate traffic reaching the control plane.
- MQC uses match criteria or ACLs, class maps, policy maps, and service-policy attachment.
- CPPr adds separate host, transit, and CEF-exception policy categories.
- Host traffic is addressed to the device, transit traffic is forwarded traffic needing CPU intervention, and CEF exceptions are packets punted from normal CEF processing.
- Routing authentication helps prevent unauthorized route advertisements, but it is not a rate limiter or complete denial-of-service defense.
- Always allow and size essential routing and infrastructure traffic before applying restrictive default handling.
Related Protection Areas
Control-plane protection works best as part of a broader architecture. Review data-plane protection, management-plane protection, AAA, and SSH on Cisco routers to cover the other major security domains.