VMware ESXi and vSphere Cluster Management

Protecting the Network Control Plane

Learn how Cisco IOS control-plane traffic works and how CoPP, CPPr, and routing-protocol authentication protect routers from CPU exhaustion and routing attacks.

The network control plane is the collection of device-to-device traffic and processing used to discover neighbors, build routing information, maintain reachability, and preserve operational state. Protecting it keeps a router able to make forwarding decisions even when it receives scans, floods, malformed packets, or unauthorized routing messages.

This lesson covers the control plane, its relationship to the data and management planes, Cisco Control Plane Policing (CoPP), Cisco Control Plane Protection (CPPr), routing-protocol authentication, and operational validation.

Control-plane fundamentals

A network device performs several different jobs. The control plane establishes topology knowledge, routing information, protocol state, and reachability. It exchanges information with other devices and processes packets that require the router's CPU.

The data plane forwards ordinary user packets through the device. On Cisco platforms, Cisco Express Forwarding (CEF) normally allows many packets to be forwarded using hardware or optimized forwarding structures without requiring full CPU processing for every packet.

The management plane provides administrative access and operational services. Examples include SSH, device monitoring, configuration access, and management protocols directed at the router itself.

Plane | Primary purpose | Representative traffic or functions | Primary security concern

Control plane | Builds topology and routing state | OSPF, EIGRP, BGP, ARP, keepalives, ICMP control messages | CPU exhaustion and unauthorized routing participation

Data plane | Moves ordinary transit traffic | CEF-forwarded IP packets | Forwarding disruption, filtering failure, or resource exhaustion

Management plane | Configures and monitors the device | SSH, management sessions, monitoring requests | Unauthorized access and management-service abuse

CPU-bound traffic

CPU-bound traffic is traffic that must be examined or handled by the device processor rather than being forwarded solely through the normal hardware path. Routing-protocol packets are an obvious example because the router must interpret their contents and update protocol state.

Other packets may be sent to the CPU because they are addressed to the router, require special processing, or cannot follow the normal CEF path. This does not mean every packet is processed identically. It means that some traffic competes for a finite CPU resource instead of remaining entirely in the fast forwarding path.

What happens when the control plane is overloaded?

  • Routing protocols may become unstable or fail to process updates on time.
  • Neighbor relationships may reset or fail to form.
  • Previously learned routes may expire or disappear.
  • New reachability information may not be installed.
  • SSH and other management access may become slow or unavailable.
  • The device may become generally unresponsive.
  • Data-plane forwarding can eventually suffer if the device cannot maintain the state needed to forward traffic.

Control-plane traffic and its attack surface

Common control-plane traffic includes routing-protocol packets, ARP messages, protocol keepalives, ICMP control messages, and packets requiring special handling. Management traffic such as SSH is also commonly addressed to the device and therefore requires CPU attention.

An attacker does not necessarily need to compromise the router to affect its control plane. A large number of packets addressed to a router interface can consume CPU time while the device examines, classifies, logs, or responds to them. A scan or connection flood against an SSH address is one example.

Routing protocols create a second important risk. On a shared or untrusted segment, an unauthorized device may attempt to form a routing adjacency. If accepted, it could advertise incorrect prefixes, manipulate path selection, or inject a route that redirects traffic. Routing authentication helps establish that updates came from an approved peer, but it should be combined with route filtering and appropriate interface trust boundaries.

Control Plane Policing (CoPP)

Control Plane Policing (CoPP) is a Cisco IOS mechanism that applies a policy to traffic sent toward the device CPU through the control-plane interface. A policy classifies traffic and then applies policing or another supported action to each class.

Policing enforces a traffic rate. Traffic within the configured rate is conforming traffic and may be transmitted to the CPU. Traffic above the threshold is exceeded traffic and can be dropped before it consumes additional CPU processing. A rate limit is the configured packet or bit threshold; a burst value allows for short, controlled variations in traffic.

Why use CoPP?

CoPP preserves CPU availability for essential operations during scans, floods, and denial-of-service attempts. A design can give trusted and essential traffic an explicit allowance while applying tighter limits to unnecessary or lower-priority traffic.

For example, an administrator might classify SSH packets destined to a router's management address and permit a conservative rate. Excess connection attempts can then be discarded before they consume the CPU needed for routing and neighbor maintenance.

CoPP design process

  1. Inventory CPU-bound traffic. Identify routing protocols, ARP, keepalives, ICMP control traffic, management services, and known exception traffic.
  2. Classify the traffic. Use extended ACLs and class maps to distinguish essential routing, authorized management, infrastructure services, and unwanted or low-priority traffic.
  3. Establish safe baselines. Measure normal packet rates, convergence bursts, management activity, and platform capacity.
  4. Choose policing rates. Set rates and burst values high enough for legitimate operation but low enough to limit abnormal load.
  5. Apply the service policy. Attach the policy under the control-plane configuration context.
  6. Monitor the result. Review counters, CPU utilization, routing state, logs, and management access.
  7. Adjust carefully. Tune classifications and thresholds using measured behavior rather than arbitrary values.

