WHITE PAPER
`
`DEPLOYING CONTROL PLANE POLICING
`
`
`This document will provide an overview of Cisco IOS® Control Plane Policing (CPP), as well as deployment recommendations
`and guidelines for this Cisco IOS Security Infrastructure feature. CPP is used to increase security on Cisco routers by
`protecting the Route Processor from unnecessary and often malicious traffic. It allows users to configure a Quality of Service
`(QoS) filter that manages the traffic flow of control plane packets to protect the control plane of Cisco routers and switches
`against reconnaissance and Denial of Service (DoS) attacks allowing the Control Plane (CP) to maintain packet forwarding
`and protocol states despite an attack or heavy load on the router or switch.
`
`PROTECTING THE ROUTE PROCESSOR
`A router can be logically divided into four functional components or planes:
`
`1. Data Plane
`
`2. Management Plane
`
`3. Control Plane
`
`4. Services Plane
`
`The vast majority of traffic travels through the router via the data plane; however, the Route Processor must handle certain packets, such as routing
`updates, keepalives, and network management. This is often referred to as control and management plane traffic.
`
`Because the Route Processor is critical to network operations, any service disruption to the Route Processor or the control and management planes
`can result in business-impacting network outages. A DoS attack targeting the Route Processor, which can be perpetrated either inadvertently or
`maliciously, typically involves high rates of punted traffic that result in excessive CPU utilization on the Route Processor itself. This type of attack,
`which can be devastating to network stability and availability, may display the following symptoms:
`• High Route Processor CPU utilization (near 100%)
`• Loss of line protocol keepalives and routing protocol updates, leading to route flaps and major network transitions
`• Interactive sessions via the Command Line Interface (CLI) are slow or completely unresponsive due to high CPU utilization
`• Route Processor resource exhaustion—resources such as memory and buffers are unavailable for legitimate IP data packets
`• Packet queue backup, which leads to indiscriminate drops (or drops due to lack of buffer resources) of other incoming packets
`
`CPP addresses the need to protect the control and management planes, ensuring routing stability, availability, and packet delivery. It uses a dedicated
`control-plane configuration via the Modular QoS CLI (MQC) to provide filtering and rate limiting capabilities for control plane packets.
`
`Figure 1 illustrates the flow of packets from various interfaces. Packets destined to the control plane are subject to control plane policy checking,
`as depicted by the control plane services block.
`
`
`All contents are Copyright © 1992–2005 Cisco Systems, Inc. All rights reserved. Important Notices and Privacy Statement.
`Page 1 of 23
`
`
`
`Exhibit 2022
`IPR2016-00309
`
`

`
`
`
`Figure 1. Packet Flow
`
`
`
`COMMAND SYNTAX
`CPP 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 CP service policies to be attached to control
`plane itself.
`
`There are four steps required to configure CPP:
`
`1. Define a packet classification criteria
`
`router(config)#class-map <traffic_class_name>
`
`router(config-cmap)#match <access-group | protocol* | ip prec | ip dscp>
`
`
`
`2. Define a service policy
`
`router(config)#policy-map <service_policy_name>
`
`router(config-pmap)#class <traffic_class_name>
`
`router(config-pmap-c)# police <cir | rate> conform-action <transmit | drop > exceed-action <transmit
`
`| drop>
`
`cir
`
`rate
`
`
`
`Committed information rate (Bits per second)
`
`Specify policy rate in packets per second (pps)
`
`3. Enter control-plane configuration mode
`
`router(config)#control-plane
`
` *
`
` When using the ‘match protocol’ classification criteria, ARP is the only protocol supported. All other protocols need an ACE entry for classification purposes.
`
`
`© 2005 Cisco Systems, Inc. All rights reserved.
`Important notices, privacy statements, and trademarks of Cisco Systems, Inc. can be found on cisco.com.
`Page 2 of 19
`
`
`
`

