Understanding Control Plane Protection

Overview

Starting 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:

  • The port-filtering feature provides for policing/dropping of packets going to closed or nonlistening TCP/UDP ports
  • Queue thresholding limits the number of packets for a specified protocol that will be allowed in the control plane IP input queue

Control Plane Interface and Subinterfaces

The 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

 

Description CoPP CPPr
Levels of control plane filtering available One: aggregate Three: subinterfaces (host, transit, CEF-exception)
Support for Distributed or Hardware Switching Platforms Yes No
CEF required No Yes
Provides a mechanism for dropping packets that are directed to closed or nonlistening TCP/UDP ports No Yes
Ability to enforce limits on the number of packets for a specified protocol that are allowed in the control plane IP input queue No Yes


Benefits of CPPr

Control 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:

  • High CPU utilization
  • Loss of keepalives and routing protocol updates
  • Slow or unresponsive interactive management sessions
  • Depletion of memory and/or buffer resources

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:

  • Protection against DoS attacks of network infrastructure by providing a mechanism for finer granularity for policing of control plane traffic and by providing the ability to rate limit each type of traffic (that is, host, transit, and CEF-exception) individually.
  • A mechanism for early dropping of packets that are directed to closed or nonlistening TCP/UDP ports on a Cisco IOS device.
  • The ability to limit protocol queue usage such that no single protocol flood can overwhelm the input interface of a Cisco IOS device.
  • QoS control for packets that are destined to the control plane of Cisco routers.
  • Ease of configuration for control plane policies using Modular QoS CLI (MQC) Infrastructure.

Caveats When Deploying CPPr

