CCNA Security online course

Cisco Network Foundation Protection (NFP) Framework

Learn how Cisco Network Foundation Protection secures the management, control, and data planes of routers and switches with practical IOS examples.

Cisco Network Foundation Protection (NFP) is an infrastructure-security framework for preserving the availability, stability, and secure operation of routers and switches. It organizes protection according to the traffic and device processes being protected: the management plane, control plane, and data plane.

NFP is not one IOS command or one security feature. It is a way to classify risks, select appropriate controls, and build defense in depth around network infrastructure.

Why Network Foundation Protection Matters

A router or switch may continue forwarding traffic during an attack while administrators lose access to it, or it may remain reachable for management while routing information is being corrupted. These are different failures and require different controls.

NFP starts by asking three questions:

  • Who or what is communicating with the device for administration and monitoring?
  • Which protocols and processes allow the device to learn topology and forwarding information?
  • Which user and application packets are being forwarded through the device?

Answering these questions helps place a threat in the correct plane before selecting an ACL, authentication method, policing policy, or monitoring procedure.

The Three-Plane Model

The planes are logical categories, not necessarily separate physical interfaces or processors. A packet's classification depends on its destination and how the device processes it. A packet addressed to the router may require CPU processing, while a packet passing through the router may be handled by the forwarding path.

Plane: Management

Purpose: Administrative access, configuration, monitoring, logging, and operational services directed to the device.

Examples: SSH, console, auxiliary access, AAA, SNMP, NTP, syslog, and file transfers.

Failure impact: Administrators cannot administer, monitor, troubleshoot, or recover the device remotely.

Representative protections: SSH, AAA, privilege control, management ACLs, access-class restrictions, separate management networks or VRFs, and secure logging.

Plane: Control

Purpose: Building topology, neighbors, reachability, and forwarding knowledge.

Examples: ARP, routing updates and adjacencies, ICMP messages requiring device processing, first-hop redundancy, spanning tree, and other Layer 2 control protocols.

Failure impact: Lost routes, unstable topology, failed adjacencies, route churn, or missing forwarding entries.

Representative protections: Routing authentication, neighbor filtering, passive interfaces, infrastructure ACLs, Control Plane Policing, validation, and rate limiting.

Plane: Data

Purpose: Forwarding transit traffic for users, hosts, and applications.

Examples: A user's web request crossing a router or traffic moving between VLANs.

Failure impact: User traffic is dropped, delayed, misrouted, or permitted when it should be denied.

Representative protections: Interface ACLs, VLAN and port security, anti-spoofing filters, uRPF, QoS, storm control, and segmentation.

Traffic Classification Examples

Administrator connects with SSH — The destination is the network device and the purpose is administration. This is management-plane traffic.

OSPF neighbors exchange hello messages — The traffic helps establish and maintain routing topology. This is control-plane traffic.

A switch receives a spanning-tree BPDU — The frame participates in Layer 2 topology control. This is control-plane traffic.

A user's HTTPS request crosses a router — The router forwards the packet on behalf of the user. This is data-plane transit traffic.

An ICMP echo request is sent to a router interface — The device must process the packet as its destination. It can consume control-plane resources even though ICMP is also commonly used for diagnostics.

An ICMP packet passes through a router — If it is not addressed to the device and is eligible for forwarding, it is transit data-plane traffic.

A single flow can affect more than one plane. For example, a routing update is control-plane traffic, but a routing failure caused by that update can change how data-plane packets are forwarded. Likewise, management access may use the same physical link as user traffic while remaining a management-plane function.

Management Plane

Definition and Responsibilities

The management plane includes administrative access and monitoring traffic directed to a router or switch. It also includes operational services that support administration, such as authentication, authorization, logging, time synchronization, inventory, and file transfer.

  • Remote administration: SSH is the preferred remote terminal protocol because it encrypts the session. Telnet sends the terminal session without encryption and should generally be disabled.
  • Local administration: Console and auxiliary access provide recovery paths, but they still require physical or out-of-band protection and appropriate authentication.
  • AAA: Authentication verifies identity, authorization controls permitted actions and privilege, and accounting records administrative activity. See AAA explained.
  • Monitoring: SNMP, syslog, and operational commands provide visibility into device health and events. Prefer secure versions and protected destinations.
  • Time and files: NTP supports reliable event correlation, while secure file-transfer services support IOS images, configurations, and backups.

Management-Plane Risks

Exposed management services can allow credential theft, unauthorized configuration, privilege abuse, or information disclosure. A management-plane failure may not immediately stop forwarding, but it prevents administrators from monitoring conditions, troubleshooting faults, changing policy, or recovering the device remotely.

