Catalyst 4500 Series Switch Software Configuration Guide, Release IOS XE 3.3(0)XO

About Control Plane Policing

The control plane policing (CoPP) feature increases security on the Catalyst 4500 series switch by protecting the CPU from unnecessary or DoS traffic and giving priority to important control plane and management traffic. The classification TCAM and QoS policers provide CoPP hardware support.

Traffic managed by the CPU is divided into three functional components or planes :

• Data plane
• Management plane
• Control plane

You can use CoPP to protect most of CPU-bound traffic and to ensure routing stability, reachability, and packet delivery. Most importantly, you can use CoPP to protect the CPU from a DoS attack.

By default, you receive a list of predefined ACLs matching a selected set of Layer 2 and Layer 3 control plane packets. You can further define your preferred policing parameters for each of these packets and modify the matching criteria of these ACLs.

The following table lists the predefined ACLs.

For the data and management plane traffic, you can define your own ACLs to match the traffic class that you want to police.

CoPP uses MQC to define traffic classification criteria and to specify the configurable policy actions for the classified traffic. MQC uses class maps to define packets for a particular traffic class. After you have classified the traffic, you can create policy maps to enforce policy actions for the identified traffic. The control-plane global configuration command allows you to directly attach a CoPP service policy to the control plane.

The policy map system-cpp-policy must contain the predefined class maps in the predefined order at the beginning of the policy map. The best way to create system-cpp-policy policy map is by using the global macro system-cpp.

The system-cpp-policy policy map contains the predefined class maps for the control plane traffic. The names of all system-defined CoPP class maps and their matching ACLs contain the prefix system-cpp-. By default, no action is specified for each traffic class. You can define your own class maps matching CPU-bound data plane and management plane traffic. You can also add your defined class maps to system-cpp-policy.

General Guidelines for Control Plane Policing

Guidelines for control plane policing include the following:

• Port security might cancel the effect of CoPP for non-IP control packets.

Although source MAC learning on a Catalyst 4500 series switch is performed in software, learning control packets' source MAC addresses (for example, IEEE BPDU, CDP, SSTP BPDU, GARP/) is not allowed. Once you configure port security on a port where you expect a high rate of potentially unanticipated control packets, the system generates a copy of the packet to the CPU (until the source address is learned), instead of forward it.

The current architecture of the Catalyst 4500 supervisor engine does not allow you to apply policing on the copy of packets sent to the CPU. You can only apply policing on packets that are forwarded to the CPU. Copies of packets are sent to the CPU at the same rate as control packets, and port security is not triggered because learning from control packets is not allowed. Policing is not applied because the packet copy, not the original, is sent to the CPU.

• Only ingress CoPP is supported. So only input keyword is supported in control-plane related CLIs.
• Use ACLs and class-maps to identify data plane and management plane traffic that are handled by CPU.
• The only action supported in CoPP policy-map is police.
• Do not use the log keyword in the CoPP policy ACLs.

Default Configuration

CoPP is disabled by default.

Configuring CoPP for Control Plane Traffic

To configure CoPP for control plane traffic, perform this task:

The following example shows how to police CDP packets:

Configuring CoPP for Data Plane and Management Plane Traffic

To configure CoPP for data plane and management plane traffic, perform this task:

The following example shows how to configure trusted hosts with source addresses 10.1.1.1 and 10.1.1.2 to forward Telnet packets to the control plane without constraint, while allowing all remaining Telnet packets to be policed at the specific rate. This example assumes that global QoS is enabled and that the system-cpp-policy policy map was created.

Control Plane Policing Configuration Guidelines and Restrictions

When using (or configuring) control plane policing, consider these guidelines and restrictions:

• Only ingress CoPP is supported. Only the input keyword is supported in control plane-related CLIs.
• Control plane traffic can be policed only through CoPP. Traffic cannot be policed at the input interface or VLAN even though a policy map containing the control plane traffic is accepted when the policy map is attached to an interface or VLAN.
• Use ACLs and class maps to identify data plane and management plane traffic that are handled by the CPU. U1ser defined class maps should be added to the system-cpp-policy policy map for CoPP.
• The default system-cpp-policy policy map does not define actions for the system-defined class maps (no policing).
• The only action supported in system-cpp-policy is police.
• You can use both MAC and IP ACLs to define data plane and management plane traffic classes. However, if a packet also matches a predefined ACL for the control plane traffic, a police (or no police) action will operate on the control plane class because the control plane classes appear above the user-defined classes in the service policy.
• The exceeding action policed-dscp-transmit is not supported for CoPP.
• Do not use the log keyword in CoPP policy ACLs. Instead, if you want to determine if rogue packets are arriving, view the output of the show policy-map interface command or use the span feature.
• To police control plane traffic, use the system-defined class maps.
• System-defined class maps cannot be used in policy maps for regular QoS.
• The policy map named system-cpp-policy is dedicated for CoPP.
• CoPP is not enabled unless global QoS is enabled and a police action is specified.