The following restrictions may influence administrators' decisions about deploying Control Plane Protection:

  • Control Plane Protection is restricted to the IPv4 input path only.
  • Access control lists (ACLs) cannot be applied directly to the control plane subinterfaces. Instead, ACLs are used within the MQC policies (that is, class maps) and the service policy is then applied to the individual control plane subinterfaces.
  • Control Plane Protection depends on Cisco Express Forwarding (CEF) for IP packet redirection. If you disable CEF globally, this will remove all active protection and policing policies configured on the control plane subinterfaces. Aggregate control plane interface policies will continue to function normally.
  • Policies applicable on the control plane host subinterface are subject to the following restrictions:
    • The port-filter feature policy supports only TCP/UDP-based protocols.
    • The queue-thresholding feature policy supports the following TCP/UDP-based protocols:
      • bgp—Border Gateway Protocol
      • dns—Domain Name Server lookup
      • ftp—File Transfer Protocol
      • http—Hypertext Transfer Protocol (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 that are not specifically matched or configured 
  • CPPr is currently not supported on distributed or hardware-switching platforms.
  • All IP packets that enter the control plane that match any of the following conditions are not classified any further and are redirected to the CEF-exception subinterface:
    • IP packets with IP options
    • IP packets with TTL less than or equal to 1 (Reference CSCsd32408)
  • Protocols are auto-detected by the port filter: Some Cisco IOS TCP- and UDP-based services, when configured, may not be auto-detected by the port filter; that is, they are not listed under the show control-plane host open-ports output and therefore they are not classified as an open port. This type of port must be manually added to the active port filter class map to be unblocked. The following example shows the output displayed by using the show control-plane host open-ports command:
  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#
  • The following table provides Cisco bug IDs (and the respective TCP/UDP port) filed to request that additional open ports be listed when using the show control-plane host open-ports command. The Cisco bug links require Cisco.com authentication.
  
DDTS Port Number Protocol
CSCsh95471 7/tcp echo
CSCsh95471 7/udp echo
CSCsh95471 9/tcp discard
CSCsh95471 9/udp discard
CSCsh95471 13/tcp daytime
CSCsh95471 13/udp daytime
CSCsh95471 19/tcp chargen
CSCsh95471 19/udp chargen
CSCsh95579 79/tcp finger
CSCsi03962 88/udp Kerberos (outbound)
CSCsi00333 113/tcp ident
CSCsb41573 123/udp NTP
CSCsd58776 496/udp PIM-RP-DISC
CSCsd58776 500/udp IKE
CSCsi00834 514/tcp RSH
CSCsi03978 514/udp syslog (outbound)
CSCsh97032 520/udp RIP
CSCsi00899 521/udp RIPv6
CSCsi03990 546/udp DHCPv6 (client)
CSCsi00816 646/udp LDP
CSCsi00816 711/udp TDP
CSCsd58776 848/udp GDOI
CSCsh97035 1698/udp RSVP
CSCsh95993 1701/udp L2TP
CSCsi00351 1812/udp RADIUS
CSCsi00351 1813/udp RADIUS
CSCsh97064 1985/udp HSRP
CSCsh95985 1987/tcp RSRB
CSCsh95985 1988/tcp RSRB
CSCsh95985 1989/tcp RSRB
CSCsh95985 1996/tcp RSRB
CSCsh95539 2001/tcp 20xx/tcp - Reverse Telnet
CSCsi00882 2029/udp HSRPv6
CSCsh95559 2065/tcp DLSw
CSCsh95559 2067/tcp DLSw
CSCsh97054 2427/udp MGCP
CSCsh95539 3001/tcp - 30xx/tcp Reverse Telnet
CSCsi00914 3222/udp GLBP
CSCsi00816 3503/udp LSP
CSCse78582 3784/udp BFD
CSCsh95539 4001/tcp - 40xx/tcp Reverse Telnet
CSCsd58776 4500/udp NAT-T
CSCsh95539 5001/tcp - 50xx/tcp Reverse Telnet
CSCsh95594 5060/udp SIP
CSCsh95539 6001/tcp - 60xx/tcp Reverse Telnet
CSCsh95539 7001/tcp - 70xx/tcp Reverse Telnet
CSCsh95539 9001/tcp - 90xx/tcp Reverse Telnet
CSCsh95539 10001/tcp - 100xx/tcp Reverse Telnet
CSCsh95981 21862/udp EAPoUDP

 

Interactions

There 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.

  • Cisco Express Forwarding: CPPr requires Cisco Express Forwarding (CEF). If CEF is not enabled, policies applied to the control plane subinterfaces will not be effective. However, CoPP policies applied directly to the control plane interface will be effective.
  • Router and VLAN access control lists: In most cases, router access control lists (RACLs) that have been applied to ingress Layer 3 interfaces, as well as VLAN access control lists (VACLs) on the ingress VLAN, will be processed before a received IP packet will be processed by CPPr.
  • Unicast Reverse Path Forwarding: When applied to the ingress Layer 3 interface, source address validation via Unicast Reverse Path Forwarding (Unicast RPF) will be completed before CPPr will be processed.
  • Receive access control lists: On supported platforms, receive ACLs filter traffic destined to the route processor of a network device. Receive ACLs are checked before CPPr processes a packet.
    Note: There are currently no hardware platform/code combinations that support the use of both receive ACLs and CPPr. More information regarding receive ACLs is available at http://www.cisco.com/warp/public/707/racl.html.
  • Control Plane Policing: Control Plane Policing is a Cisco IOS feature that allows policing of traffic destined to the route processor. A packet will not be checked against the CPPr policy until it has been permitted by all configured forms of CoPP. More information about Control Plane Policing is available at http://www.cisco.com/univercd/cc/td/doc/product/software/ios122s/122snwft/release/122s18/gtrtlimt.htm.
  • Hardware rate limiters: The Policy Feature Card 3 (PFC3) for the Cisco Catalyst 6500 Series switches and Cisco 7600 Series routers with Supervisor Engine 720 or Supervisor Engine 32 includes hardware rate limiters (HWRLs) that apply to certain categories of packets. The processing of HWRLs and hardware CoPP take place in parallel and packets that match a configured HWRL will not be processed by hardware CoPP. However, packets that are permitted by an HWRL will be processed by software CoPP and CPPr.
    Note: There are currently no hardware platform/code combinations that support the use of both HWRLs and CPPr. More information about Hardware Rate Limiting on the PFC3 is available at http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/ios/12.2SXF/native/configuration/guide/dos.html#wp1140842
  • Selective Packet Discard: Select Packet Discard (SPD) provides queuing and basic congestion management of packets destined to the route processor. SPD is used after a packet has been permitted by CPPr. The configurations of SPD and CPPr have no bearing on one another. More information about Selective Packet Discard is available at http://www.cisco.com/en/US/products/hw/routers/ps167/products_tech_note09186a008012fb87.shtml.

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.

 

feature processing order diagram

 

Deployment Methodology

 

Policy Development

Just 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:

  1. Drop packets prior to CPPr using ACLs, Unicast RPF, and additional features (as described in the preceding "Interactions" section)
  2. Identify the necessary protocols and consider initial rate-limiting values based on configurations, NetFlow data, classification ACLs, and show commands (such as show ip traffic and show ip socket)
  3. Develop and pilot a CPPr framework without enforcing rate limits and drops
  4. Refine the policy and adjust rates based on observation
  5. Deploy the policy and enforce rate limits and drops as required

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 CPPr

There 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:

  • Interface ACLs and Unicast RPF: Consider points where interface ACLs and Unicast RPF can be employed.
  • IP Options Handling: Use the ip options drop command (where supported) to prevent IP packets with options from reaching the control plane.
  • ACL Logging: Use of the ip access-list logging interval interval-in-ms command will rate limit ACL logging punts (which will need to be processed by the CPU). This method is particularly effective when logging packets that are denied by an ACL.
  • Unnecessary services: Disable unnecessary services to minimize the number of packets that are punted to the CPU.

Identify Necessary Protocols

Identifying 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:

  • Configuration: Reviewing the configurations of network devices will provide some basic information in terms of the protocols that are being used on the network.
  • NetFlow data: NetFlow is one of the most effective forms of telemetry in identifying the types of traffic that are being seen on the network. NetFlow can be enabled on just about every Cisco IOS device and it can provide granular information about the ports/protocols being used between end hosts on the network. More information about NetFlow is on the NetFlow Home Page.
  • Classification ACLs: A classification ACL is composed of permit statements for the various protocols that could be destined to the internal network. Use the show access-list command to display a count of access control entry (ACE) hits to identify required protocols. Investigate and understand any suspicious or surprising results before you create explicit permit statements for unexpected protocols.
  • Cisco IOS Software commands: The following Cisco IOS commands can also help in the identification of the various types of traffic on the network:
    • show ip socket: Displays the UDP ports and non-TCP IP protocols currently in use (active or listening) by the Cisco IOS device
    • show tcp brief all: Displays the TCP ports currently in use (active or listening) by the Cisco IOS device
    • show cef not-cef-switched: Displays the traffic (in number of packets) that have bypassed the CEF switching path in the Cisco IOS device
    • show ip traffic: Displays a wealth of statistics on the types of IP packets (grouped by protocol, such as IP, ICMP, TCP, and BGP) sent/received by the IOS device
    • show ip protocols: Displays the IP routing protocol process parameters and statistics for the IOS device

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 Configuration

After 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.

  • Known Undesirable: Malicious traffic that is expected yet undesirable (for example, IP fragments, SQL Slammer); this traffic should never reach the route processor/CPU and thus should always be dropped.
  • Critical Traffic: This includes traffic, such as routing protocol traffic (for example, iBGP, EIGRP), that is absolutely necessary and should never be dropped or rate limited.
  • Important Traffic: Management plane traffic (for example, SNMP, SSH, AAA, NTP) that is expected and required to reach the route processor/CPU but may need to be rate limited.
  • Normal Traffic: Includes other expected nonmalicious traffic (for example, ping and other ICMP types: ttl-exceeded, port-unreachable, etc.) that is necessary but should be rate limited.
  • Reactive Undesirable: Used for "exploit of the day" type of traffic; it should be used for reactive handling of potentially malicious traffic (such as vulnerabilities) and should always result in dropping the traffic.
  • Catch-all: Remaining unclassified IP traffic, which should be rate limited.
  • Default: Non-IP traffic, which may need to be rate limited.
Create the ACLs

The 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
permit tcp 192.168.100.0 0.0.0.255 eq 22 any established
permit tcp 192.168.100.0 0.0.0.255 any eq 22
permit tcp host 192.168.200.1 eq tacacs 192.168.0.0 0.0.0.255 established
permit udp 192.168.10.0 0.0.0.255 192.168.0.0 0.0.0.255 eq snmp
ip access-list extended normal-acl
permit icmp any any ttl-exceeded
permit icmp any any port-unreachable
permit icmp any any echo-reply
permit icmp any any echo
permit icmp any any packet-too-big
ip access-list extended reactive-undesirable-acl
permit tcp any any eq 445
ip access-list extended catch-all-acl
permit tcp any any
permit udp any any
permit icmp any any
permit ip any any

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:

  • Known Undesirable: Malicious traffic that is expected yet undesirable (for example, IP fragments, SQL Slammer); this traffic should never reach the internal networks and thus should always be dropped.
  • Critical Traffic: This includes traffic, such as routing protocol traffic (for example, eBGP, OSPF), that is absolutely necessary and should never be dropped or rate limited.
  • Normal Traffic: Includes any traffic that is considered transit traffic and is destined for parts of the network "inside" the IOS device on which CPPr is configured. This would include all the applications that are in use by the organization and, due to the logical location of sources and destinations, need to traverse this IOS device. This traffic should have some loose rate limiting applied. However, until the traffic types and rates are clearly understood, no dropping of this traffic should take place.
  • Reactive Undesirable: Used for the "exploit of the day" type of traffic; it should be used for reactive handling of potentially malicious traffic (such as vulnerabilities) and should always result in dropping the traffic that is destined for the inside networks.
  • Catch-all: Remaining unclassified IP traffic, which may need to be rate limited.
  • Default: Non-IP traffic, which may need to be rate limited.

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
! eBGP peers
permit tcp host 10.1.1.1 gt 1024 host 10.1.1.2 eq bgp
permit tcp host 10.1.1.1 eq bgp host 10.1.1.2 gt 1024
! IGP
permit ospf 192.168.100.0 0.0.0.255 host 224.0.0.5
permit ospf 192.168.100.0 0.0.0.255 host 224.0.0.6
permit ospf 192.168.100.0 0.0.0.255 192.168.100.0 0.0.0.255 ip access-list extended normal-acl permit icmp any any ttl-exceeded permit icmp any any port-unreachable permit icmp any any echo-reply permit icmp any any echo permit icmp any any packet-too-big ip access-list extended reactive-undesirable-acl permit tcp any any eq 445 ip access-list extended catch-all-acl permit tcp any any permit udp any any permit icmp any any permit ip any any

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
match access-group name cef-critical-acl
class-map match-any CPPr-cef-exception-normal match access-group name normal-acl class-map match-any CPPr-cef-exception-reactive-undesirable match access-group name reactive-undesirable-acl class-map match-any CPPr-cef-exception-catch-all match access-group name catch-all-acl

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
class CPPr-cef-exception-critical
! no operation specified – no rate-limit

class CPPr-cef-exception-normal <<<NOTE hyphen here that has obviously been incorrect since Day 1! police <rate> conform-action transmit exceed-action drop class CPPr-cef-exceptionreactive-undesirable
drop
class CPPr-cef-exceptioncatch-all
police <rate> conform-action transmit exceed-action 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 Tuning

After 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.
In addition to the commands highlighted in the "Policy Development" section, there are a number of methods that can be used to monitor the traffic being filtered by CPPr, including the following:

  • The IOS show policy-map control-plane command is invaluable for reviewing and tuning site-specific policies and troubleshooting. The output of this command displays dynamic information about the number of packets (and bytes) conforming to or exceeding each policy definition. As displayed in the following example, this command can be used to show all the control plane policies (both CoPP and all three CPPr subinterface policies) or can be used to display just one specific CPPr subinterface (CEF-exception, host, transit) policy.
  • The show access-list command displays hit counts per ACL entry. Hits will indicate that flows for that data type are reaching the control plane as expected. This command should be used primarily to view the hit counters for the ACLs that are used within the respective CPPr class map policies.
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).

Conclusion

Although 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.

References

Control Plane Protection
http://www.cisco.com/en/US/partner/products/ps6441/products_feature_guide09186a0080556710.html

NetFlow Home Page
http://www.cisco.com/go/netflow


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.

Back to Top

Cisco Security Intelligence Operations