Cisco APIC Security Configuration Guide, Release 6.2(x)

Control plane policing

Updated: April 17, 2026

Want to summarize with AI?

Control plane policing (CoPP) protects switch control processors by classifying and rate-limiting traffic that is destined for the control plane.

CoPP protects network stability and reachability by preventing excessive protocol traffic from overwhelming the supervisor module.

Control and data planes

CoPP applies policers to traffic destined for the IP addresses of a router or Layer 3 switch. You can configure rate limits for each protocol that can reach the control processor.

The leaf and spine switch NX-OS software in Cisco Application Centric Infrastructure ( ACI ) uses CoPP to prevent denial-of-service (DoS) attacks from affecting switch performance. These attacks can be intentional or unintentional and typically involve high rates of traffic destined for the supervisor module or switch CPU.

The supervisor module processes traffic through the following functional planes:

Data plane —Forwards data packets from one interface to another. Packets that are not destined for the switch are transit packets and are processed by the data plane.
Control plane —Processes routing protocol traffic. Protocols such as Border Gateway Protocol (BGP) and Open Shortest Path First (OSPF) exchange control packets that are destined for router addresses.

Denial-of-service attacks

The control plane is critical to the operation of the Cisco ACI fabric. Excessive traffic can overload the supervisor module, consume resources needed to process legitimate traffic, and disrupt the network.

Examples of DoS attacks include:

Internet Control Message Protocol (ICMP) echo requests
IP fragments
TCP SYN floods

DoS attacks can cause the following conditions:

Reduced service quality for voice, video, and critical application traffic
High route processor or switch processor CPU utilization
Route flaps caused by the loss of routing protocol updates or keepalive messages
Exhaustion of processor resources, including memory and buffers
Indiscriminate drops of incoming packets

Control plane protection

NX-OS on Cisco ACI leaf and spine switches classifies traffic destined for the control plane. CoPP then applies a policer to each traffic class to prevent the traffic from overwhelming the supervisor module.

Control plane packet types

The following packet types can reach the control plane:

Receive packets —Packets destined for a Layer 2 or Layer 3 address of the router, such as a router MAC address or an interface IP address. These packets include routing updates, keepalive messages, and packets sent to multicast addresses used by the router.
Exception packets —Packets that require special handling by the supervisor module. For example, if a destination address is not present in the Forwarding Information Base (FIB), the resulting miss does not cause the supervisor module to send an ICMP unreachable message. This behavior protects the supervisor module from distributed denial-of-service (DDoS) attacks. The supervisor module also drops IP packets that contain IP options.
Redirect packets —Packets that a feature redirects to the supervisor module. For example, Dynamic Host Configuration Protocol (DHCP) snooping and dynamic Address Resolution Protocol (ARP) inspection redirect certain packets to the supervisor module.
Glean packets —Packets received by the supervisor module when the FIB does not contain a Layer 2 MAC address for the destination IP address. The supervisor module sends an ARP request to resolve the destination.

CoPP classification

Any control plane packet type can be used to overwhelm the fabric. CoPP separates packets into traffic classes so that you can control the rate at which the supervisor module receives each type.

Different rate-control policies can be applied according to the packet type. For example, a routing protocol hello packet can have a less restrictive rate limit than an exception packet that contains an IP option.

Available classification categories

The available categories are 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 , and ToR-Glean .

Rate-control parameters

For each classification category, you can configure the rate and burst parameters in packets per second (PPS).

Committed information rate (CIR) —The desired traffic rate, specified in PPS.
Committed burst (BC) —The number of packets that can exceed the CIR during a specified interval without affecting scheduling.

Default policing policies

When a leaf or spine switch first boots, NX-OS applies predefined CoPP parameters for the supported traffic categories. Cisco determines the default values through testing.

Note

CoPP protects Cisco ACI leaf and spine switches by default. You can tune the CoPP parameters for a group of nodes to meet operational requirements.

CoPP guidelines and limitations

Use these guidelines when configuring and monitoring CoPP policies.

Policy configuration and monitoring

