Configuring the Control Plane Protection feature on your Cisco router provides the following benefits:

• Extends protection against DoS attacks at infrastructure routers by providing mechanism for finer policing granularity for control-plane traffic that allows you to rate-limit each type individually.
• Provides a mechanism for early dropping of packets that are directed to closed or nonlistened IOS TCP/UDP ports.
• Provides ability to limit protocol queue usage such that no single protocol flood can overwhelm the input interface.
• Provides QoS control for packets that are destined to the control-plane of Cisco routers.
• Provides ease of configuration for control plane policies using MQC Infrastructure.
• Provides better platform reliability, security and availability.
• Provides dedicated control-plane subinterface for aggregate, host, transit and cef-exception control-plane traffic processing.
• Is highly flexible: permit, deny, rate-limit.
• Provides CPU protection so it can be used for important jobs, such as routing.

The figure below shows control-plane architecture with the Control Plane Protection feature.

Figure 1

Control-plane Architecture with Control Plane Protection

The following sections describe the components of the Control Plane Protections feature.

Control Plane Policing (CoPP) introduced the concept of early rate-limiting protocol specific traffic destined to the processor by applying QoS policies to the aggregate control-plane interface. Control Plane Protection extends this control plane functionality by providing three additional control-plane subinterfaces under the top-level (aggregate) control-plane interface. Each subinterface receives and processes a specific type of control-plane traffic. The three subinterfaces are:

• Control-plane host subinterface . This interface receives all control-plane IP traffic that is directly destined for one of the router interfaces. Examples of control-plane host IP traffic include tunnel termination traffic, management traffic or routing protocols such as SSH, SNMP, BGP, OSPF, and EIGRP. All host traffic terminates on and is processed by the router. Most control plane protection features and policies operate strictly on the control-plane host subinterface. Since most critical router control plane services, such as routing protocols and management traffic, is received on the control-plane host subinterface, it is critical to protect this traffic through policing and protection policies. CoPP, port-filtering and per-protocol queue thresholding protection features can be applied on the control-plane host subinterface.

Note	Non-IP based Layer 2 protocol packets such as ARP or CDP do not fall within the control-plane host subinterface. These packets are currently classified in the control-plane CEF-exception subinterface traffic.

• Control-plane transit subinterface . This subinterface receives all control-plane IP traffic that is software switched by the route processor. This means packets that are not directly destined to the router itself but rather traffic traversing through the router. Nonterminating tunnels handled by the router is an example of this type of control-plane traffic. Control Plane Protection allows specific aggregate policing of all traffic received at this subinterface.
• Control-plane CEF-exception subinterface . This control-plane subinterface receives all traffic that is either redirected as a result of a configured input feature in the CEF packet forwarding path for process switching or directly enqueued in the control plane input queue by the interface driver (i.e. ARP, L2 Keepalives and all non-IP host traffic). Control Plane Protection allows specific aggregate policing of this type of control plane traffic.

QoS policies attached on any of the control-plane interfaces or subinterfaces execute at interrupt level prior to packets being enqueued to the IP input queue and sent to the processor.

The transit and CEF-exception control plane subinterfaces exist in parallel to the control plane host subinterface. This release of Control Plane Protection allows for rate-limiting policies to be configured on these paths as Control Plane Policing extensions. The port-filtering and per-protocol queue thresholding features are not available on these control-plane subinterfaces.

All protection features in the control plane are implemented as MQC policies that operate using the control plane class-maps and policy-maps. New class-map and policy-map types have been created for the control plane port-filter and per-protocol queue-threshold features.

The control-plane Port-filtering feature enhances control plane protection by providing for early dropping of packets directed toward closed or nonlistened IOS TCP/UDP ports on the router. The port-filter feature policy can be applied only to the control-plane host subinterface.