An overly restrictive policy can be harmful. It may drop legitimate routing updates, SSH packets, ARP messages, or neighbor keepalives. Always define required traffic before applying a restrictive default class, and test during a maintenance window.

Conceptual CoPP configuration

The following is a platform-dependent template. Replace placeholders and verify the exact syntax for the IOS release and hardware.

ip access-list extended <management-traffic-acl>
 permit tcp <approved-source-or-any> host <device-address> eq 22
class-map match-any <management-class>
 match access-group name <management-traffic-acl>
policy-map <control-plane-policy>
 class <management-class>
  police <rate> <burst> conform-action transmit exceed-action drop
 class class-default
  police <default-rate> <burst> conform-action transmit exceed-action drop
control-plane
 service-policy input <control-plane-policy>

Classify required routing and management traffic before relying on a restrictive class-default. Exact policing actions, syntax, and supported features vary by IOS release and platform.

Cisco Control Plane Protection (CPPr)

Cisco Control Plane Protection (CPPr) extends CoPP by providing more detailed handling of traffic that requires CPU attention. Instead of treating all control-plane traffic as one broad group, CPPr can subdivide it into virtual control-plane categories.

The aggregate control-plane interface represents traffic directed toward the device's processing resources. Where supported, CPPr provides separate host, transit, and CEF-exception configuration contexts.

Category | Traffic direction or condition | Examples | Protection goal

Host | Traffic addressed to a physical or logical address of the router and requiring CPU processing | SSH, routing protocols, ARP, and control traffic addressed to the device | Protect services and protocols that terminate on the router

Transit | Through traffic that would normally be forwarded but requires CPU intervention before forwarding | Packets containing IP options | Limit exceptional transit processing without broadly restricting host traffic

CEF-exception | Packets punted because they are exceptions to normal CEF handling | Keepalives and packets affected by TTL expiration behavior | Isolate forwarding exceptions from ordinary host-bound traffic

IP options are optional IPv4 header fields that may require special processing outside the normal fast-forwarding path. TTL, or Time To Live, is an IP field decremented at every hop. Packets associated with TTL expiry processing can also require exceptional handling.

Separate classification matters because host traffic, exceptional transit traffic, and CEF exceptions have different operational requirements. A single broad policy can hide which traffic is consuming CPU and may accidentally apply a management threshold to a forwarding-exception category.

Conceptual CPPr attachment structure

control-plane host
 service-policy input <host-policy>
control-plane transit
 service-policy input <transit-policy>
control-plane cef-exception
 service-policy input <exception-policy>

CPPr availability and syntax are platform- and software-dependent. Build separate policies that reflect the traffic expected in each category, then validate category-specific counters after deployment.

Feature | Scope | Classification model | Typical use | Key benefit

CoPP | Aggregate traffic sent to the control plane | User-defined classes, commonly ACL and class-map matches | Protect routing, management, and other CPU-bound traffic | Broad, centralized CPU protection

CPPr | More detailed control-plane processing categories | Host, transit, and CEF-exception categories plus policy classes | Isolate management and routing from exceptional transit processing | More precise protection and troubleshooting

Routing-protocol authentication

Routing updates should be authenticated on shared or untrusted segments. Authentication helps prevent a rogue router from establishing a trusted adjacency or injecting false routing information.

A rogue router is an unauthorized device attempting to participate in routing or advertise malicious or incorrect routes. Without authentication, a device that can send plausible protocol packets may be able to influence neighbor state or route selection, depending on the protocol and network design.

Authenticated neighbors must use compatible settings and shared secret material before updates are accepted. Depending on the routing protocol and IOS version, authentication may use plaintext methods or cryptographic methods, key identifiers, and key chains. Prefer supported cryptographic authentication over legacy clear-text mechanisms.

Conceptual authentication structure

key chain <routing-key-chain>
 key <key-id>
  key-string <secret>
interface <routing-interface>
 <routing-protocol-authentication-command>
 <routing-protocol-key-chain-command> <routing-key-chain>

Use the exact authentication commands for the selected routing protocol and IOS version. The authentication method, key ID where applicable, secret, key-chain reference, and interface or protocol attachment must be consistent on intended neighbors. Do not place real shared secrets in examples, documentation, or configuration repositories.

Authentication supplements, rather than replaces, routing-policy controls. Also use interface trust boundaries, route filtering, prefix filtering, and appropriate protocol configuration to limit which peers and routes are acceptable.