`
`
`
`4. Apply QoS policy
`
`service-policy
`
`{input | output} <service_policy_name>
`
`input
`
`output**
`
`
`
`Assign policy-map to the input of an interface
`
`Assign policy-map to the output of an interface
`
`COMMAND REFERENCES
`Please refer to the following links for more information on the control plane policing and QoS command syntax.
`
`Control Plane Policing: http://www.cisco.com/en/US/products/sw/iosswrel/ps1838/products_feature_guide09186a00801afad4.html#1027184
`
`QoS Command Reference: http://www.cisco.com/en/US/products/sw/iosswrel/ps5207/products_command_reference_book09186a00801a7ec7.html
`
`CISCO HARDWARE AND CISCO IOS SOFTWARE SUPPORT
`Refer to Table 1 for Cisco hardware and Cisco IOS Software support.
`
`Table 1. Cisco Hardware and Cisco IOS Software Support
`
`Cisco Hardware
`Cisco 12000 Series Router
`
`Cisco IOS Software Release
`Release 12.0(29)S
`
`Cisco 7600 Series
`
`Cisco 6500 Series
`
`Cisco 7200 Series
`
`Cisco 7500 Series
`
`Cisco 1751 Router
`
`Cisco 2600/2600-XM Series
`
`Release 12.2(18)SXD1
`
`Release 12.2(18)SXD1
`
`Release 12.2(18)S
`
`Release 12.3(4)T
`
`Cisco 3700 Series
`
`Cisco 7200 Series
`
`Cisco 1800 Series
`
`Cisco 2800 Series
`
`Cisco 3800 Series
`
`
`
`Release 12.3(8)T
`
`Release 12.3(11)T
`
`DEVELOPING A CPP POLICY
`Since CPP filters traffic destined to the Route Processor, it is critical to gain an adequate level of understanding about the legitimate traffic destined
`for the Route Processor prior to deployment. Configuring CPP policies without this knowledge may result in the blockage of critical traffic, with
`the potential for unintentionally provoking a DoS attack. In some networks, determining the exact traffic profile required for CPP policies might
`be difficult, so a careful staged approach should be taken to define these policies. Refer to the Deployment Guidelines section of this document
`for a recommended conservative methodology for deploying CPP using iterative ACL configurations to help identify and filter traffic.
`
`
`** Although MQC can be leveraged to support outbound policies, this document focuses solely on input CPP since input CPP provides the most effective protection
`scenario. Output CPP is mainly used to suppress responses to input packets and does not limit response generation.
`
`
`
`
`© 2005 Cisco Systems, Inc. All rights reserved.
`Important notices, privacy statements, and trademarks of Cisco Systems, Inc. can be found on cisco.com.
`Page 3 of 19
`
`
`
`