The port-filter maintains a global database of all open TCP and UDP ports on the router, including random ephemeral ports created by applications. The port database is dynamically populated with entries provided by the registered applications as they start listening on their advertised ports either by configuration of an application (that is SNMP) or initiation of an application (that is, TFTP transfer). An MQC class-map using the list of open ports can be configured and a simple drop policy can be applied to drop all packets destined to closed or nonlistened ports. Port-filter class-maps also support direct match of any user configured TCP/UDP port numbers.

Control-plane protocol Queue-thresholding feature provides a mechanism for limiting the number of unprocessed packets a protocol can have at process-level. This feature can only be applied to the control-plane host subinterface. The intent of this feature is to prevent the input queue from being overwhelmed by any single protocol traffic. Per-protocol thresholding follows a protocol charge model. Each protocol's queue usage is limited such that no single mis-behaving protocol process can jam the interface hold queue. In this release, only a subset of TCP/UDP protocols can be configured for thresholding. Non-IP and Layer 2 protocols such as ARP and CDP cannot be configured. You can set queue limits for the following protocols:

• bgp--Border Gateway Protocol
• dns--Domain Name Server lookup
• ftp--File Transfer Protocol
• http--World Wide Web traffic
• igmp-- Internet Group Management Protocol
• snmp--Simple Network Management Protocol
• ssh--Secure Shell Protocol
• syslog--Syslog Server
• telnet--Telnet
• tftp--Trivial File Transfer Protocol
• host-protocols--A wild card for all TCP/UDP protocol ports open on the router not specifically matched/configured

Control-plane Policing is an existing Cisco IOS feature that allows QoS policing of aggregate control-plane traffic destined to the route processor. The Control Plane Protection feature enhances protection for the router's control-plane by providing finer granularity of policing of traffic destined to the router's processor entering through any of the three control-plane subinterfaces. The CoPP feature is intended to be the first Control Plane Protection feature encountered by packets before any other features/policies. Existing (aggregate) Control-plane Policing policies will not be affected when the Control Plane Protection functionality is enabled. The aggregate Control-plane Policing policy will be applied on all control-plane traffic types. However, Control Plane Protection allows for additional and/or separate Control-plane Policing policies to be configured and applied on the different types of control-plane subinterfaces (host, transit, CEF-exception).

The CLI for control-plane (introduced with the Control Plane Policing feature) has been extended to allow for CoPP policies to be applied to individual control-plane subinterfaces (host, transit, CEF-exception). The command syntax for creating CoPP Service Policies remains the same. In addition, the MQC class-map and policy-map CLI was modified to allow for additional types. The port-filter and queue-threshold policy features available in the host subinterface uses these new class-map and policy-map "types".

CoPP leverages MQC to define traffic classification criteria and to specify configurable policy actions for the classified traffic. Traffic of interest must first be identified via class-maps, which are used to define packets for a particular traffic class. Once classified, enforceable policy actions for the identified traffic are created with policy-maps. The control-plane global command allows the control-plane service policies to be attached to the aggregate control-plane interface itself.

The CLI for configuring Control-plane Policing policies on the new control-plane subinterfaces remains basically the same as the CLI introduced for Control-plane Policing. The only difference is in how you apply or attach the CoPP policy to the different control-plane subinterfaces.

Before You Begin

Before you attach an existing QoS policy to the control-plane subinterface, you must first create the policy using the MQC to define a class map and policy map for control-plane traffic.

For information about how to classify traffic and create a QoS policy, see the QoS: Modular QoS: Command-Line Interface Configuration Guide.

Note

The Control-plane Policing feature requires the MQC to configure packet classification and policing. Thus, restrictions that apply to MQC also apply to control-plane policing. Only the following classification (match) criteria are supported: standard and extended IP access lists (named or numbered) and the match ip dscp command, the match ip precedence command, and the match protocol arp command. The control-plane policing CLI does not support "type" extensions available with other protection features. This is to preserve backward-compatibility.

1.    enable

2.    configure terminal

3.    class-map [match-any | match-all] class-map-name

4.    match {access-group | name access-group-name}