Begin with the default CoPP policy. Modify the policy as needed to meet data center and application requirements.
Review CoPP policies whenever the protocols, features, or control plane services used in the environment change.
Continuously monitor CoPP. If packet drops occur, determine whether CoPP responded to an attack or malfunction or unintentionally dropped legitimate traffic. Adjust the policy if necessary.
Ensure that the CoPP policy does not filter critical traffic, such as routing protocol traffic or interactive management traffic. Filtering this traffic can prevent remote access to a Cisco ACI leaf or spine switch and require a console connection.
Configure CoPP prefilter entries carefully. Incorrect entries can affect connectivity in Multi-Pod, remote leaf, and Cisco ACI Multi-Site deployments.
Use the Cisco APIC GUI to tune CoPP parameters.

Per-interface, per-protocol limitations

Per-interface, per-protocol policing is supported only on leaf switches.
Fabric Extender (FEX) ports do not support per-interface, per-protocol policing.
The supported protocols are ARP, ICMP, CDP, LLDP, LACP, BGP, STP, BFD, and OSPF.
Per-interface, per-protocol policing supports a maximum of 256 ternary content-addressable memory (TCAM) entries. Cisco APIC raises a fault when this limit is exceeded.

Configure CoPP by using the Cisco APIC GUI

Procedure

On the menu bar, choose Fabric > Access Policies .
In the Navigation pane, expand Policies > Switch , right-click CoPP Leaf , and choose Create CoPP Leaf Level Policy .
In the Create CoPP Leaf Level Policy dialog box, configure the policy.
1. In the Name field, enter a name for the policy.
2. In the Type of Profile field, choose the profile type.
  
  Choose CoPP has custom values to configure each protocol independently. If you do not choose a profile type, the system applies the default values.
3. Click Submit .
In the Navigation pane, expand Switches > Leaf Switches , right-click Policy Groups , and choose Create Access Switch Policy Group .
In the Create Access Switch Policy Group dialog box, configure the policy group.
1. In the Name field, enter a name for the policy group.
2. In the COPP Leaf Policy field, choose the CoPP policy that you created.
3. Click Submit .
In the Navigation pane, expand Switches > Leaf Switches , right-click Profiles , and choose Create Leaf Profile .
In the Create Leaf Profile dialog box, configure the leaf profile.
1. In the Name field, enter a name for the profile.
2. In the Leaf Selectors table, click + .
3. In the Name field, enter a name for the leaf selector.
4. In the Blocks field, choose the leaf switches.
5. In the Policy Group field, choose the access switch policy group that you created.
6. Click Update .
7. Click Next , and then click Finish .

The CoPP policy is assigned to the selected leaf switches through the access switch policy group.

Configure CoPP by using the REST API

The following examples configure custom BGP rate and burst values and associate each CoPP profile with a switch policy group.

Procedure

Send a POST request to https://<apic-ip-address>/api/node/mo/uni.xml with an XML payload similar to the following example to configure a CoPP leaf profile:

Example:

<infraInfra>
            <!-- Define the custom CoPP leaf profile. -->
            <coppLeafProfile name="mycustom" type="custom">
            <coppLeafGen1CustomValues bgpBurst="150" bgpRate="300"/>
            </coppLeafProfile>
            <!-- Select leaf nodes 101 and 103 and assign the policy group. -->
            <infraNodeP name="leafCopp">
            <infraLeafS name="leafs" type="range">
            <infraNodeBlk name="leaf1" from_="101" to_="101"/>
            <infraNodeBlk name="leaf3" from_="103" to_="103"/>
            <infraRsAccNodePGrp
            tDn="uni/infra/funcprof/accnodepgrp-myLeafCopp"/>
            </infraLeafS>
            </infraNodeP>
            <!-- Bind the CoPP leaf profile to the policy group. -->
            <infraFuncP>
            <infraAccNodePGrp name="myLeafCopp">
            <infraRsLeafCoppProfile tnCoppLeafProfileName="mycustom"/>
            </infraAccNodePGrp>
            </infraFuncP>
            </infraInfra>

Send a POST request to https://<apic-ip-address>/api/node/mo/uni.xml with an XML payload similar to the following example to configure a CoPP spine profile:

Example:

<infraInfra>
            <!-- Define the custom CoPP spine profile. -->
            <coppSpineProfile name="mycustomSpine" type="custom">
            <coppSpineGen1CustomValues bgpBurst="150" bgpRate="300"/>
            </coppSpineProfile>
            <!-- Select spine node 104 and assign the policy group. -->
            <infraSpineP name="spineCopp">
            <infraSpineS name="spines" type="range">
            <infraNodeBlk name="spine1" from_="104" to_="104"/>
            <infraRsSpineAccNodePGrp
            tDn="uni/infra/funcprof/spaccnodepgrp-mySpineCopp"/>
            </infraSpineS>
            </infraSpineP>
            <!-- Bind the CoPP spine profile to the policy group. -->
            <infraFuncP>
            <infraSpineAccNodePGrp name="mySpineCopp">
            <infraRsSpineCoppProfile
            tnCoppSpineProfileName="mycustomSpine"/>
            </infraSpineAccNodePGrp>
            </infraFuncP>
            </infraInfra>