`
`
`
`Traffic Classification
`Prior to developing the actual CPP policy, administrators must identify required traffic and separate it into different classes. Multiple classification
`schemes can be used, but Cisco recommends a methodology that involves dividing traffic into distinct groups based on relative importance.
`
`The following example uses nine different classes of traffic, thus providing a granular level of detail for real-world environments. Use this as a
`reference; however, note that the actual number and type of classes needed for a network may differ and should be selected based on local
`requirements, security policies, and a thorough analysis of the baseline traffic of the customer.
`
`The nine traffic classes in this example were created with the following criteria:
`
`1. Border Gateway Protocol (BGP)
`• Traffic that is crucial to maintaining neighbor relationships for BGP routing protocol
`• Examples: BGP keepalives and routing updates
`• Maintaining BGP routing protocol is crucial to maintaining connectivity within a network or to a Service Provider
`• Sites that do not run BGP will not need to use this class
`
`2.
`Interior Gateway Protocol (IGP)
`• Traffic that is crucial to maintaining IGP routing protocols
`• Examples: Open Shortest Path First (OSPF), Enhanced Interior Gateway Routing Protocol (EIGRP), and Routing Information Protocol (RIP)
`• Maintaining IGP routing protocols is crucial to maintaining connectivity within a network
`
`3. Management
`• Necessary, frequently used traffic that is required during day-to-day operations
`• Examples: traffic used for remote network access, Cisco IOS Image upgrades and management (ie: telnet, Secure Shell (SSH), Network Time
`Protocol (NTP), Simple Network Management Protocol (SNMP), Terminal Access Controller Access Control System (TACACS), Hypertext
`Transfer Protocol (HTTP), Trivial File Transfer Protocol (TFTP), and File Transfer Protocol (FTP)
`
`
`4. Reporting
`• Traffic used for generating network performance statistics for reporting
`• Example: using Cisco IOS IP Service Level Agreements (SLAs) to generate ICMP with different DSCP settings in order to report on response
`times within different QoS data classes
`
`
`5. Monitoring
`• Traffic used for monitoring a router
`• Traffic should be permitted but should never pose a risk to the router; with CPP, this traffic can be permitted but limited to a low rate
`• Examples: ICMP echo request (ping), and traceroute
`
`6. Critical Applications
`• Critical application traffic that is specific and crucial to a particular customer environment
`• Traffic included in this class should be tailored specifically to the required application requirements of the user (ie: one customer may use
`multicast, while another uses IPSec and/or Generic Routing Encapsulation [GRE])
`• Examples: GRE, Hot Standby Router Protocol (HSRP), Virtual Router Redundancy Protocol (VRRP), Session Initiation Protocol (SIP), Data
`Link Switching (DLSw), Dynamic Host Configuration Protocol (DHCP), Multicast Source Discovery Protocol (MSDP), Internet Group
`Management Protocol (IGMP), Protocol Independent Multicast (PIM), Multicast Traffic, and IPSec
`
`
`
`
`© 2005 Cisco Systems, Inc. All rights reserved.
`Important notices, privacy statements, and trademarks of Cisco Systems, Inc. can be found on cisco.com.
`Page 4 of 19
`
`
`
`

`
`
`
`7. Layer 2 Protocols
`• Traffic used for Address Resolution Protocol (ARP)
`• Excessive ARP packets can potentially monopolize Route Processor resources, starving other important processes; CPP can be used to rate limit
`ARP packets to prevent this
`• Currently, ARP is the only Layer 2 protocol that can be specifically classified using the “match protocol” classification criteria
`
`8. Undesirable
`• Explicitly identifies “bad” or malicious traffic that should be unconditionally dropped and denied access to the Route Processor
`• Particularly useful when known traffic destined for the router should always be denied and not placed into a default category; explicitly denying
`traffic allows the end-user to collect rough statistics on this traffic via show commands and offers some insight into the rate of denied traffic
`
`
`9. Default
`• All remaining traffic destined for the Route Processor that has not been identified
`• MQC provides the default class, so the user can specify the treatment to be metered out to traffic not explicitly identified in the other user defined
`classes
`• Give this traffic access to the Route Processor at a highly reduced rate
`• With a default classification in place, statistics can be monitored to determine the rate of otherwise unidentified traffic destined to the control-
`plane. Once this traffic is identified, further analysis can be performed to classify it and if needed, the other CPP policy entries can be updated
`to account for this traffic
`
`Classification Access Lists
`Using the classification scheme defined in the previous section, commonly required traffic is identified with a series of Access Control Lists (ACLs).
`This example uses extended-named ACLs, which are recommended because of their flexibility in allowing the targeted removal and insertion of
`actions within the ACL. This enables classification ACLs to be updated without completely removing and re-adding them. Named ACLs can also
`be named using descriptive names to indicate their use.
`
`In this example, the following named classification ACLs are used to classify the traffic into the recommended classes:
`• coppacl-bgp: BGP traffic
`• coppacl-igp: IGP traffic
`• coppacl-management: management traffic
`• coppacl-reporting: reporting traffic
`• coppacl-monitoring: monitoring traffic
`• copp acl-critical-app: critical application traffic
`• coppacl-layer2: ARP traffic
`• coppacl-undesirable: explicitly denies unwanted traffic (i.e. slammer worm in this example)
`
`The ACLs will be used to build classes of traffic that are used to define the service policies.
`
`Note: As CPP policies are applied to the control plane interface, only traffic destined for the Route Processor will be affected by the CPP policy.
`The destination key word ‘any’ can be used to classify all traffic destined to any interface on the router. The router can be further secured by
`specifying exact destination IP addresses, which limits the number of specific interfaces that can receive certain protocols.
`
`
`© 2005 Cisco Systems, Inc. All rights reserved.
`Important notices, privacy statements, and trademarks of Cisco Systems, Inc. can be found on cisco.com.
`Page 5 of 19
`
`
`
`

`
`
`
`In this example, the following named classification ACLs were created for CPP classification:
`
`In this network, BGP is used and must be classified. This ACL only classifies traffic destined to the IP address of 10.9.9.9.
`
`ip access-list extended coppacl-bgp
`
` remark CoPP BGP traffic class
`
`! allow BGP from a known peer to this router’s BGP TCP port
`
` permit tcp host 47.1.1.1 host 10.9.9.9 eq bgp
`
`! allow BGP from a peer’s BGP port to this router
`
` permit tcp host 47.1.1.1 eq bgp host 10.9.9.9
`
` permit tcp host 10.86.183.120 host 10.9.9.9 eq bgp
`
` permit tcp host 10.86.183.120 eq bgp host 10.9.9.9
`
`
`
`For the IGP class, OSPF is the IGP used in this example.
`
`ip access-list extended coppacl-igp
`
` remark CoPP IGP traffic class
`
`! permit OSPF
`
` permit ospf any host 224.0.0.5
`
` permit ospf any host 224.0.0.6
`
` permit ospf any any
`
`
`
`The Management class is for traffic that is required for accessing and managing the router. In this example, TACACS, ssh, telnet, snmp, ntp and FTP
`(for IOS upgrades) is classified in this class.
`
`ip access-list extended coppacl-management
`
` remark CoPP management traffic class
`
`! permit return traffic from TACACS host
`
`permit tcp host 1.1.1.1 host 10.1.1.1 established
`
`! permit ssh access to the router from a specific subnet
`
`permit tcp 10.86.183.0 0.0.0.255 any eq 22
`
`! permit telnet access to the router from a specific subnet
`
`permit tcp 10.86.183.0 0.0.0.255 any eq telnet
`
`! permit SNMP access from the NMS host to the router
`
`permit udp host 1.1.1.2 any eq snmp
`
`
`
`Allow the router to receive NTP packets from a known clock source.
`
`permit udp host 1.1.1.3 any eq ntp
`
`! Permit FTP from a specific host for IOS upgrades.
`
`permit tcp host 10.9.9.9 eq ftp host 1.1.1.1
`
`permit tcp host 10.9.9.9 eq ftp-data host 1.1.1.1
`
`
`
`The reporting class is for traffic used for generating network performance statistics. In this example, we are using SAA to generate ICMP Pings
`with different DSCP bits in order to determine response times for different classes of traffic. i.e. COS1 will use an ICMP with DSCP set to EF,
`
`
`© 2005 Cisco Systems, Inc. All rights reserved.
`Important notices, privacy statements, and trademarks of Cisco Systems, Inc. can be found on cisco.com.
`Page 6 of 19
`
`
`
`

`
`
`
`COS2=AF31, COS3=AF21 and COS4=BE. We will create an ACL to classify ICMP pings from specific source routers using SAA to generate
`the ICMPs. We will then use this ACL and the ‘match ip dscp’ classification criteria in the service policy to create the reporting class.
`
`ip access-list extended coppacl-reporting
`
` remark CoPP reporting traffic class
`
`! permit SAA generated ICMP requests from SAA source router
`
`permit icmp host 10.4.4.4 host 10.1.1.1 echo
`
`
`
`The monitoring class is used for traffic that is required for monitoring the router. Monitoring traffic is traffic that we expect to see destined to the
`router and want to track and limit.
`
`ip access-list extended coppacl-monitoring
`
` remark CoPP monitoring traffic class
`
`! permit router originated traceroute
`
`permit icmp any any ttl-exceeded
`
`permit icmp any any port-unreachable
`
`! permit receipt of responses to router originated pings
`
`permit icmp any any echo-reply
`
`! allow pings to router
`
`permit icmp any any echo
`
`
`
`The critical-app class is used for traffic that is crucial to a specific customer’s environment. In this example, HSRP and DHCP is used.
`
`ip access-list extended coppacl-critical-app
`
` remark CoPP critical apps traffic class
`
`! permit HSRP
`
`permit ip any host 224.0.0.2
`
`! permit DHCP requests
`
`permit udp host 0.0.0.0 host 255.255.255.255 eq bootps
`
`! permit DHCP replies from DHCP server
`
`permit udp host 10.8.8.8 eq bootps any eq bootps
`
`
`
`This ACL identifies traffic that should always be blocked from accessing the Route Processor. Once undesirable traffic flow is identified, an ACE
`entry classifying it can be added and mapped to the undesirable traffic class. This can be used as a reaction tool.
`
`ip access-list extended coppacl-undesirable
`
` remark explicitly defined "undesirable" traffic
`
`! permit, for policing, all traffic destined to UDP 1434
`
`permit udp any any eq 1434
`
`
`
`Note: The coppacl-undesirable ACL is a “permit” entry for classification and monitoring purposes, this traffic will be dropped as a result of the
`CPP policy.
`
`
`© 2005 Cisco Systems, Inc. All rights reserved.
`Important notices, privacy statements, and trademarks of Cisco Systems, Inc. can be found on cisco.com.
`Page 7 of 19
`
`
`
`

`
`
`
`CPP Policy and MQC
`MQC provides a flexible interface for creating service policies. In this configuration, traffic can be identified via the class-map and will be dropped
`or permitted access to the Route Processor. Using “transmit/drop”, only configuration is analogous to a receive ACL (rACL)*** deployment and
`when properly deployed provides good protection against many attacks.
`
`MQC also permits multiple match criteria within a class-map. The router needs to determine how packets are evaluated when multiple match criteria
`exists within a single class. Packets must either meet all of the specified match criteria (match-all) or any one of the match criteria (match-
`any) in order to be considered a member of the class. Traffic destined to the undesirable class should follow a “match-any” classification scheme,
`traffic that has any of the match criteria specified in this class may be dropped.
`
`The following example shows a typical CPP policy that contains only transmit and drop actions:
`
`The following example shows how to use class-maps to define a class for each “type” of traffic and associate it with an ACL or appropriate match
`criteria:
`
`class-map match-all coppclass-bgp
`
` match access-group name coppacl-bgp
`
`class-map match-all coppclass-igp
`
` match access-group name coppacl-igp
`
`class-map match-all coppclass-management
`
` match access-group name coppacl-management
`
`
`
`Create a class for packets that match icmp traffic classified by the reporting acl and that are marked with dscp bits of ef, af31, af21 or be.
`
`class-map match-all coppclass-reporting
`
` match access-group name coppacl-reporting
`
` match ip dscp ef af31 af21 default
`
`class-map match-all coppclass-monitoring
`
` match access-group name coppacl-monitoring
`
`class-map match-all coppclass-critical-app
`
` match access-group name coppacl-critical-app
`
`class-map match-all coppclass-layer2
`
` match protocol arp
`
`class-map match-all coppclass-undesirable
`
` match access-group name coppacl-undesirable
`
`
`
`*** For more information regarding rACLs, please visit: http://www.cisco.com/en/US/tech/tk648/tk361/technologies_white_paper09186a00801a0a5e.shtml
`
`
`
`© 2005 Cisco Systems, Inc. All rights reserved.
`Important notices, privacy statements, and trademarks of Cisco Systems, Inc. can be found on cisco.com.
`Page 8 of 19
`
`
`
`

`
`
`
`The following example illustrates the configuration of the actual CPP service policy. In this base case, all actions are transmit actions. The only
`exception is for traffic defined as undesirable, which is unconditionally dropped, regardless of rate and the default class that is rate limited above the
`specified packets per second (PPS) rate. Configuring the CPP policy using only transmit actions initially without the drop action allows the ability to
`monitor the classes under normal operating conditions in order to determine the appropriate rate limit. Once the appropriate rate under normal
`conditions is determined, this information can be used to tighten the policy down by dropping packets that exceed the normal operation rates.
`
`Note: The CPP action allows the ability to configure rate limits based on bits-per-second (BPS) or PPS. Rate-limiting at a PPS rate is better
`as the packet size varies on the network. Understanding the baseline of a network from a PPS perspective is important as well as the bandwidth
`requirement in BPS.
`
`
`
`policy-map copp-policy
`
` class coppclass-bgp
`
` < no operation specified since this class has unrestricted access to route processor >
`
` class coppclass-igp
`
` < no operation specified since this class has unrestricted access to route processor >
`
` class coppclass-management
`
` police rate 100 pps conform-action transmit exceed-action transmit
`
` class coppclass-reporting
`
` police rate 30 pps conform-action transmit exceed-action transmit
`
` class coppclass-monitoring
`
` police rate 50 pps conform-action transmit exceed-action transmit
`
` class coppclass-critical-app
`
` police rate 75 pps conform-action transmit exceed-action transmit
`
` class coppclass-layer2
`
` police rate 20 pps conform-action transmit exceed-action transmit
`
`
`
`This policy drops all traffic categorized as undesirable, regardless of rate. The drop command is currently supported only in T train from 12.2(13)T,
`S train users can use the police statement.
`
` class coppclass-undesirable
`
` police rate 10 pps conform-action drop exceed-action drop
`
` <or>
`
` drop
`
`
`
`The default class applies to all traffic received by the control plane that has not been otherwise identified. In this example, all default traffic is
`limited to 10 pps and violations of that limit are dropped.
`
` class class-default
`
` police rate 10 pps conform-action transmit exceed-action drop
`
`
`
`Because deploying a policy that permits only required traffic is generally the least complicated option, many administrators will initially configure
`their network in this manner. In many cases, a simple permit or deny decision will not suffice because it provides only limited flexibility for
`protecting the Route Processor from those packets that must be allowed with certain restrictions. An example is Internet Control Message Protocol
`(ICMP) echo-request (pings), which are typically allowed for simple diagnostic purposes. A high enough PPS rate of ping can present a risk, the
`
`© 2005 Cisco Systems, Inc. All rights reserved.
`Important notices, privacy statements, and trademarks of Cisco Systems, Inc. can be found on cisco.com.
`Page 9 of 19
`
`
`
`

`
`
`
`router must process and generate a reply to each packet. MQC extends the permit/deny model, so echo-request packets can be permitted, but the rate
`at which those packets are transmitted to the Route Processor is limited. The CPP policy has evolved to the point where traffic can be permitted,
`denied, or rate limited.
`
`Although rate limiting punted traffic is recommended, care must be taken to ensure that the administrator understands the required rates of traffic,
`particularly for critical traffic. A very low rate might discard or drop necessary traffic, whereas a very high rate might inundate the Route Processor
`with a flood of non-critical packets to process. These rates are typically site-specific and vary depending on local topology and routing table size.
`
`Hybrid configurations enable users to deploy a CPP policy that protects the router, while limiting the risk of dropping critical traffic. In a hybrid
`deployment, some traffic—from known sources and often to specific destinations—is permitted without rate limiting; conversely, different, less
`critical traffic is policed. The policed rate depends on both determined criticality and site-specific rate values. For instance, the “normal” rate of
`SNMP will differ based on environment. Using the aforementioned classification scheme with a hybrid deployment, BGP and IGP traffic are both
`permitted without limitation, while management, reporting, monitoring, critical application, and Layer 2 and default traffic are permitted with
`appropriate rate limiting. This deployment causes the network to drop undesirable traffic immediately. A hybrid deployment depends on traffic
`profiling. Using the scheme defined in the previous section, a hybrid configuration involves determining what traffic should pass with a permit
`statement and how much of that traffic can be permitted (ie: what rate should be allowed). Table 2 extends this example and summarizes a sample
`policy.
`
`Note: The rates defined in Table 2 are used for illustrative purposes; every environment will have different baselines. For example, a large
`Service Provider topology will likely require a higher rate of BGP traffic, than a typical enterprise network, due to large BGP routing tables.
`
`The purpose of defining the BGP or IGP traffic class is not to rate limit, but to tag this traffic as BGP or IGP traffic and provide it with unconditional
`access to the Route Processor. As the policy becomes increasingly refined, a more representative rate should be used for BGP or IGP traffic to
`further secure the router and show commands that can detect abnormal increases in traffic rates. See the “Monitoring CPP” section of this document
`for more information regarding CPP centric show commands.
`
`Table 2. Sample CPP Policy
`
`Traffic Class
`BGP
`IGP
`Management
`Reporting
`Monitoring
`Critical-App
`Layer 2
`Undesirable
`Default
`
`Rate (PPS)
`N/A
`N/A
`250
`50
`75
`125
`25
`10
`10
`
`Conform Action
`Transmit
`Transmit
`Transmit
`Transmit
`Transmit
`Transmit
`Transmit
`Drop
`Transmit
`
`Exceed Action
`Transmit
`Transmit
`Drop
`Drop
`Drop
`Drop
`Drop
`Drop
`Drop
`
`
`The following example shows how to configure the hybrid CPP policy as described in Table 2:
`
`Define a class for each “type” of traffic and associate it with the named classification ACL.
`
`class-map match-all coppclass-bgp
`
` match access-group name coppacl-bgp
`
`class-map match-all coppclass-igp
`
` match access-group name coppacl-igp
`
`
`© 2005 Cisco Systems, Inc. All rights reserved.
`Important notices, privacy statements, and trademarks of Cisco Systems, Inc. can be found on cisco.com.
`Page 10 of 19
`
`
`
`

`
`
`
`class-map match-all coppclass-management
`
` match access-group name coppacl-management
`
`
`
`Create a class for packets that match icmp traffic classified by the reporting acl and that are marked with dscp bits or ef, af31, af21 or be.
`
`class-map match-all coppclass-reporting
`
` match access-group name coppacl-reporting
`
` match ip dscp ef af31 af21 default
`
`class-map match-all coppclass-monitoring
`
` match access-group name coppacl-monitoring
`
`class-map match-all coppclass-critical-app
`
` match access-group name coppacl-critical-app
`
`class-map match-all coppclass-layer2
`
` match protocol arp
`
`class-map match-all coppclass-undesirable
`
` match access-group name coppacl-undesirable
`
`!
`
`
`
`This is the actual policy. Depending on class of traffic, rates and associated actions are defined.
`
`BGP traffic will not be limited in any way therefore no operation needs to be specified in this class.
`
`Note: Once normal rates are determined for the BGP traffic, consider rate-limiting this class to protect the router further.
`
`policy-map copp-policy
`
` class coppclass-bgp
`
`
`
`IGP traffic will not be limited in this example either, therefore no operation needs to be specified in this class.
`
`Note: As with the BGP class, once normal rates are determined for the IGP traffic, consider setting a rate-limit to further protect the router.
`
` class coppclass-igp
`
`
`
`Management traffic is limited to a rate of 250 pps, if traffic exceeds that rate it is dropped.
`
` class coppclass-management
`
` police rate 250 pps conform-action transmit exceed-action drop
`
`
`
`Reporting traffic is limited to a rate of 50 pps, if traffic exceeds that rate it is dropped.
`
` class coppclass-reporting
`
` police rate 50 pps conform-action transmit exceed-action drop
`
`
`
`
`© 2005 Cisco Systems, Inc. All rights reserved.
`Important notices, privacy statements, and trademarks of Cisco Systems, Inc. can be found on cisco.com.
`Page 11 of 19
`
`
`
`

`
`
`
`Monitoring traffic is limited to a rate of 75 pps, if traffic exceeds that rate it is dropped.
`
` class coppclass-monitoring
`
` police rate 75 pps conform-action transmit exceed-action drop
`
`
`
`Critical-app traffic is limited to a rate of 125 pps, if traffic exceeds that rate it is dropped.
`
` class coppclass-critical-app
`
` police rate 125 pps conform-action transmit exceed-action drop
`
`
`
`Layer2 ARP traffic is limited to a rate of 25 pps, if traffic exceeds that rate it is dropped.
`
` class coppclass-layer2
`
` police rate 25 pps conform-action transmit exceed-action drop
`
`
`
`This policy drops all traffic categorized as undesirable, regardless of rate.
`
` class coppclass-undesirable
`
` police rate 10 pps conform-action drop exceed-action drop
`
` <or if on the T train you can use the drop command>
`
` drop
`
`
`
`The default class applies to all traffic received by the control plane that has not been otherwise identified. In this example, all default traffic is
`limited to 10 pps and violations of that limit are dropped.
`
` class class-default
`
` police rate 10 pps conform-action transmit exceed-action drop
`
`
`
`MONITORING CPP
`
`show access-lists
`The show access-lists command displays a count, per ACL Entry or Access Control Entry (ACE), when traffic matches a particular entry.
`This information can be used to develop a CPP policy that ensures that identified traffic is matching as expected.
`
`The absence of hits on a particular entry might indicate that the control plane has not received traffic matching the rule. If the lack of traffic
`matching a specific entry is unlikely, the rule might have been improperly written. It should be carefully reviewed to ensure that the ACL matches
`the actual traffic.
`
`
`© 2005 Cisco Systems, Inc. All rights reserved.
`Important notices, privacy statements, and trademarks of Cisco Systems, Inc. can be found on cisco.com.
`Page 12 of 19
`
`
`
`

`
`
`
`For instance, in the following example, coppacl-bgp ACL has processed 4 packets from 47.1.1.1 to the BGP port on 10.9.9.9 but no packets from
`47.1.1.1’s port 179 to 10.9.9.9.
`
`server-2821#show access-lists coppacl-bgp
`
`Extended IP access list coppacl-bgp
`
` 10 permit tcp host 47.1.1.1 host 10.9.9.9 eq bgp (4 matches)
`
` 20 permit tcp host 47.1.1.1 eq bgp host 10.9.9.9
`
` 30 permit tcp host 10.86.183.120 host 10.9.9.9 eq bgp (1 match)
`
` 40 permit tcp host 10.86.183.120 eq bgp host 10.9.9.9
`
`
`Displaying an access-list in this manner can also help with attack classification, if an attack is suspected, a show access-list can be used to display an
`ACE hit count. If one of the entries has logged an excessive count or an unusually rapid rate increase in the number of packets processed, that traffic
`is suspicious and should be investigated.
`
`In the following output, the router received a significant volume of traffic destined to UDP port 1434. This is clearly attack traffic since UDP/1434
`traffic matches the fingerprint of a known worm: Slammer.
`
`Extended IP access list coppacl-undesirable
`
` 10 permit udp any any eq 1434 (163053 matches)
`
`
`
`show policy-map control-plane
`The show policy-map control-plane command is an invaluable tool for developing site specific policies, monitoring statistics for the
`control plane policy, and troubleshooting CPP. This command displays dynamic information about the actual policy applied, including rate
`information and the number of packets (and bytes) that conformed and/or exceeded the configure