Management-Plane Protections

  • Use SSH version 2 and disable Telnet on VTY lines.
  • Use AAA with centralized RADIUS or TACACS+ where appropriate, with a controlled local fallback account.
  • Apply least privilege through roles, privilege levels, command authorization, and separate administrator accounts.
  • Restrict VTY access with an access class or management ACL that permits only approved administrator source networks.
  • Place management addresses on a dedicated management network or management VRF when the design supports it.
  • Protect credentials with encrypted or secret forms, strong authentication, login protections, and controlled console and auxiliary access.
  • Send logs to a protected, centralized collector and synchronize device clocks with authenticated or trusted NTP sources.
  • Minimize exposed services. Disable unused HTTP, insecure file-transfer, discovery, and legacy management services.

Example: Restricting Remote SSH Access

The following is a lab-oriented example. Replace the domain, account, key, and source subnet with values appropriate for the environment. It demonstrates management-plane hardening; it is not a complete centralized AAA deployment.

ip domain-name example.local
crypto key generate rsa modulus 2048
ip ssh version 2
ip access-list standard MGMT-SOURCES
 permit 192.0.2.0 0.0.0.255
line vty 0 4
 login local
 transport input ssh
 access-class MGMT-SOURCES in

Before applying a restrictive access class remotely, confirm that your current source address is permitted and that console or out-of-band recovery is available.

Control Plane

Definition and Responsibilities

The control plane contains device-originated or device-processed protocols and processes that establish topology, discover neighbors, learn reachability, and create forwarding knowledge.

  • ARP: Associates IPv4 addresses with Layer 2 addresses on a local network.
  • Routing protocols: OSPF, EIGRP, IS-IS, BGP, and other protocols exchange reachability information and maintain adjacencies.
  • Layer 2 control: Spanning tree and applicable discovery or redundancy protocols help devices build and maintain a stable topology.
  • First-hop redundancy: Protocols such as HSRP or VRRP coordinate default-gateway availability.
  • Device-processing traffic: Some ICMP messages and packets addressed to device interfaces require CPU attention rather than simple transit forwarding.

Control-Plane Risks and Consequences

Threats include spoofed routing peers, unauthorized routing advertisements, ARP manipulation, forged topology messages, malformed packets, and excessive traffic that exhausts CPU or memory. A control-plane failure can remove valid routes, cause route churn, destabilize Layer 2 topology, or prevent the device from installing usable forwarding entries.

CPU starvation occurs when excessive processing demand prevents essential control or management tasks from being handled promptly. Symptoms can include high CPU utilization, slow CLI response, missed protocol timers, and flapping routing adjacencies.

Control-Plane Protections

  • Enable routing-protocol authentication and verify that only intended neighbors can form adjacencies.
  • Use neighbor filters, infrastructure ACLs, and interface placement to restrict where control protocols are accepted.
  • Use passive interfaces where an interface should advertise a network but should not form a routing adjacency.
  • Apply protocol-specific validation and filtering for routing updates, ARP behavior, and Layer 2 control traffic.
  • Use Control Plane Policing (CoPP) to classify and rate-limit traffic handled by the control plane.
  • Establish safe rate limits based on normal traffic baselines. A policy that is too aggressive can block legitimate routing, monitoring, or management traffic.

Example: Basic CoPP Structure

Control Plane Policing (CoPP) is a Cisco IOS mechanism that classifies and rate-limits packets processed by the control plane. The following example illustrates structure only; production values require measurement and protocol-specific allowances.

class-map match-any CONTROL-PLANE-ICMP
 match protocol icmp
policy-map CONTROL-PLANE-POLICY
 class CONTROL-PLANE-ICMP
  police 32000 conform-action transmit exceed-action drop
control-plane
 service-policy input CONTROL-PLANE-POLICY

For a focused guide, see protecting the control plane.

Data Plane

Definition and Responsibilities

The data plane is the forwarding path for traffic traveling through a router or switch on behalf of users, hosts, and applications. Transit traffic passes through the device rather than being intended for the device itself.

Data-plane protection determines which transit packets may enter, leave, or cross a trust boundary. It is different from protecting packets addressed to the router's own interfaces or CPU.

Data-Plane Risks and Consequences

Threats include source-address spoofing, unauthorized access between segments, floods, malformed transit traffic, broadcast or multicast storms, and traffic that consumes forwarding, queue, link, or memory resources. Failures appear as dropped, delayed, misrouted, or unauthorized user traffic.

Data-Plane Protections

  • Apply interface ACLs in the correct direction and at an appropriate trust boundary.
  • Use VLAN segmentation and switch port-security controls to reduce unauthorized Layer 2 access.
  • Apply anti-spoofing filters and use unicast reverse-path forwarding (uRPF) where the routing design supports it.
  • Use QoS to protect critical traffic during congestion and storm control to limit broadcast, multicast, or unknown-unicast floods.
  • Separate users, servers, voice, guests, and management with segmentation and explicit policy.
  • Verify that data-plane ACLs do not unintentionally block device management, routing protocols, DNS, DHCP, or required diagnostic traffic.

Example: Filtering Spoofed User Traffic

