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:
-
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.
-
In Cisco NX-OS
releases prior to 5.2, you must use the setup utility to change or reapply the
default copp-system-policy policy. You can access the setup utility using the
setup command in the CLI.
-
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.
-
F1 Series modules do not support CoPP.
-
In Cisco NX-OS
Release 5.0, CoPP does not support non-IP traffic classification. Instead, you
can use ACLs to drop or limit the non-IP traffic that reaches the supervisor
module.
-
The following rules apply beginning with Cisco NX-OS Release 5.1: The following rules apply for Cisco NX-OS Release 4.2(6):
-
CoPP supports non-IP and IP traffic classes.
-
L2PT, OTV-ISIS, and FabricPath-ISIS packets are classified under the copp-system-class-critical policy.
-
LLDP and flow-control packets are classified under the copp-system-class-important policy.
-
Dot1x packets are classified under the copp-system-class-normal policy.
-
STP, CDP, UDLD, VTP, LACP, and CFSoE packets are classified under the copp-system-class-l2-unpoliced policy. These packets
are only classified; they are not policed. The corresponding policer simply displays the statistics. These packets are always
forwarded to the supervisor.
-
The rest of the non-IP traffic is classified under the copp-system-class-l2-default policy.
-
IP traffic not matching any of the copp classes is classified under the class-default policy.
-
CoPP MAC
policies are supported beginning with Cisco NX-OS Release 5.1.
-
If you use the
in-service software grade (ISSU) to upgrade to Cisco NX-OS Release 5.1, the
default CoPP policies for the following features must be manually configured:
FabricPath, OTV,
L2PT, LLDP, DHCP, and DOT1X.
-
Beginning with
Cisco NX-OS Release 5.2, the CoPP best practice policy is read-only. If you
want to modify its configuration, you must copy it. Copied policies are treated
as user configurations.
-
When you use
ISSU to upgrade to Cisco NX-OS Release 5.2, the policy attached to the control
plane is treated as a user-configured policy. Check the CoPP profile using the
show
copp profile command and make any required changes.
-
If you use the
in-service software downgrade (ISSD) to downgrade from Cisco NX-OS Release 5.2,
CoPP reports the incompatible configuration and instructs you to copy the CoPP
profile. In the lower version, all configurations are restored in
user-configuration mode.
-
If you
downgrade from Cisco NX-OS Release 5.2 without using ISSD, the CoPP
configuration is lost, and a CoPP policy is no longer attached to the control
plane.
-
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.