Understanding Layer 2 Control Packet QoS

You might want to police incoming Layer 2 control packets such as STP, CDP, VTP, SSTP, BPDU, EAPOL and LLDP on a specific port before the packets reach CPU. This could serve as a first line of defense before aggregate traffic is subjected to policing (through CoPP). By default, policers cannot be applied to Layer 2 control packets in the input direction. This prevents users from inadvertently policing or dropping critical Layer 2 control packets.

While this approach protects a user who is wrongly policing control packets, it introduces a more serious problem. If a flood of Layer 2 control packets is received on any of the switch interfaces at a very high rate due to a DoS attack or to a loop introduced in the customer network because of misconfiguration, CPU utilization can increase quickly. This can have adverse impacts such as loss of protocol keep-alives and routing protocol updates. The Layer 2 control packet QoS feature allows you to police Layer 2 control packets at the port, VLAN, or port- VLAN level in the input direction.

Default Configuration

Layer 2 control packet QoS is disabled by default.

Enabling Layer 2 Control Packet QoS

To enable Layer 2 control packet QoS, perform this task:

Table 45-1 lists the types of packets impacted by this feature.

The following example shows how to enable QoS for CDP packets and to apply a policer to CDP packets arriving on interface gi3/1 and VLAN 1:

Disabling Layer 2 Control Packet QoS

The no qos control-packet command disables QoS for all packet types.

The following example shows how to disable QoS for CDP packets after QoS is enabled for all packet types:

Note When all control packets (CDP/VTP, bpdu-range, SSTP, LLDP, and protocol-tunnel), are enabled only qos control-packets is nevgen’d. Individual protocol names mentioned in the previous output are nvegen’d only if the some of the control packets are configured.

Note When you unconfigure this feature for a specified protocol type, the user-configured policies handling that protocol type immediately become ineffective. To save TCAM resources, remove the policies as well as MACLs and class maps (auto-generated or user-defined).

Note TCAM resources are not consumed when the interface is in a down state.

Table 45-2 displays the auto-generated MACLs and class maps that are created when you enable the feature on the corresponding packet type.

Layer 2 Control Packet QoS Configuration Examples

You can use CoPP and Layer 2 control packet QoS together to prevent DoS attacks to the CPU. In the following example, BPDUs arriving on interface gi3/1, VLAN 1 and VLAN 2 are limited to 32 Kbps and 34 Kbps, respectively. Aggregate BPDU traffic to CPU then is further rate-limited to 50 Kbps using CoPP.

Configuring Layer 2 Control Packet QoS

Configuring Control Plane Policy

Note To reduce the consumption of policer resources, you can also use named-aggregate policers applied to a group of ports or VLANs.

Note Do not modify class maps and MACLs that are auto-generated by the system. This action can cause unexpected behavior when the switch reloads or when the running configuration is updated from a file.

To refine or modify system-generated class maps or MACLs, apply user-defined class maps and MACLs.

Note User defined class map names must begin with the prefix system-control-packet.

For example, the following are valid user-defined class map names to police Layer 2 control packets because they begin with the prefix system-control-packet:

No such restrictions exist on the names you can use for user-defined MACLs (access-groups).

The following example shows how to create user-defined MACLs and class maps to identify EAPOL and BPDU packets. Because the auto-generated class map system-control-packet-bpdu range matches three packet types (BPDU, EAPOL, and OAM), policing this traffic class affects all three packet types. To police BPDU and EAPOL packets at different rates, you can set user-defined MACL and class map as follows:

Layer 2 Control Packet QoS Guidelines and Restrictions

When using (or configuring) Layer 2 control packet QoS, consider these guidelines and restrictions:

• When you enable Layer 2 control packet QoS, it applies to all ports on the switch. If Layer 2 control packets are not explicitly classified in the policy attached to port or VLAN, the actions in class-default will be applied as per normal QoS rules.
• Place classifiers that match control packets at the beginning of a policy map followed by other traffic classes, ensuring that Layer 2 control packets are not subjected to inadvertent QoS actions.
• Actions associated with class-default are applied on unmatched control packets.
• If you enable the feature on a BPDU range, EAPOL packets are policed only after the initial 802.1X authentication phase completes.