To define a service policy, use the policy-map global configuration command to specify the service policy name, and use the configuration commands to associate a traffic class that was configured with the class-map command, with the QoS action. The traffic class is associated with the service policy when the class command is used. You must issue the class command after entering policy-map configuration mode. After entering the class command, you are automatically in policy-map class configuration mode.

For information about how to classify traffic and create a QoS policy, see the QoS: Modular QoS: Command-Line Interface Configuration Guide.

Note

Platform-specific restrictions, if any, are checked when the service policy is applied to the control-plane interface. The Control-plane Policing feature requires the modular QoS command-line interface (CLI) (MQC) to configure packet classification and policing. Thus, restrictions that apply to MQC also apply to control-plane policing. Also, only two MQC actions are supported in policy maps - police and drop. Support for output policing is available only in Cisco IOS Release 12.3(4)T and later T-train releases, and only on the aggregate control-plane interface. Only input policing is available on the new control-plane host, transit and CEF-exception subinterfaces. (Note that output policing does not provide any performance benefits. It simply controls the information that is leaving the device.)

1.    enable

2.    configure terminal

3.    policy-map policy-map-name

4.    class class-name

5.    police rate [burst-normal] [burst-max] conform-action action exceed-action action [violate-action action]

After you have created a class of traffic and defined the service policy for the control-plane, apply the policy to either the aggregate control-plane interface or one of the subinterfaces.

Note

Platform-specific restrictions, if any, are checked when the service policy is applied to the control-plane interface. Support for output policing is available only in Cisco IOS Release 12.3(4)T and later T-train releases, and only on the aggregate control-plane interface. Only input policing is available on the new control-plane host, transit and CEF-exception subinterfaces. (Note that output policing does not provide any performance benefits. It simply controls the information that is leaving the device.)

1.    enable

2.    configure terminal

3.    control-plane [host | transit | cef-exception]

Before You Begin

Before you attach an existing QoS policy to the control-plane, you must first create the policy by using MQC to define a class map and policy map for control-plane traffic.

For information about how to classify traffic and create a QoS policy, see the QoS: Modular QoS: Command-Line Interface Configuration Guide.

Note

Platform-specific restrictions, if any, are checked when the service policy is applied to the control-plane interface. Support for output policing is available only in Cisco IOS Release 12.3(4)T and later T-train releases, and only on the aggregate control-plane interface. Only input policing is available on the new control-plane host, transit and CEF-exception subinterfaces. (Note that output policing does not provide any performance benefits. It simply controls the information that is leaving the device.)

1.    enable

2.    configure terminal

3.    control-plane [host | transit | cef-exception]

4.    service-policy {input | output} policy-map-name

You can apply the port-filter policy feature to the control-plane host subinterface to block traffic destined to closed or nonlistened TCP/UDP ports. New class-map and service-policy types have been created to accommodate the port-filter configuration. The classification and match criteria for the new port-filter class-maps supports only a constrained subset of the overall global MQC match criteria. Also, the actions supported by the new port-filter service policy is limited as well. that is only the drop action is supported

• Restrictions
  
• Defining Port-filter Packet Classification Criteria
  
• Defining Port-filter Service Policy
  
• Applying Port-filter Service Policy to the Host Subinterface
  

The Control Plane Protection feature includes a new queue-threshold policy feature that can be applied to the control-plane host subinterface. The queue-threshold feature allows you to limit the number of packets for a given higher level protocol allowed in the control-plane IP input queue. Much like the port-filter feature, new class-map and policy-map types have been created to accommodate the queue-threshold feature. As with the port-filter feature, the queue-threshold feature supports a very specific class-map and policy-map capabilities.

• Restrictions
  
• Defining Queue-threshold Packet Classification Criteria
  
• Defining a Queue-threshold Service Policy
  
• Applying a Queue-threshold Policy to the Host Subinterface
  

1.    enable

2.    show policy-map [type policy-type] control-plane [pfx | slot slot number] [all] [host | transit | cef-exception] [{input | output} [class class-name]]

• Examples