About Control Plane Policing
Control plane policing (CoPP) protects the control plane, which ensures network stability, reachability, and packet delivery.
This feature allows specification of parameters, for each protocol that can reach the control processor to be rate-limited using a policer. The policing is applied to all traffic destined to any of the IP addresses of the router or Layer 3 switch. A common attack vector for network devices is the denial-of-service (DoS) attack, where excessive traffic is directed at the device interfaces.
The Cisco Application Centric Infrastructure (ACI) leaf and spine switch NX-OS provides CoPP to prevent DoS attacks from impacting performance. Such attacks, which can be perpetrated either inadvertently or maliciously, typically involve high rates of traffic destined to the supervisor module of a Cisco ACI leaf and spine switch CPU or the CPU itself.
The supervisor module of Cisco ACI leaf and spine switch switches divides the traffic that it manages into two functional components or planes:
-
Data plane: Handles all the data traffic. The basic functionality of a Cisco NX-OS device is to forward packets from one interface to another. The packets that are not meant for the switch itself are called the transit packets. These packets are handled by the data plane.
-
Control plane: Handles all routing protocol control traffic. These protocols, such as the Border Gateway Protocol (BGP) and the Open Shortest Path First (OSPF) Protocol, send control packets between devices. These packets are destined to router addresses and are called control plane packets.
The Cisco ACI leaf and spine switch supervisor module has a control plane and is critical to the operation of the network. Any disruption or attacks to the supervisor module will result in serious network outages. For example, excessive traffic to the supervisor module could overload and slow down the performance of the entire Cisco ACI fabric. Another example is a DoS attack on the Cisco ACI leaf and spine switch supervisor module that could generate IP traffic streams to the control plane at a very high rate, forcing the control plane to spend a large amount of time in handling these packets and preventing the control plane from processing genuine traffic.
Examples of DoS attacks are as follows:
-
Internet Control Message Protocol (ICMP) echo requests
-
IP fragments
-
TCP SYN flooding
These attacks can impact the device performance and have the following negative effects:
-
Reduced service quality (such as poor voice, video, or critical applications traffic)
-
High route processor or switch processor CPU utilization
-
Route flaps due to loss of routing protocol updates or keepalives
-
Processor resource exhaustion, such as the memory and buffers
-
Indiscriminate drops of incoming packets
Note |
Cisco ACI leaf and spine switches are by default protected by CoPP with default settings. This feature allows for tuning the parameters on a group of nodes based on customer needs. |
Control Plane Protection
To protect the control plane, the Cisco NX-OS running on Cisco ACI leaf and spine switches segregates different packets destined for the control plane into different classes. Once these classes are identified, the Cisco NX-OS device polices the packets, which ensures that the supervisor module is not overwhelmed.
Control Plane Packet Types:
Different types of packets can reach the control plane:
-
Receive Packets: Packets that have the destination address of a router. The destination address can be a Layer 2 address (such as a router MAC address) or a Layer 3 address (such as the IP address of a router interface). These packets include router updates and keepalive messages. Multicast packets can also be in this category where packets are sent to multicast addresses that are used by a router.
-
Exception Packets: Packets that need special handling by the supervisor module. For example, if a destination address is not present in the Forwarding Information Base (FIB) and results in a miss, the supervisor module sends an ICMP unreachable packet back to the sender. IP packet with IP options are dropped by the supervisor.
-
Redirect Packets: Packets that are redirected to the supervisor module. Features such as Dynamic Host Configuration Protocol (DHCP) snooping or dynamic Address Resolution Protocol (ARP) inspection redirect some packets to the supervisor module.
-
Glean Packets: If a Layer 2 MAC address for a destination IP address is not present in the FIB, the supervisor module receives the packet and sends an ARP request to the host.
All of these different packets could be maliciously used to attack the control plane and overwhelm the Cisco ACI fabric. CoPP classifies these packets to different classes and provides a mechanism to individually control the rate at which the Cisco ACI leaf and spine switch supervisor module receives these packets.
Classification for CoPP:
For effective protection, the Cisco ACI leaf and spine switch NX-OS classifies the packets that reach the supervisor modules to allow you to apply different rate controlling policies based on the type of the packet. For example, you might want to be less strict with a protocol packet such as Hello messages, but more strict with a packet that is sent to the supervisor module because the IP option is set.
Available Protocols:
-
ACLLOG
-
ARP
-
BGP
-
CDP
-
COOP
-
DHCP
-
EIGRP
-
ICMP
-
IGMP
-
ISIS
-
LACP
-
LLDP
-
MCP
-
ND
-
OSPF
-
PERMIT LOG
-
PIM
-
STP
-
TRACEROUTE
-
Infra ARP
-
IFC Other
-
IFC SPAN
-
IFC
-
Glean
-
Tor-Glean
For each protocol, you can specify the rate and burst in packets per second (PPS). For more information about the rate and burst, see Rate Controlling Mechanisms.
Rate Controlling Mechanisms:
Once the packets are classified, the Cisco ACI leaf and spine switch NX-OS has different mechanisms to control the rate at which packets arrive at the supervisor module.
You can configure the following parameters for policing:
-
Committed information rate (CIR): Desired bandwidth, specified in packets per second (PPS).
-
Committed burst (BC): Size of a traffic burst that can exceed the CIR within a given unit of time and not impact scheduling, specified in the number of packets.
Default Policing Policies:
When a Cisco ACI leaf and spine switch are initially booted up, the pre-defined CoPP parameters for different protocols are based on tests done by Cisco.
Guidelines and Limitations for CoPP
CoPP has the following configuration guidelines and limitations:
-
We recommend that you use the default CoPP policy initially and then later modify the CoPP policies based on the data center and application requirements.
-
Customizing CoPP is an ongoing process. CoPP must be configured according to the protocols and features used in your specific environment as well as the supervisor features that are required by the server environment. As these protocols and features change, CoPP must be modified.
-
We recommend that you continuously monitor CoPP. If drops occur, determine if CoPP dropped traffic unintentionally or in response to a malfunction or attack. In either event, analyze the situation and evaluate the need to modify the CoPP policies.
-
You must ensure that the CoPP policy does not filter critical traffic such as routing protocols or interactive access to the device. Filtering this traffic could prevent remote access to the Cisco ACI Leaf/Spine and require a console connection.
-
Do not mis-configure CoPP pre-filter entries. CoPP pre-filter entries might impact connectivity to multi-pod configurations, remote leaf switches, and Cisco ACI Multi-Site deployments.
-
You can use the APIC UI to be able to tune the CoPP parameters.
-
Per interface per protocol is only supported on Leaf switches.
-
FEX ports are not supported on per interface per protocol.
-
For per interface per protocol the supported protocols are; ARP, ICMP, CDP, LLDP, LACP, BGP, STP, BFD, and OSPF.
-
The TCAM entry maximum for per interface per protocol is 256. Once the threshold is exceeded a fault will be raised.
Configuring CoPP Using the APIC GUI
Procedure
Step 1 |
On the menu bar, click . |
Step 2 |
In the Navigation pane, right-click and choose Create CoPP Leaf Level Policy. |
Step 3 |
In the Create CoPP Leaf Level Policy dialog, perform the following substeps: |
Step 4 |
In the Navigation pane, right-click and choose Create Access Switch Policy Group. |
Step 5 |
In the Create Access Switch Policy Group dialog, perform the following substeps:
|
Step 6 |
In the Navigation pane, right-click and choose Create Leaf Profile. |
Step 7 |
In the Create Leaf Profile dialog, perform the following substeps:
|
Configuring CoPP Using the Cisco NX-OS CLI
Procedure
Step 1 |
Configure a CoPP leaf profile: Example:
|
Step 2 |
Configure a CoPP Spine profile: Example:
|
Configuring CoPP Using the REST API
Procedure
Step 1 |
Configure a CoPP leaf profile: Example:
|
Step 2 |
Configure a CoPP spine profile: Example:
|
Viewing CoPP Statistics Using the GUI
Fine tuning CoPP requires knowing the number of packets dropped/allowed by a given protocol on a given node. The information can be viewed in the GUI using the procedure below:
Procedure
On the menu bar, click , select from the list of classes to configure the statistics display format.You can collect statistics about the number of packets allowed or dropped by CoPP. |
Configuring Per Interface Per Protocol CoPP Policy Using the APIC GUI
Procedure
Step 1 |
On the menu bar, click . |
Step 2 |
In the Navigation pane, expand , right click Create Per Interface Per Protocol CoPP Policy dialog box to perform the following actions in the Create Per Interface Per Protocol CoPP Policy dialog box:
|
Step 3 |
In the Navigation pane, expand , right click Create Leaf Access Port Policy Group dialog box to perform the following actions in the Create Leaf Access Port Policy Group dialog box:
|
Step 4 |
In the Navigation pane, expand , right click Create Leaf Interface Profile dialog box to perform the following actions in the Create Leaf Interface Profile dialog box:
|
Configuring Per Interface Per Protocol CoPP Policy Using the NX-OS Style CLI
Procedure
Step 1 |
Define the CoPP class map and policy map: Example:
|
Step 2 |
Applying the configuration to an interface on the leaf: Example:
|
Configuring CoPP Per Interface Per Protocol Using REST API
Procedure
Configure a CoPP per interface per protocol: Example:
|