The custom CoPP profiles are assigned to the specified leaf and spine switches.

View CoPP statistics by using the GUI

Review CoPP packet statistics before fine-tuning the policy for a node.

Procedure

On the menu bar, choose Fabric > Inventory .
In the Navigation pane, choose Pod pod-number > Node node-name > Control Plane Statistics > default .
Select a traffic class and configure the statistics display format.

The GUI displays the number of packets that CoPP allowed or dropped for the selected traffic class.

Configure a per-interface, per-protocol CoPP policy by using the Cisco APIC GUI

The navigation paths and field names differ between releases earlier than Cisco APIC release 6.2(3) and release 6.2(3) or later.

Procedure

On the menu bar, choose Fabric > Access Policies.
In the Navigation pane, expand Policies > Interface, right click CoPP Interface, and click Create Per Interface Per Protocol CoPP Policy:
1. In the Name field, add a policy name.
2. In the CoPP policy Protocol table, click + and enter the protocol name, match proto, rate, and burst information.
3. Click Update and Submit.
In the Navigation pane, expand Interfaces > Leaf Interfaces > Policy Groups, right click Leaf Access Port, and click Create Leaf Access Port Policy Group.

Perform the following actions in the Create Leaf Access Port Policy Group dialog box:
1. In the Name field, add a policy name.
2. In the CoPP Policy field, select the policy that you previously created.
3. Click Submit.
In the Navigation pane, expand Interfaces > Leaf Interfaces, right click Profiles, click Create Leaf Interface Profile:

Perform the following actions in the Create Leaf Interface Profile dialog box:
1. In the Name field, add a profile name.
2. In the Interface Selectors table, click + and add the name, interface IDs, and interface policy group that you previously created.
3. Click OK and Submit to complete Per Interface Per Protocol CoPP configuration.

Configure per-interface, per-protocol CoPP by using the REST API

The following example applies a CoPP policy to interfaces 1/1 through 1/7 on leaf node 101. The policy defines one class for LLDP and ARP traffic and another class for BGP traffic.

Procedure

Send a POST request to https://<apic-ip-address>/api/node/mo/.xml with an XML payload similar to the following example:

Example:

<polUni>
                        <infraInfra>
                        <!-- Select leaf node 101 and associate the interface profile. -->
                        <infraNodeP name="default">
                        <infraLeafS name="default" type="range">
                        <infraNodeBlk name="default" from_="101" to_="101"/>
                        </infraLeafS>
                        <infraRsAccPortP tDn="uni/infra/accportprof-default"/>
                        </infraNodeP>
                        <!-- Select interfaces 1/1 through 1/7 and assign the policy group. -->
                        <infraAccPortP name="default">
                        <infraHPortS name="regularPorts" type="range">
                        <infraPortBlk name="blk1" fromCard="1" toCard="1"
                        fromPort="1" toPort="7"/>
                        <infraRsAccBaseGrp
                        tDn="uni/infra/funcprof/accportgrp-copp"/>
                        </infraHPortS>
                        </infraAccPortP>
                        <!-- Bind the CoPP policy to the interface policy group. -->
                        <infraFuncP>
                        <infraAccPortGrp name="copp">
                        <infraRsCoppIfPol tnCoppIfPolName="pc"/>
                        </infraAccPortGrp>
                        </infraFuncP>
                        <!-- Define the per-interface, per-protocol CoPP policy. -->
                        <coppIfPol name="pc">
                        <coppProtoClassP name="test" matchProto="lldp,arp"
                        rate="505" burst="201"/>
                        <coppProtoClassP name="test1" matchProto="bgp"
                        rate="500" burst="200"/>
                        </coppIfPol>
                        </infraInfra>
                        </polUni>

The CoPP policy applies the configured protocol-specific rate and burst limits to the selected leaf switch interfaces.

Need help?

Open a support case

(Requires a Cisco Service Contract)

The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.