Protecting routing updates on a shared LAN

  1. Configure the same supported authentication method on both legitimate neighbors.
  2. Use matching key identifiers and secret material where the protocol requires them.
  3. Enable authentication on every intended routing endpoint, not only one side.
  4. Confirm that the correct interface participates in the routing process.
  5. Verify that the adjacency forms and that expected routes are exchanged.
  6. Test that a device without the correct authentication settings cannot establish or maintain the trusted relationship.

Threats and defenses

Threat | Likely effect | Primary mitigation | Validation method

SSH flood against a router address | CPU exhaustion and intermittent administration | Host-bound CoPP class with a conservative SSH rate and approved source restrictions | Review management-class drops and CPU utilization

Unauthorized routing peer | False routes or unstable adjacency | Routing authentication, interface trust boundaries, and route filtering | Check neighbor state, logs, and route exchange

Packets with IP options | CPU load from exceptional transit processing | CPPr transit classification and an appropriate policer | Review transit counters and forwarding behavior

CEF-exception flood | CPU exhaustion from punted packets | CPPr CEF-exception policy and platform-specific controls | Review exception counters and CPU processes

Overly restrictive policy | Legitimate routing or management traffic is dropped | Baseline-driven rates, explicit essential classes, and staged rollout | Correlate policy drops with protocol and access failures

Operational validation and maintenance

Security controls are effective only when their attachment and behavior are verified. After enabling a policy or authentication, validate both the security feature and the network functions it protects.

Useful verification commands

show policy-map control-plane
show policy-map interface control-plane
show processes cpu
show ip route
show ip ospf neighbor
show ip eigrp neighbors

Use protocol-specific neighbor commands appropriate to the deployed routing protocol. Command names and output vary among Cisco platforms and IOS releases.

  • Confirm that the control-plane policy is attached to the intended control-plane context.
  • Check policy counters for matches, conforming traffic, and drops.
  • Monitor CPU utilization before and after deployment.
  • Check protocol logs, neighbor state, route learning, and route stability.
  • Test SSH and other authorized management paths.
  • Inspect interface behavior and relevant platform-specific control-plane statistics.

Use a staged rollout. Test in a lab or limited production segment first, then deploy during a maintenance window with console or out-of-band access available. Document exceptions and revisit rates when routing design, management methods, platform capacity, or normal traffic patterns change.

Troubleshooting control-plane protection

SSH or management access becomes intermittent

Likely causes include an excessively low management policer, an ACL that does not match authorized sources, or a restrictive default class dropping traffic omitted from explicit classes.

  1. Review drops in the management class and class-default.
  2. Confirm the destination address, protocol, port, and source matching logic.
  3. Compare normal management bursts with the configured rate and burst values.
  4. Correct the classification or cautiously increase the rate or burst allowance.
  5. Retest from approved management hosts.

Routing neighbors fail after authentication is enabled

Check for a mismatched authentication method, key-chain name, key ID, secret, interface attachment, or one-sided configuration. Review protocol logs and neighbor status. Compare endpoint configuration without exposing secret values, then align parameters and verify adjacency restoration and route exchange.

CPU remains high during a packet flood

The traffic may not match the expected class, required CPU-bound traffic may be omitted, the policy may not be attached, or the platform may not support the assumed behavior. Verify attachment and per-class counters, inspect traffic characteristics, review CPU processes, and check platform-specific control-plane statistics. Correct classification and tune the policer using measured traffic. Where supported, use CPPr to isolate host, transit, and exception traffic.

Legitimate traffic is dropped after CPPr configuration

Examine counters for each CPPr category. Determine whether the traffic was placed in the wrong host, transit, or CEF-exception policy. Correlate drops with routing events, keepalive failures, and TTL-related traffic. Adjust the category policy or threshold while retaining limits on abnormal volumes and allowing for convergence bursts.

Practical deployment checklist

Requirement | Why it matters | What must match between neighbors | Verification

Inventory CPU-bound traffic | Prevents required protocols from being omitted | Not normally a neighbor-matching item | Baseline captures, logs, and platform documentation

Classify essential management and routing traffic | Allows critical traffic to remain available | Protocol and interface design must be understood on both endpoints | Policy match counters and successful access

Set measured rates and bursts | Avoids both CPU overload and accidental disruption | Traffic expectations should be compatible across the design | Conform and drop counters during normal and peak events

Attach CoPP or CPPr policies | An unattached policy provides no protection | Platform and IOS support must be confirmed | Control-plane policy display commands

Enable routing authentication | Rejects unauthorized routing participation | Method, key ID, secret, key chain, and attachment as applicable | Neighbor state, logs, and route exchange

Stage and monitor deployment | Reduces production outage risk | Maintenance and rollback procedures should be agreed | CPU, interfaces, protocol logs, and policy counters

Document exceptions and retune | Network behavior changes over time | Updated routing and management requirements | Periodic review and change records

For related study, review control-plane protection concepts and configuration practices together with management-plane security, data-plane defenses, route filtering, and infrastructure monitoring.