Configuring Control Plane Policing

This chapter contains the following sections:

About CoPP

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 entering the switch from a non-management port. 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. For example, a DoS attack on the supervisor module 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 include:

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

Control Plane Protection

To protect the control plane, the Cisco NX-OS device 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.

Guidelines and Limitations for CoPP

CoPP has the following configuration guidelines and limitations:

  • Before you upgrade to Release 9.3(7), set the scale factor to 1 using the scale-factor 1 module multiple-module-range command.

  • For CIR lower than 7812 pps, the policer works in steps of 122 pps. For CIR greater than 7812 pps, you can expect a 1.6% deviation in the configured CIR.

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

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

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

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

  • Skip CoPP policy option has been removed from the Cisco NX-OS initial setup utility because using it can impact the control plane of the network.

  • Custom CoPP with user defined class-map is not supported.

  • The copp-system-class-fcoe class is not supported for Cisco Nexus 3400-S Series switches.

  • The following guidelines and limitations apply to static CoPP ACLs:

    • Only Cisco Nexus 3400-S Series switches use static CoPP ACLs.

    • Access control entries (ACEs) cannot be modified or removed for static CoPP ACLs.

    • If a CoPP ACL has a static ACL substring, it will be mapped to that type of traffic. For example, if the ACL includes the acl-mac-stp substring, STP traffic will be classified to the class map for that ACL.

    • You must have static CoPP ACLs in the CoPP policy. Otherwise, the CoPP policy will be rejected.


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.

Default Settings for CoPP

This table lists the default settings for CoPP parameters.

Table 1. Default CoPP Parameters Settings

Parameters

Default

Default policy

Strict

Default policy

9 policy entries

Note 

The maximum number of supported policies with associated class maps is 128.

Scale factor value

1.00

Configuring CoPP

This section describes how to configure CoPP.

Configuring a Control Plane Policy Map

You must configure a policy map for CoPP, which includes policing parameters. If you do not configure a policer for a class, the default is configured. Configuration changes are permitted only to those control plane policy maps that are a copy of one of the CoPP best practice policy profiles. For more information, see Copying the CoPP Best Practice Policy.

Before you begin

Ensure that you have configured a control plane class map.

Procedure

  Command or Action Purpose
Step 1

configure terminal

Example:

switch# configure terminal
switch(config)#

Enters global configuration mode.

Step 2

policy-map type control-plane policy-map-name

Example:

switch(config)# policy-map type control-plane ClassMapA
switch(config-pmap)#

Specifies a control plane policy map and enters policy map configuration mode. The policy map name can have a maximum of 64 characters and is case sensitive.

Step 3

class {class-map-name [insert-before class-map-name2] | class-default}

Example:

switch(config-pmap)# class ClassMapA
switch(config-pmap-c)#

Specifies a control plane class map name or the class default and enters control plane class configuration mode.

The class-default class map is always at the end of the class map list for a policy map.

Step 4

Enter one of the following commands:

  • police [cir] {cir-rate [rate-type]}
  • police [cir] {cir-rate [rate-type]} [bc] burst-size [burst-size-type]
  • police [cir] {cir-rate [rate-type]]} conform transmit [violate drop]

Example:

switch(config-pmap-c)# police cir 52000 bc 1000 packets

Specifies the committed information rate (CIR). The rate range is 25 to 60000000 (60 Million) pps..

The committed burst (BC) range is 1:1073741 packets.

The conform transmit action transmits the packet.

Note 
You can specify the BC and conform action for the same CIR.
Step 5

(Optional) set cos cos-value

Example:

switch(config-pmap-c)# set cos 1
 (Optional)

Specifies the 802.1Q class of service (CoS) value. The range is from 0 to 7. The default value is 0.

Step 6

exit

Example:

switch(config-pmap-c)# exit
switch(config-pmap)#

Exits policy map class configuration mode.

Step 7

exit

Example:

switch(config-pmap)# exit
switch(config)#

Exits policy map configuration mode.

Step 8

(Optional) show policy-map type control-plane [expand] [name class-map-name]

Example:

switch(config)# show policy-map type control-plane
 (Optional)

Displays the control plane policy map configuration.

Step 9

(Optional) copy running-config startup-config

Example:

switch(config)# copy running-config startup-config
 (Optional)

Copies the running configuration to the startup configuration.

Configuring the Control Plane Service Policy

You can configure one or more policy maps for the CoPP service policy.

Before you begin

Ensure that you have configured a control plane policy map.

Procedure

  Command or Action Purpose
Step 1

configure terminal

Example:

switch# configure terminal
switch(config)#

Enters global configuration mode.

Step 2

control-plane

Example:

switch(config)# control-plane
switch(config-cp)#

Enters control plane configuration mode.

Step 3

[no] service-policy input policy-map-name

Example:

switch(config-cp)# service-policy input PolicyMapA

Specifies a policy map for the input traffic. Repeat this step if you have more than one policy map.

You cannot disable CoPP. If you enter the no form of this command, packets are rate limited at 125 packets per seconds.

Step 4

exit

Example:

switch(config-cp)# exit
switch(config)#

Exits control plane configuration mode.

Step 5

(Optional) show running-config copp [all]

Example:

switch(config)# show running-config copp
 (Optional)

Displays the CoPP configuration.

Step 6

(Optional) copy running-config startup-config

Example:

switch(config)# copy running-config startup-config
 (Optional)

Copies the running configuration to the startup configuration.

Configuring the CoPP Scale Factor Per Line Card

You can configure the CoPP scale factor per line card.

The scale factor configuration is used to scale the policer rate of the applied CoPP policy for a particular line card. The accepted value is from 0.10 to 2.00. You can increase or reduce the policer rate for a particular line card without changing the current CoPP policy. The changes are effective immediately, so you do not need to reapply the CoPP policy.

Procedure

  Command or Action Purpose
Step 1

configure terminal

Example:

switch# configure terminal
switch(config)#

Enters global configuration mode.

Step 2

control-plane

Example:

switch(config)# control-plane
switch(config-cp)#

Enters control plane configuration mode.

Step 3

scale-factor value module multiple-module-range

Example:

switch(config-cp)# scale-factor 1.10 module 1-2

Configures the policer rate per line card. The allowed scale factor value is from 0.10 to 2.00. When the scale factor value is configured, the policing values are multiplied by the corresponding scale factor value of the module, and it is programmed in the particular module.

To revert to the default scale factor value of 1.00, use the no scale-factor value module multiple-module-range command, or explicitly set the default scale factor value to 1.00 using the scale-factor 1 module multiple-module-range command.

Step 4

(Optional) show policy-map interface control-plane

Example:

switch(config-cp)# show policy-map interface control-plane
 (Optional)

Displays the applied scale factor values when a CoPP policy is applied.

Step 5

(Optional) copy running-config startup-config

Example:

switch(config)# copy running-config startup-config
 (Optional)

Copies the running configuration to the startup configuration.

Changing or Reapplying the Default CoPP Policy

You can change to a different default CoPP policy, or you can reapply the same default CoPP policy.

Procedure

  Command or Action Purpose
Step 1

[no] copp profile [strict | moderate | lenient | dense]

Example:

switch(config)# copp profile moderate

Applies the CoPP best practice policy.

You cannot disable CoPP. If you enter the no form of this command, packets are rate limited at 125 packets per seconds.

Step 2

(Optional) show copp status

Example:

switch(config)# show copp status
 (Optional)

Displays the CoPP status, including the last configuration operation and its status. This command also enables you to verify that the CoPP best practice policy is attached to the control plane.

Step 3

(Optional) show running-config copp

Example:

switch(config)# show running-config copp
 (Optional)

Displays the CoPP configuration in the running configuration.

Copying the CoPP Best Practice Policy

The CoPP best practice policy is read-only. If you want to modify its configuration, you must copy it.

Procedure

  Command or Action Purpose
Step 1

copp copy profile {strict | moderate | lenient | dense} {prefix | suffix} string

Example:

switch# copp copy profile strict prefix abc

Creates a copy of the CoPP best practice policy.

CoPP renames all class maps and policy maps with the specified prefix or suffix.

Step 2

(Optional) show copp status

Example:

switch# show copp status
 (Optional)

Displays the CoPP status, including the last configuration operation and its status. This command also enables you to verify that the copied policy is not attached to the control plane.

Step 3

(Optional) show running-config copp

