Contents
Overview
OverviewStarting with Cisco IOS Software release 12.4(4)T, Control Plane Protection (CPPr) can be used to restrict and/or police control plane traffic destined to the route processor of the Cisco IOS device. Although it is similar to Control Plane Policing (CoPP), CPPr has the ability to restrict/police traffic using finer granularity than that used by CoPP. CPPr divides the aggregate control plane into three separate control plane categories, known as subinterfaces: (1) host, (2) transit, and (3) CEF-exception. In addition, CPPr includes the following additional control plane protection features:
Control Plane Interface and SubinterfacesThe subinterfaces receive the following types of traffic: Control plane host subinterface: This interface receives all control plane IP traffic that is directly destined for one of the router interfaces (physical and loopback). Examples of control plane host IP traffic include tunnel termination traffic; management traffic; and routing protocols such as SSH, SNMP, internal BGP (iBGP), 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. Because most critical router control plane services, such as routing protocols and management traffic, are 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 traffic consists of packets that are not directly destined to the router itself but rather are traffic traversing through the router. Nonterminating tunnels handled by the router are an example of this type of control plane traffic. Control Plane Protection allows specific aggregate policing of all traffic received at this subinterface. Note: Port filtering and per-protocol queue thresholding protection features cannot be applied on the control plane transit 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 (that is, ARP, external BGP (eBGP), OSPF, LDP, Layer 2 keepalives, and all non-IP host traffic). Control Plane Protection allows specific aggregate policing of this type of control plane traffic. Note: Port filtering and per-protocol queue thresholding protection features cannot be applied on the control plane CEF-exception subinterface. CoPP and CPPr Comparison
Benefits of CPPrControl Plane Protection is one of several methods that administrators can use to protect the CPU of a Cisco IOS device. Denial of service (DoS) attacks that either directly or indirectly target the CPU typically involve high rates of traffic that needs to be processed by the CPU. The end result of this traffic can be:
CPPr protects the control and management planes of a Cisco IOS device, which maintains routing stability, network reachability, and packet delivery. Overall, CPPr increases the reliability, confidentiality (security), integrity, and availability of network devices. In addition to the points mentioned above, configuring the Control Plane Protection feature provides the following benefits:
Caveats When Deploying CPPrThe following restrictions may influence administrators' decisions about deploying Control Plane Protection:
router#show control-plane host open-ports Active internet connections (servers and established) Prot Local Address Foreign Address Service State tcp *:22 *:0 SSH-Server LISTEN tcp *:23 *:0 Telnet LISTEN tcp *:23 161.44.52.179:2462 Telnet ESTABLIS tcp *:80 *:0 HTTP CORE LISTEN udp *:2067 255.255.255.255:0 IOS host service LISTEN udp *:49 192.168.130.66:0 TACACS service LISTEN udp *:57554 *:0 IP SNMP LISTEN udp *:67 *:0 DHCPD Receive LISTEN udp *:161 *:0 IP SNMP LISTEN udp *:162 *:0 IP SNMP LISTEN udp *:1985 *:0 cisco HSRP LISTEN router#
InteractionsThere are several features that affect IP packets destined for the route processor of a network device. When deploying CPPr, as with any of the features in the following list, it is important to understand how these features may or may not interact. The following items detail how other features interact with CPPr; the interaction between any two other features is not discussed in this paper.
The following figure illustrates the feature processing order for packets that are destined to the route processor of a device. This figure does not include the processing order for special case features such as receive ACLs and HWRLs.
Deployment Methodology
Policy DevelopmentJust as with CoPP, it is necessary to develop a CPPr policy that is based on a traffic classification methodology. Because CPPr filters traffic destined to the route processor, it is critical to have a thorough understanding of the types of traffic that traverse the network, in particular the traffic that will terminate on the Cisco IOS device being protected by CPPr. Because the CEF-exception and transit subinterfaces will each filter transit traffic, this traffic should simply be rate limited at a conservative rate so that it does not impact any customer applications. In other words, the only type of traffic that should be tightly controlled is the traffic that is directed to the network device itself, that is, the traffic that will flow through to the CPPr host subinterface. Note: Administrators should first perform thorough testing of CPPr configurations in controlled lab environments prior to deploying these configurations in a production setting. Administrators are advised to use the following steps when developing the CPPr policy:
The following details address the first three steps of CPPr policy development. Steps 4 and 5 greatly depend on each environment and would need to be customized for each customer's network. Drop Packets Prior to CPPrThere are several points in the path of the packet prior to CPPr where undesirable packets can and should be dropped. The following considerations can help administrators reduce the number of packets that reach CPPr:
Identify Necessary ProtocolsIdentifying and classifying the types of traffic that traverse an enterprise network is probably the most difficult task that administrators will undertake in the development of the CPPr policies. Some of the tools and techniques that can make the process easier are in the following list:
An example of the output displayed by each of the above commands follows: show ip socket router#show ip socket Proto Remote Port Local Port In Out Stat TTY OutputIF 17 255.255.255.255 0 192.168.128.20 2067 0 0 100001 0 17 0.0.0.0 0 192.168.128.20 67 0 0 2211 0 88 --listen-- --any-- 1 0 0 0 0 17 192.168.130.42 34682 192.168.206.20 161 0 0 1 0 17 --listen-- --any-- 162 0 0 11 0 router# In the preceding output, it is evident that this IOS device has established connections and/or is listening on UDP port 2067, UDP port 67 (DHCP), IPv4 protocol number 88 (EIGRP), UDP port 161 (SNMP), and UDP port 162 (SNMP trap). show tcp brief all router#show tcp brief all TCB Local Address Foreign Address (state) 65BD98BC 192.168.128.20.21376 192.168.130.66.49 TIMEWAIT 65C7E71C 192.168.128.20.23 10.86.115.218.1670 ESTAB 6729256C *.80 *.* LISTEN router# Based on the preceding output, this router is currently listening on TCP port 80 (HTTP), is hosting an established Telnet connection on TCP port 23, and has a TACACS+ connection to a AAA/TACACS+ server on TCP port 49. show cef not-cef-switched router#show cef not-cef-switched CEF Packets passed on to next switching layer Slot No_adj No_encap Unsupp'ted Redirect Receive Options Access Frag RP 3 0 0 18 1055618 0 0 0 IPv6 CEF Packets passed on to next switching layer Slot No_adj No_encap Unsupp'ted Redirect Receive Options Access MTU RP 0 0 24581 0 1 2 0 0 router# In the preceding output, the display indicates the number of packets that have bypassed the CEF switching layer (and the reasons for the bypasses). show ip traffic router#show ip traffic
IP statistics:
Rcvd: 12179889 total, 2212014 local destination
0 format errors, 0 checksum errors, 20 bad hop count
0 unknown protocol, 96 not a gateway
0 security failures, 0 bad options, 0 with options
Opts: 0 end, 0 nop, 0 basic security, 0 loose source route
0 timestamp, 0 extended security, 0 record route
0 stream ID, 0 strict source route, 0 alert, 0 cipso, 0 ump
0 other
Frags: 0 reassembled, 0 timeouts, 0 couldn't reassemble
0 fragmented, 0 fragments, 0 couldn't fragment
Bcast: 158009 received, 0 sent
Mcast: 1156989 received, 1502104 sent
Sent: 3034933 generated, 9967135 forwarded
Drop: 27 encapsulation failed, 0 unresolved, 0 no adjacency
600 no route, 0 unicast RPF, 0 forced drop
0 options denied
Drop: 0 packets with source IP address zero
Drop: 0 packets with internal loop back IP address
ICMP statistics:
Rcvd: 0 format errors, 0 checksum errors, 0 redirects, 604457 unreachable
632 echo, 88 echo reply, 0 mask requests, 0 mask replies, 0 quench
0 parameter, 0 timestamp, 0 timestamp replies, 0 info request, 0 other
0 irdp solicitations, 0 irdp advertisements
Sent: 18 redirects, 54 unreachable, 120 echo, 632 echo reply
0 mask requests, 0 mask replies, 0 quench, 0 timestamp, 0 timestamp replies
0 info reply, 20 time exceeded, 0 parameter problem
0 irdp solicitations, 0 irdp advertisements
TCP statistics:
Rcvd: 21699 total, 0 checksum errors, 2 no port
Sent: 18630 total
BGP statistics:
Rcvd: 0 total, 0 opens, 0 notifications, 0 updates
0 keepalives, 0 route-refresh, 0 unrecognized
Sent: 0 total, 0 opens, 0 notifications, 0 updates
0 keepalives, 0 route-refresh
-------------- Output Truncated --------------
The key item of note in the preceding output is the types of IP packets that are being seen by this IOS device. In the preceding example, it is noted that this device is passing IP, ICMP, TCP, and BGP packets. show ip protocols router#show ip protocols
Routing Protocol is "eigrp 1"
Outgoing update filter list for all interfaces is not set
Incoming update filter list for all interfaces is not set
Default networks flagged in outgoing updates
Default networks accepted from incoming updates
EIGRP metric weight K1=1, K2=0, K3=1, K4=0, K5=0
EIGRP maximum hopcount 100
EIGRP maximum metric variance 1
Redistributing: eigrp 1
EIGRP NSF-aware route hold timer is 240s
Automatic network summarization is in effect
Automatic address summarization:
192.168.208.0/24 for Loopback0, GigabitEthernet0/1
192.168.206.0/24 for Loopback0
192.168.128.0/24 for GigabitEthernet0/1
Summarizing with metric 128256
Maximum path: 4
Routing for Networks:
192.168.0.0/16
Passive Interface(s):
GigabitEthernet0/0
Routing Information Sources:
Gateway Distance Last Update
(this router) 90 1w2d
Distance: internal 90 external 170
Routing Protocol is "ospf 1"
Outgoing update filter list for all interfaces is not set
Incoming update filter list for all interfaces is not set
Router ID 192.168.128.20
It is an autonomous system boundary router
Redistributing External Routes from,
static with metric mapped to 1000, includes subnets in redistribution
Number of areas in this router is 1. 1 normal 0 stub 0 nssa
Maximum path: 4
Routing for Networks:
192.168.0.0 0.0.255.255 area 0
Reference bandwidth unit is 100 mbps
Routing Information Sources:
Gateway Distance Last Update
192.168.208.253 110 1w3d
192.168.208.254 110 3d17h
10.9.66.202 110 3d17h
192.168.206.40 110 3d17h
192.168.135.10 110 3d17h
192.168.128.2 110 3d17h
Gateway Distance Last Update
192.168.128.3 110 3d17h
192.168.128.4 110 3d17h
192.168.128.21 110 3d17h
192.168.128.22 110 3d17h
192.168.128.23 110 3d17h
Distance: (default is 110)
router#
In the preceding example, the output displayed indicates that there is a process of EIGRP (eigrp 1) and of OSPF (ospf 1) running on this IOS device. Develop CPPr ConfigurationAfter most, if not all, of the traffic that is transiting the enterprise network has been identified, administrators can use categories that are associated with the CPPr subinterfaces to further classify the traffic into "traffic compartments." Host Subinterface Categories The host subinterface categories are used for traffic that is destined to the IP address space of the IOS device on which CPPr is configured.
Create the ACLsThe following ACLs are examples based on the categories of traffic in the preceding descriptions: iBGP loopback space = 192.168.0.0/24 eBGP peer = 10.1.1.1 eBGP peering address = 10.1.1.2 core address space = 192.168.100.0/24 AAA server = 192.168.200.1 NMS address space = 192.168.10.0/24 ip access-list extended known-undesirable-acl permit tcp any any fragments permit udp any any fragments permit icmp any any fragments permit ip any any fragments permit udp any any eq 1434 ip access-list extended critical-acl ! iBGP peers permit tcp 192.168.0.0 0.0.0.255 gt 1024 192.168.0.0 0.0.0.255 eq bgp permit tcp 192.168.0.0 0.0.0.255 eq bgp 192.168.0.0 0.0.0.255 gt 1024 ip access-list extended important-acl Create the Class Maps The following class maps are based on the preceding ACLs: class-map match-all CPPr-host-known-undesirable
match access-group name known-undesirable-acl
class-map match-all CPPr-host-critical
match access-group name critical-acl
class-map match-all CPPr-host-important
match access-group name important-acl
class-map match-any CPPr-host-normal
match access-group name normal-acl
class-map match-any CPPr-host-reactive-undesirable
match access-group name reactive-undesirable-acl
class-map match-any CPPr-host-catch-all
match access-group name catch-all-acl
Create the Policy Map The CPPr host policy map is then created using the class maps shown above: policy-map CPPr-host class CPPr-host-known-undesirable drop class CPPr-host-critical ! no operation specified – no rate-limit class CPPr-host-important police <rate> conform-action transmit exceed-action drop class CPPr-host-normal police <rate> conform-action transmit exceed-action drop class CPPr-host-reactive-undesirable drop class CPPr-host-catch-all police <rate> conform-action transmit exceed-action drop Apply the Policy Map to the CPPr Host Subinterface router-01(config)#control-plane host router-01(config-cp-host)#service-policy input CPPr-host router-01(config-cp-host)#exit router-01(config)#^Z Transit and CEF-Exception Subinterface Categories The transit and CEF-exception categories are used for traffic that is destined to devices beyond the IOS device on which CPPr is configured:
Create the ACLs The following ACLs are examples based on the categories of traffic in the preceding descriptions: ip access-list extended known-undesirable-acl
permit tcp any any fragments
permit udp any any fragments
permit icmp any any fragments
permit ip any any fragments
permit udp any any eq 1434
ip access-list extended cef-critical-acl
Create the Class Maps The following class maps are based on the preceding ACLs: !Transit subinterface class-map
class-map match-all CPPr-transit-known-undesirable
match access-group name known-undesirable-acl
class-map match-any CPPr-transit-normal
match access-group name normal-acl
class-map match-any CPPr-transit-reactive-undesirable
match access-group name reactive-undesirable-acl
class-map match-any CPPr-transit-catch-all
match access-group name catch-all-acl
!CEF-exception subinterface class-map
class-map match-all CPPr-cef-exception-known-undesirable
match access-group name known-undesirable-acl
class-map match-all CPPr-cef-exception-critical
Create the Policy Maps The CPPr transit policy map is then created using the class maps shown above: !Transit subinterface policy-map policy-map CPPr-transit class CPPr-transit-known-undesirable drop class CPPr-transit-normal police <rate> conform-action transmit exceed-action drop class CPPr-transit-reactive-undesirable drop class CPPr-transit-catch-all police <rate> conform-action transmit exceed-action drop The CPPr CEF-exception policy map is then created using the class maps shown above: !CEF-exception subinterface policy-map policy-map CPPr-cef-exception class CPPr-cef-exceptionknown-undesirable drop Apply the Policy Map to the CPPr Transit Subinterface router-01(config)#control-plane transit router-01(config-cp-host)#service-policy input CPPr-transit router-01(config-cp-host)#exit router-01(config)#^Z Apply the Policy Map to the CPPr CEF-Exception Subinterface router-01(config)#control-plane cef-exception router-01(config-cp-host)#service-policy input CPPr-cef-exception router-01(config-cp-host)#exit router-01(config)#^Z Policy TuningAfter the CPPr policy has been deployed, it is necessary to actively monitor it to determine the types and amounts of traffic that are being categorized into each of the CPPr subinterfaces. At this point, no traffic is being actively dropped as a result of CPPr policies, but the information gathered when reviewing the ACLs and the CPPr policy statistics will be used to start tuning the CPPr configuration order to (1) drop undesirable traffic that is being passed to the route processor/CPU, (2) allow traffic that would have been dropped by the CPPr policies (after dropping is configured), and/or (3) modify rate limits on traffic that is currently being policed by CPPr.
router#show policy-map control-plane ? all Show all control plane policies cef-exception Cef-exception subinterface host Host subinterface input Input policy output Output policy transit Transit subinterface | Output modifiers <cr> The following example of output for show policy-map control-plane is focused solely on the control plane host subinterface and displays both the policy map statistics applied to the CPPr host subinterface as well as the hits to the respective ACL entries. router#show policy-map control-plane host
Control Plane Host
Service-policy input: CPPr-host
Class-map: CPPr-host-known-undesirable (match-all)
0 packets, 0 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: access-group name known-undesirable-acl
drop
Class-map: CPPr-host-critical (match-all)
0 packets, 0 bytes
5 minute offered rate 0 bps
Match: access-group name critical-acl
Class-map: CPPr-host-important (match-all)
0 packets, 0 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: access-group name important-acl
police:
cir 8000 bps, bc 1500 bytes
conformed 0 packets, 0 bytes; actions:
transmit
exceeded 0 packets, 0 bytes; actions:
drop
conformed 0 bps, exceed 0 bps
Class-map: CPPr-host-normal (match-any)
4 packets, 562 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: access-group name normal-acl
4 packets, 562 bytes
5 minute rate 0 bps
police:
cir 8000 bps, bc 1500 bytes
conformed 0 packets, 0 bytes; actions:
transmit
exceeded 0 packets, 0 bytes; actions:
drop
conformed 0 bps, exceed 0 bps
Class-map: CPPr-host-reactive-undesirable (match-any)
0 packets, 0 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: access-group name reactive-undesirable-acl
0 packets, 0 bytes
5 minute rate 0 bps
drop
Class-map: CPPr-host-catch-all (match-any)
209 packets, 12543 bytes
5 minute offered rate 1000 bps, drop rate 0 bps
Match: access-group name catch-all-acl
209 packets, 12543 bytes
5 minute rate 1000 bps
police:
cir 8000 bps, bc 1500 bytes
conformed 0 packets, 0 bytes; actions:
transmit
exceeded 0 packets, 0 bytes; actions:
drop
conformed 0 bps, exceed 0 bps
Class-map: class-default (match-any)
0 packets, 0 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: any
router#
In the preceding output, four packets matched the CPPr-host-normal class map and 209 packets matched the CPPr-host-catch-all class map. In addition, the rate of traffic that matched the CPPr-host-catch-all class map was 1000 bps. Monitoring these rate limits can be useful when determining the required rates to be configured for each of the respective classes. The following example shows output for show access-lists ACL-name: router#show access-lists catch-all-acl
Extended IP access list catch-all-acl
10 permit tcp any any (209 matches)
20 permit udp any any
30 permit icmp any any
40 permit ip any any
router#show access-lists normal-acl
Extended IP access list normal-acl
10 permit icmp any any ttl-exceeded
20 permit icmp any any port-unreachable (4 matches)
30 permit icmp any any echo-reply
40 permit icmp any any echo
50 permit icmp any any packet-too-big
router#
In the preceding output, the catch-all-acl ACL matched 209 packets (which corresponds to the packets that were matched in the CPPr-host-catch-all class map) and the normal-acl ACL matched four packets (which corresponds to the packets matched in the CPPr-host-normal class map). ConclusionAlthough CPPr provides tremendous value in governing traffic that is destined to the control plane subinterfaces of the route processor, customers need to be aware of the capabilities and limitations that currently exist when deploying this feature. It should be reiterated that testing of CPPr configurations should be performed in controlled lab environments prior to deploying these configurations in a production setting. ReferencesControl Plane Protection NetFlow Home Page This document is part of the Cisco Security Intelligence Operations. This document is provided on an "as is" basis and does not imply any kind of guarantee or warranty, including the warranties of merchantability or fitness for a particular use. Your use of the information on the document or materials linked from the document is at your own risk. Cisco reserves the right to change or update this document at any time.
|
