Control Plane Policing (CoPP)
Control plane attacks are growing, so protecting the network infrastructure against these types of attacks is imminently required. Control plane policing (CoPP), a Cisco IOS feature that has been available since IOS release 12.2(18)S, allows you to configure a QoS filter that manages the traffic flow of control plane packets. Using CoPP, you can protect the control plane of Cisco IOS routers and switches against DoS and reconnaissance attacks and ensure network stability (router/switch stability in particular) during an attack. Deploying CoPP is a recommended best practice and a key protection mechanism.
The route processor routes and forwards the majority of the traffic that enters a router; the destination of this type of traffic, called data plane traffic, is elsewhere other than the router itself. On the other hand, some traffic—such as routing updates, management traffic, keepalives, and so on—is indeed for the router; this type of traffic is called control and management plane traffic. Formally, the Cisco router functional planes are enlisted as data plane, management plane, control plane, and service plane. Excessive and malicious traffic in the form of control and management traffic aimed at the route processor can have the following devastating results:
■ High or close to 100 percent utilization of CPU or other resources such as memory and buffers
■ Loss of routing updates and keepalives, resulting in route flaps and erroneous NLRI (network layer reachability information) withdrawals and updates
■ Slow response times and interactive sessions, including command-line interface (CLI) through virtual terminal lines
■ Queue buildups, resulting in excessive delays and tail drops, or drops due to lack of buffer space
CoPP mitigates control plane attacks and ensures stability and availability of the routers and switches. CoPP is configured by applying a policy map to the control plane from the control plane configuration mode. In other words, CoPP is applied using modular QoS command-line interface (MQC), providing filtering and rate-limiting for control plane packets. Those devices with route processors on line card modules can be protected by distributed CoPP or control plane configuration mode on the particular slot number. The four steps to configure CoPP are as follows:
Step 1 Define a packet classification criteria. (Use MQC class-map.)
Step 2 Define a service policy. (Use MQC policy-map.)
Step 3 Enter control plane configuration mode.
Step 4 Apply a QoS policy.
Example 6-2 shows a configuration that allows two 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 policing all remaining Telnet packets to the control plane at the specified rate. The access list matches all Telnet traffic except that from hosts 10.1.1.1 and 10.1.1.2. The class map telnet-class is defined for all traffic matching access list 100. The policy map telnet-policy applies the police command to the traffic matching class telnet-class. Finally, the telnet-policy is applied to the control plane using the service-policy command. The QoS policy shown in Example 6-2 is applied for aggregate CP services to all packets that are entering the control plane from all line cards in the router.
Example 6-2 CoPP Example: QoS Policy Applied for Aggregate CP Services
Example 6-3 shows a similar example, but for distributed CP services, allowing two 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 policing all remaining Telnet packets that enter through slot 1 at the specified rate.
Example 6-3 CoPP Example: QoS Policy Applied for Distributed CP Services
Foundation Summary
The "Foundation Summary" is a collection of information that provides a convenient review of many key concepts in this topic. If you are already comfortable with the topics in this topic, this summary can help you recall a few details. If you just read this topic, this review should help solidify some key facts. If you are doing your final preparation before the exam, the information in this section is a convenient way to review the day before the exam.
A virtual private network (VPN) carries private traffic over a public network. It is established between end systems or between networks. VPNs provide three functions:
■ Confidentiality
■ Data integrity
■ Origin authentication
Two general types of VPN exist, each with its own variations:
■ Remote access
— Client initiated
— Network access server (NAS) initiated
■ Site-to-site
— Intranet
— Extranet
The most common Layer 3 tunneling protocols are as follows:
■ Generic routing encapsulation (GRE)
■ Internet Protocol security (IPsec)
QoS pre-classify is a Cisco IOS feature that allows packets to be classified before tunneling and encryption occur. The need to classify traffic within a traffic tunnel is growing side by side with the growth in VPN popularity.
The QoS pre-classify feature provides access to the original (encapsulated) IP packet header fields. If IP QoS classification needs access to those fields, using the QoS pre-classify feature will be necessary. You can use one of three approaches to apply the QoS policy and the QoS pre-classify features:
■ To classify packets based on the pre-tunnel header, apply the QoS policy to the tunnel interface without QoS pre-classify.
■ To classify packets based on the post-tunnel header, apply the QoS policy to the physical interface without QoS pre-classify.
■ To classify packets based on the pre-tunnel header, apply the QoS policy to the physical interface and enable QoS pre-classify.
With the growth of multimedia and real-time applications such as IP Telephony, conferencing, and e-learning, QoS service level agreements (SLAs) have become more important than before. The QoS SLAs provide contractual assurance for parameters such as availability, throughput, delay, jitter, and packet loss.
To meet the QoS requirements of customer applications, the service provider and customer both must implement proper QoS mechanisms. This means that you must implement QoS in the customer campus, at the customer WAN edge device outbound toward the provider network, on the PE device inbound from the customer edge, on the provider network, on the PE device at the remote site outbound toward the remote customer site, and on the remote customer site (remote campus). Generally, deploying end-to-end QoS is specified to be necessary at three locations:
■ On campus
■ On the WAN edge (CE/PE)
■ On the service provider cloud
Table 6-3 provides a short list of important QoS-related tasks that might be necessary at different locations on the customer and provider premises. Implementing these and possibly other tasks on both the customer and provider devices supports the effort to provide end-to-end QoS.
Table 6-3 Necessary QoS Tasks (at Different Spots) for End-to-End QoS
|
Campus Access |
Campus Distribution |
WAN Edge |
Service Provider Cloud |
|
Speed and duplex settings |
Layer 3 policing and marking |
SLA definitions |
Capacity planning |
|
Classification and trust settings |
Multiple queues on switch ports |
Classification and marking |
DiffServ implementation (PHB) |
|
Phone and access switch configurations |
Priority queuing for VoIP |
Low-latency queuing |
Low-latency queuing |
|
Multiple queues on switch ports |
WRED within data queues for congestion avoidance |
Link fragmentation and interleaving |
Modified deficit round robin |
|
Priority queuing for VoIP |
- |
WRED and traffic shaping |
WRED |
Following are the general guidelines for enterprise campus QoS implementations:
■ Implement multiple queues on all interfaces to prevent transmit queue congestion and packet drops.
■ Assign voice (and video) traffic to the highest priority queue.
■ Establish proper trust boundaries. (Trust the Cisco IP phone CoS setting, not the PCs.)
■ Classify and mark traffic as close to the source as possible.
■ Use class-based policing to rate-limit certain unwanted excess traffic.
■ Try to perform QoS in hardware rather than software when possible.
WAN edge QoS implementation has two facets: features applied to the traffic leaving the enterprise network (toward the provider network), and features applied to the traffic leaving the provider network toward the customer network. In both cases, note whether the CE device is provider managed.
For the traffic leaving the enterprise network (via CE) moving toward the provider network, if the CE device is provider managed, these are the QoS requirements:
■ The service provider controls output of the QoS policy on the CE.
■ The service provider should enforce SLA using the output QoS policy on the CE.
■ The output policy uses queuing, dropping, and shaping.
■ Elaborate traffic classification or mapping of existing markings takes place on the CE.
■ Link fragmentation and interleaving and compressed RTP might be necessary. If the CE device is not provider managed, these are the QoS requirements:
■ The service provider controls output of the QoS policy on the CE.
■ The service provider should enforce SLA using the input QoS policy on the PE.
■ The input policy should use policing and marking.
■ Elaborate traffic classification or mapping of existing markings takes place on the PE.
For traffic leaving the service provider network (via PE) moving toward the enterprise customer network, these are the QoS requirements (for both managed and unmanaged-CE cases):
■ The service provider should enforce SLA using the output QoS policy on the PE.
■ The output policy should use queuing, dropping, and optionally shaping.
■ LFI or cRTP might be required.
■ The input QoS policy on the CE is not implemented if the CE is provider managed, but the customer might implement certain QoS features on the customer-managed CE to meet the end-to-end QoS budgets.
The functional planes of Cisco routers are data plane, management plane, control plane, and service plane. Control plane policing (CoPP) is a Cisco IOS feature that allows you to build QoS filters to manage the flow of control plane packets to protect the control plane against DoS attacks. Because infrastructure attacks are becoming increasingly common, protecting the control plane of the routers and switches using CoPP against reconnaissance and DoS attacks is crucial. The four steps required to deploy CoPP (using MQC) are as follows:
Step 1 Define the packet classification criteria.
Step 2 Define a service policy.
Step 3 Enter the control plane configuration mode.
Step 4 Apply a QoS policy.