Example:

switch# show running-config copp
 (Optional)

Displays the CoPP configuration in the running configuration, including the copied policy configuration.

Verifying the CoPP Configuration

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

Command

Purpose

show policy-map type control-plane [expand] [name policy-map-name]

Displays the control plane policy map with associated class maps and CIR and BC values.

show policy-map interface control-plane

Displays the policy values with associated class maps and drops per policy or class map. It also displays the scale factor values when a CoPP policy is applied. When the scale factor value is the default (1.00), it is not displayed.
Note 
The scale factor changes the CIR and BC values internally on each module, but the display shows the configured CIR and BC values only. The actual applied value on a module is the scale factor multiplied by the configured value.

show class-map type control-plane [class-map-name]

Displays the control plane class map configuration, including the ACLs that are bound to this class map.

show copp diff profile {strict | moderate | lenient | dense} [prior-ver] profile {strict | moderate | lenient | dense} show copp diff profile

Displays the difference between two CoPP best practice policies.

When you do not include the prior-ver option, this command displays the difference between two currently applied default CoPP best practice policies (such as the currently applied strict and currently applied moderate policies).

When you include the prior-ver option, this command displays the difference between a currently applied default CoPP best practice policy and a previously applied default CoPP best practice policy (such as the currently applied strict and the previously applied lenient policies).

show copp profile {strict | moderate | lenient | dense}

Displays the details of the CoPP best practice policy, along with the classes and policer values.

show running-config aclmgr [all]

Displays the user-configured access control lists (ACLs) in the running configuration. The all option displays both the default (CoPP-configured) and user-configured ACLs in the running configuration.

show running-config copp [all]

Displays the CoPP configuration in the running configuration.

show startup-config aclmgr [all]

Displays the user-configured access control lists (ACLs) in the startup configuration. The all option displays both the default (CoPP-configured) and user-configured ACLs in the startup configuration.

Displaying the CoPP Configuration Status

Procedure

Command or Action Purpose

switch# show copp status

Displays the configuration status for the CoPP feature.

Example

This example shows how to display the CoPP configuration status: 

switch# show copp status

Monitoring CoPP

Procedure

Command or Action Purpose

switch# show policy-map interface control-plane

Displays packet-level statistics for all classes that are part of the applied CoPP policy.

Statistics are specified in terms of OutPackets (packets admitted to the control plane) and DropPackets (packets dropped because of rate limiting).

Example

This example shows how to monitor CoPP: 

switch# show policy-map interface control-plane
Control Plane
 
  Service-policy  input: copp-system-p-policy-strict
 
    class-map copp-system-p-class-critical (match-any)
      set cos 7
      police cir 19000 pps , bc 128 packets 
      module 4 :
        transmitted 373977 packets;
        dropped 0 packets;

Monitoring CoPP with SNMP

Beginning with Cisco Nexus Release 9.2(3), CoPP supports the Cisco class-based QoS MIB (cbQoSMIB). All CoPP elements can now be monitored (but not modified) using SNMP. This feature applies only to policies and their subelements (such as classes, match rules, and set actions) that are attached to the control plane. Elements of policies that are not in service on the control plane are not visible through SNMP.

The following cbQoSMIB tables are supported:

  • ccbQosServicePolicy

  • cbQosInterfacePolicy

  • cbQosObjects

  • cbQosPolicyMapCfg

  • cbQosClassMapCfg

  • cbQosMatchStmtCfg

  • cbQosPoliceCfg

  • cbQosSetCfg

Clearing the CoPP Statistics

Procedure

  Command or Action Purpose
Step 1

(Optional) switch# show policy-map interface control-plane

(Optional)

Displays the currently applied CoPP policy and per-class statistics.

Step 2

switch# clear copp statistics

Clears the CoPP statistics.

Example

This example shows how to clear the CoPP statistics for your installation: 

switch# show policy-map interface control-plane
switch# clear copp statistics

Configuration Examples for CoPP

This section includes example CoPP configurations.

Additional References for CoPP

This section provides additional information related to implementing CoPP.

Related Documents

Related Topic

Document Title

Licensing

Cisco NX-OS Licensing Guide

Standards

Standards

Title

RFC 2698

A Two Rate Three Color Marker