Control Plane Policing (CoPP) protects the control plane and separates it from the data plane, which ensures network stability, reachability, and packet delivery.

This feature allows a policy map to be applied to the control plane. This policy map looks like a normal QoS policy and 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 NX-OS device 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 or CPU itself.

The supervisor module divides the traffic that it manages into three 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.

Management plane

Runs the components meant for Cisco NX-OS device management purposes such as the command-line interface (CLI) and Simple Network Management Protocol (SNMP).

The supervisor module has both the management plane and 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 NX-OS device. Another example is a DoS attack on the 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

• Unstable Layer 2 topology

• Slow or unresponsive interactive sessions with the CLI

• Processor resource exhaustion, such as the memory and buffers

• Indiscriminate drops of incoming packets

Caution

It is important to ensure that you protect the supervisor module from accidental or malicious attacks by configuring control plane protection.

CoPP has the following configuration guidelines and limitations:

• Support for uRPF exception CoPP class is introduced in Cisco NX-OS Release 8.2(6). By default all uRPF exception packets are punted to the supervisor module. A new CoPP class, copp-system-p-classurpf- exception is introduced to match uRPF exception packets and police them at 100 kbps. You can customize the default CoPP profiles and you can choose to drop uRPF exceptions or police at a lower rate.

• CoPP classification does not work for the Layer 2 control traffic in native VLAN in the following scenarios:

  • When the native vlan (ID other than 1) command is configured on the interface and the native VLAN ID is missing in the configuration.

  • If the vlan dot1q tag native exclude control command is configured.

• We recommend that you use the strict default CoPP policy initially and then later modify the CoPP policies based on the data center and application requirements.

• We recommend applying the default dense policy when the chassis is fully loaded with F2 or F2e Series modules or loaded with more F2 or F2e Series modules than any other type of I/O module.

• We recommend configuring the scale factor and applying the default dense policy when the chassis is loaded with both F2 or F2e and M Series modules.

• 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.

• All the traffic that you do not specify in the other class maps is put into the last class, the default class. Monitor the drops in this class and investigate if these drops are based on traffic that you do not want or the result of a feature that was not configured and you need to add.

• All broadcast traffic is sent through CoPP logic in order to determine which packets (for example, ARP and DHCP) need to be redirected through an access control list (ACL) to the router processor. Broadcast traffic that does not need to be redirected is matched against the CoPP logic, and both conforming and violated packets are counted in the hardware but not sent to the CPU. Broadcast traffic that needs to be sent to the CPU and broadcast traffic that does not need to be sent to the CPU must be separated into different classes.

• When you configure a policer in a CoPP class map active policy with a valid CIR value, but both conform and violate action is set to drop the packets, the CIR value will be taken as 0. The configuration of conform drop violate drop action drops all the classified packets irrespective of the incoming rate.

  Thus, as expected all packets will be dropped and the CoPP statistics will display the conformed counter as "0 bytes" and will not be incremented. This is an expected behaviour.

• In a CoPP policy-map, make sure you set the class with police rate as bps (bytes per second) and not as pps (packets per second). The Control plane policy segregates different packets destined for the control plane into different classes. Using hardware policers, you can define separate actions for traffic that conforms to, exceeds, or violates certain conditions. The actions can transmit the packet, mark down the packet, or drop the packet.

  The police [cir] {cir-rate [bps | gbps | kbps | mbps | pps]} command allows you to configure the policer CIR unit in bps. But the Cisco Nexus 7000 hardware considers the byte-policing rather than the packet-policing. Therefore, you are suggested to use bps and not pps when you set the class with the police rate.

• If you remove the set cos configuration, there is a difference in behavior between M1 Series modules and F2/F2e Series modules with SVI and trunk ports. With an M1 Series module, when Layer 3 control packets with both DSCP and UserPriority (UP) (in the VLAN header) are received, queuing is performed using DSCP. With a F2/F2e Series module, queuing is performed using UP.

• After you have configured CoPP, delete anything that is not being used, such as old class maps and unused routing protocols.

• 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 NX-OS device and require a console connection.

• The Cisco NX-OS software does not support egress CoPP or silent mode. CoPP is supported only on ingress (you cannot use the service-policy output copp command to the control plane interface).

• You can use the access control entry (ACE) hit counters in the hardware only for ACL logic. Use the software ACE hit counters and the show access-lists and show policy-map type control-plane commands to evaluate CPU traffic.

• The Cisco NX-OS device hardware performs CoPP on a per-forwarding-engine basis. CoPP does not support distributed policing. Therefore, you should choose rates so that the aggregate traffic does not overwhelm the supervisor module.

• To get a more granular view of traffic that reaches the supervisor and might be dropped by CoPP, you can use the NetFlow feature on SVIs. To do so, compare the ACL hit counts by the values listed in the NetFlow table.

• When you use ISSU to upgrade to a new Cisco NX-OS release, the default CoPP policy for the new release is not applied. Because you might have your own configured CoPP policy and want to continue using it, the policy for the prior release continues to be applied. However, if you have not modified the default CoPP policy in prior versions, we recommend that when you install Cisco NX-OS Release 5.2 or later releases, you apply the latest default CoPP policy for that version by using the copp profile [strict | moderate | lenient ] command. This action removes the previous policy and applies the new one.

• Beginning with Cisco NX-OS Release 5.2, the default CoPP policies are read only. To make modifications, copy the default profile by using the copp copy profile {strict | moderate | lenient } {prefix | suffix } string, make modifications, and then apply that policy to the control plane using the service-policy input policy-map-name command.

• If multiple flows map to the same class, individual flow statistics will not be available.

• Support for monitoring CoPP with SNMP is limited to the listed cbQoSMIB tables and the elements attached to the control plane.

Note	If you are familiar with the Cisco IOS CLI, be aware that the Cisco NX-OS commands for this feature might differ from the Cisco IOS commands that you would use.

This table lists the default settings for CoPP parameters.

This section describes how to configure CoPP.

To display CoPP configuration information, perform one of the following tasks:

For detailed information about the fields in the output from these commands, see the Cisco Nexus 7000 Series NX-OS Security Command Reference.

This section includes example CoPP configurations.

This table lists the release history for this feature.