This example denies packets using a private source range on an edge interface where that range should not appear. The address ranges and interface placement must match the organization's addressing plan.

ip access-list extended USER-EDGE-FILTER
 deny ip 10.0.0.0 0.255.255.255 any
 permit ip any any
interface GigabitEthernet0/1
 ip access-group USER-EDGE-FILTER in

Verify the ACL's direction, attachment point, deny counters, return path, and required application flows before relying on it.

See protecting the data plane for additional data-plane controls.

Plane Interdependence

The planes are logically distinct but operationally dependent.

  • A control-plane routing failure can remove forwarding entries. The data plane then cannot deliver affected user flows even though the interfaces may remain physically up.
  • A management-plane outage may leave forwarding operational, but administrators cannot investigate, update configuration, verify recovery, or respond remotely.
  • Data-plane congestion or a flood can consume CPU, memory, queues, link capacity, or buffers. That pressure can delay control protocols and management traffic.

Consider an interdependent outage: a forged or excessive routing exchange causes neighbors to drop. Routes disappear from the routing table, so data-plane traffic to remote networks fails. Administrators then use the management plane to inspect neighbor state, logs, CPU load, and policy counters before correcting and testing the configuration.

Applying NFP as Defense in Depth

  1. Map the asset and traffic. Identify whether the target is device administration, topology formation, or transit forwarding.
  2. Reduce exposure. Disable unused services, limit management sources, and avoid forming protocol adjacencies on untrusted interfaces.
  3. Authenticate trust relationships. Use AAA for administrators and authentication for routing or redundancy peers where supported.
  4. Enforce least privilege. Give users, administrators, protocols, and interfaces only the access they require.
  5. Layer controls. Combine segmentation, ACLs, protocol validation, CoPP, QoS, storm control, secure logging, and monitoring rather than depending on one feature.
  6. Measure normal behavior. Establish baselines for CPU, protocol rates, interface traffic, ACL hits, and control-plane counters.
  7. Test safely. Confirm that legitimate administrators, routing peers, monitoring systems, and user applications still work. Have a console or out-of-band recovery method before making restrictive changes.

Common Threats and Controls by Plane

Management plane — Threat: Telnet exposure or unauthorized login. Symptom: Credential disclosure or unexpected configuration changes. Control: SSH, AAA, access classes, privilege control. Validation: Test permitted and denied source networks and review login logs.

Control plane — Threat: Forged routing updates or excessive device-directed traffic. Symptom: Adjacency failures, route churn, high CPU, or missing routes. Control: Routing authentication, neighbor filtering, passive interfaces, and CoPP. Validation: Check neighbor state, routing tables, CPU, and policy counters.

Data plane — Threat: Spoofed or unauthorized transit traffic. Symptom: Application failure, unexpected access, drops, or congestion. Control: Interface ACLs, segmentation, uRPF, QoS, and storm control. Validation: Review ACL counters, flow records, interface statistics, and application tests.

Troubleshooting by Plane

Remote Administration Is Unavailable

This is primarily a management-plane problem. Verify that SSH is enabled, VTY lines permit SSH, and the management ACL or access class allows the administrator's source address. Confirm local or AAA account authentication and privilege permissions. Finally, validate reachability to the management address or management VRF. Use console or out-of-band access if the change removed remote access.

Remote Networks Become Unreachable

This is a control-plane issue with data-plane impact. Check routing-neighbor state and authentication compatibility, inspect the routing table and route installation, review interface status and passive-interface settings, and determine whether ACLs or CoPP are dropping routing traffic.

CPU Is High and Routing Adjacencies Flap

This suggests control-plane overload. Review CPU utilization and control-plane counters, identify traffic classes reaching the CPU, inspect CoPP counters and rate limits, and verify that legitimate routing, management, and monitoring traffic is not being policed excessively.

An ACL Breaks an Application

This is usually a data-plane issue. Verify the ACL's interface and direction, review deny counters and protocol or port matches, confirm return-path and stateful-policy requirements, and check dependencies such as DNS, DHCP, and diagnostic ICMP.

Exam-Relevant Notes

  • Management plane: Protects access to and operation of the device, such as SSH, AAA, SNMP, logging, and NTP.
  • Control plane: Builds topology and forwarding knowledge, such as routing protocols, ARP, spanning tree, and redundancy protocols.
  • Data plane: Forwards user and application traffic through the device.
  • CoPP: Protects traffic handled by the control plane by classifying and rate-limiting it; it is not a replacement for transit ACLs.
  • Transit traffic: Passes through the device. Traffic addressed to the device itself may require control-plane processing instead.
  • Availability: NFP emphasizes keeping infrastructure usable during normal operation and attacks, while also supporting secure administration and correct forwarding.

For deeper practice, continue with management-plane protection, control-plane protection, and data-plane protection. Related skills include enabling SSH, configuring NTP, and using AAA with Cisco routers.