- Release 15.5SY Supervisor Engine 6T Software Configuration Guide
- Preface
- Product Overview
- Command-Line Interfaces
- Smart Port Macros
- Virtual Switching Systems (VSS)
- Enhanced Fast Software Upgrade (eFSU)
- Fast Software Upgrades
- Stateful Switchover (SSO)
- Non-Stop Forwarding (NSF)
- RPR Supervisor Engine Redundancy
- Interface Configuration
- UniDirectional Link Detection (UDLD)
- Instant Access
- EnergyWise
- Power Management
- Environmental Monitoring
- Online Diagnostics
- Onboard Failure Logging (OBFL)
- Switch Fabric Functionality
- Cisco IP Phone Support
- Power over Ethernet
- Layer 2 LAN Port Configuration
- Flex Links
- EtherChannels
- IEEE 802.1ak MVRP and MRP
- VLAN Trunking Protocol (VTP)
- VLANs
- Private VLANs (PVLANs)
- Private Hosts
- IEEE 802.1Q Tunneling
- Layer 2 Protocol Tunneling
- Spanning Tree Protocols (STP, MST)
- Optional STP Features
- IP Unicast Layer 3 Switching
- Policy Based Routing (PBR)
- Layer 3 Interface Configuration
- Unidirectional Ethernet (UDE) and unidirectional link routing (UDLR)
- Multiprotocol Label Switching (MPLS)
- MPLS VPN Support
- Ethernet over MPLS (EoMPLS)
- Virtual Private LAN Services (VPLS)
- L2VPN Advanced VPLS (A-VPLS)
- Ethernet Virtual Connections (EVC)
- Layer 2 over Multipoint GRE (L2omGRE)
- Campus Fabric
- IPv4 Multicast Layer 3 Features
- IPv4 Multicast IGMP Snooping
- IPv4 PIM Snooping
- IPv4 Multicast VLAN Registration (MVR)
- IPv4 IGMP Filtering
- IPv4 Router Guard
- IPv4 Multicast VPN Support
- IPv6 Multicast Layer 3 Features
- IPv6 MLD Snooping
- NetFlow Hardware Support
- System Event Archive (SEA)
- Backplane Platform Monitoring
- Local SPAN, RSPAN, and ERSPAN
- SNMP IfIndex Persistence
- Top-N Reports
- Layer 2 Traceroute Utility
- Mini Protocol Analyzer
- PFC QoS Guidelines and Restrictions
- PFC QoS Overview
- PFC QoS Classification, Marking, and Policing
- PFC QoS Policy Based Queueing
- PFC QoS Global and Interface Options
- AutoQoS
- MPLS QoS
- PFC QoS Statistics Data Export
- Cisco IOS ACL Support
- Cisco TrustSec (CTS)
- AutoSecure
- MAC Address-Based Traffic Blocking
- Port ACLs (PACLs)
- VLAN ACLs (VACLs)
- Policy-Based Forwarding (PBF)
- Denial of Service (DoS) Protection
- Control Plane Policing (CoPP)
- Dynamic Host Configuration Protocol (DHCP) Snooping
- Configuring IGMP Proxy
- IP Source Guard
- Dynamic ARP Inspection (DAI)
- Traffic Storm Control
- Unknown Unicast and Multicast Flood Control
- IEEE 802.1X Port-Based Authentication
- Configuring Web-Based Authentication
- Port Security
- Lawful Intercept
- Online Diagnostic Tests
Control Plane Policing (CoPP)
- Prerequisites for CoPP
- Restrictions for CoPP
- Information About CoPP
- Default Settings for CoPP
- How to Configure CoPP
- Monitoring CoPP
Note ● For complete syntax and usage information for the commands used in this chapter, see these publications:
http://www.cisco.com/en/US/products/ps11846/prod_command_reference_list.html
http://www.cisco.com/en/US/prod/collateral/switches/ps5718/ps708/white_paper_c11-663623.html
- Cisco IOS Release 15.4SY supports only Ethernet interfaces. Cisco IOS Release 15.4SY does not support any WAN features or commands.
http://www.cisco.com/en/US/products/hw/switches/ps708/tsd_products_support_series_home.html
Participate in the Technical Documentation Ideas forum
Prerequisites for CoPP
Restrictions for CoPP
- The PFC and DFC provide hardware support for classes that match multicast traffic.
- CoPP is not supported in hardware for broadcast packets. The combination of ACLs, traffic storm control, and CoPP software protection provides protection against broadcast DoS attacks.
- CoPP does not support non-IP classes except for the default non-IP class. ACLs can be used instead of non-IP classes to drop non-IP traffic, and the default non-IP CoPP class can be used to limit to non-IP traffic that reaches the RP CPU.
- Do not use the log keyword in CoPP policy ACLs.
- If you have a large QoS configuration, the system may run out of TCAM space. If this is the case, CoPP may be performed in software.
- When there is a large QoS configuration for other interfaces, you can run out of TCAM space. When this situation occurs, CoPP may be performed entirely in software and result in performance degradation and CPU cycle consumption.
- You must ensure that the CoPP policy does not filter critical traffic such as routing protocols or interactive access to the switches. Filtering this traffic could prevent remote access to the switch, requiring a console connection.
- The PFC and DFCs support built-in special-case rate limiters, which are useful for situations where an ACL cannot be used (for example, TTL, MTU, and IP options). When you enable the special-case rate limiters, you should be aware that the special-case rate limiters will override the CoPP policy for packets matching the rate-limiter criteria.
- Neither egress CoPP nor silent mode is supported. CoPP is only supported on ingress (service-policy output CoPP cannot be applied to the control plane interface).
- ACE hit counters in hardware are only for ACL logic. You can rely on software ACE hit counters and the show access-list, show policy-map control-plane, and show platform ip qos commands to troubleshoot evaluate CPU traffic.
- CoPP is performed on a per-forwarding-engine basis and software CoPP is performed on an aggregate basis.
- CoPP does not support ACEs with the log keyword.
- CoPP uses hardware QoS TCAM resources. Enter the show tcam utilization command to verify the TCAM utilization.
- To avoid matching the filtering and policing that are configured in a subsequent class, configure policing in each class. CoPP does not apply the filtering in a class that does not contain a police command. A class without a police command matches no traffic.
- The ACLs used for classification are QoS ACLs. The supported QoS ACLs are IP standard, extended, and named.
- These are the only match types supported:
- Only IP ACLs are supported in hardware.
- MAC-based matching is done in software only.
- You can enter one match command in a single class map only.
- When defining the service policy, the police policy-map action is the only supported action.
- When applying the service policy to the control plane, the input direction is only supported.
Information About CoPP
The traffic managed by the RP is divided into three functional components or planes :
The control plane policing (CoPP) feature increases security on the switch by protecting the RP from unnecessary or DoS traffic and giving priority to important control plane and management traffic. The PFC and DFCs provide hardware support for CoPP. CoPP works with the hardware rate limiters.
The PFC and DFCs support the built-in “special case” rate limiters that can be used when an ACL cannot classify particular scenarios, such as IP options cases, TTL and MTU failure cases, packets with errors, and multicast packets. When enabling the special-case rate limiters, the special-case rate limiters override the CoPP policy for packets matching the rate-limiter criteria.
The majority of traffic managed by the RP is handled by way of the control and management planes. You can use CoPP to protect the control and management planes, and ensure routing stability, reachability, and packet delivery. CoPP uses a dedicated control plane configuration through the modular QoS CLI (MQC) to provide filtering and rate-limiting capabilities for the control plane packets.
You must first identify the traffic to be classified by defining a class map. The class map defines packets for a particular traffic class. After you have classified the traffic, you can create policy maps to enforce policy actions for the identified traffic.
Default Settings for CoPP
CoPP is enabled by default. To disable the default CoPP configuration, enter the no service-policy input policy-default-autocopp control plane configuration mode command.
These are the default CoPP class maps:
This is the default CoPP policy map:
conform-action drop
exceed-action drop
conform-action drop
exceed-action drop
conform-action transmit
exceed-action drop
conform-action transmit
exceed-action drop
conform-action transmit
exceed-action drop
conform-action transmit
exceed-action drop
conform-action transmit
exceed-action drop
conform-action transmit
exceed-action drop
conform-action transmit
exceed-action drop
conform-action transmit
exceed-action drop
conform-action transmit
exceed-action drop
conform-action set-discard-class-transmit 48
exceed-action transmit
conform-action set-discard-class-transmit 48
exceed-action transmit
conform-action set-discard-class-transmit 48
exceed-action drop
Note The default policer rate for the MLD and IGMP classes has been updated to 5000 pps from the previous default value of 10000 pps. If the default policer rate for the MLD and IGMP classes is not set to 5000 pps, change the value manually by running the no policy-map policy-default-autocopp and platform qos auto-copp commands in global configuration mode.
How to Configure CoPP
Configuring CoPP
To configure CoPP, perform this task:
Defining CoPP Traffic Classification
Traffic Classification Overview
You can define any number of classes, but typically traffic is grouped into classes that are based on relative importance. The following provides a sample grouping:
- Border Gateway Protocol (BGP)—Traffic that is crucial to maintaining neighbor relationships for BGP routing protocol, for example, 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 do not need to use this class.
- Interior Gateway Protocol (IGP)—Traffic that is crucial to maintaining IGP routing protocols, for example, 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.
- Management—Necessary, frequently used traffic that is required during day-to-day operations. For example, traffic used for remote network access, and Cisco IOS image upgrades and management, such as 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).
- Reporting—Traffic used for generating network performance statistics for the purpose of reporting. For 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.
- Monitoring—Traffic used for monitoring a switch. Traffic should be permitted but should never be a risk to the switch; with CoPP, this traffic can be permitted but limited to a low rate. For example, ICMP echo request (ping) and traceroute.
- 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 (in other words, one customer may use multicast, while another uses IPsec or generic routing encapsulation (GRE). For example, 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.
- Layer 2 Protocols—Traffic used for address resolution protocol (ARP). Excessive ARP packets can potentially monopolize RP resources, starving other important processes; CoPP can be used to rate limit ARP packets to prevent this situation. ARP is the only Layer 2 protocol that can be specifically classified using the match protocol classification criteria.
- Undesirable—Explicitly identifies bad or malicious traffic that should be unconditionally dropped and denied access to the RP. The undesirable classification is particularly useful when known traffic destined for the switch should always be denied and not placed into a default category. If you explicitly deny traffic, then you can enter show commands to collect approximate statistics on the denied traffic and estimate its rate.
- Default—All remaining traffic destined for the RP that has not been identified. MQC provides the default class, so the user can specify the treatment to be applied to traffic not explicitly identified in the other user-defined classes. This traffic has a highly reduced rate of access to the RP. With a default classification in place, statistics can be monitored to determine the rate of otherwise unidentified traffic destined for the control plane. After this traffic is identified, further analysis can be performed to classify it and, if needed, the other CoPP policy entries can be updated to accomodate this traffic.
After you have classified the traffic, the ACLs build the classes of traffic that are used to define the policies. For sample basic ACLs for CoPP classification, see the “Sample Basic ACLs for CoPP Traffic Classification” section.
Traffic Classification Restrictions
- Before you develop the actual CoPP policy, you must identify and separate the required traffic into different classes. Traffic is grouped into nine classes that are based on relative importance. The actual number of classes needed might differ and should be selected based on your local requirements and security policies.
- You do not have to define policies that match bidirectionally. You only need to identify traffic unidirectionally (from the network to the RP) since the policy is applied on ingress only.
Sample Basic ACLs for CoPP Traffic Classification
This section shows sample basic ACLs for CoPP classification. In the samples, the commonly required traffic is identified with these ACLs:
- ACL 120—Critical traffic
- ACL 121—Important traffic
- ACL 122—Normal traffic
- ACL 123—Explicitly denies unwanted traffic
- ACL 124—All other traffic
This example shows how to define ACL 120 for critical traffic:
This example shows how to allow BGP from a known peer to this switch’s BGP TCP port:
This example shows how to allow BGP from a peer’s BGP port to this switch:
This example shows how to define ACL 121 for the important class:
This example shows how to permit return traffic from TACACS host:
This example shows how to permit SSH access to the switch from a subnet:
This example shows how to allow full access for Telnet to the switch from a host in a specific subnet and police the rest of the subnet:
This example shows how to allow SNMP access from the NMS host to the switch:
This example shows how to allow the switch to receive NTP packets from a known clock source:
This example shows how to define ACL 122 for the normal traffic class:
This example shows how to permit switch-originated traceroute traffic:
This example shows how to permit receipt of responses to the switch that originated the pings:
This example shows how to allow pings to the switch:
This example shows how to define ACL 123 for the undesirable class.
Note In the following example, ACL 123 is a permit entry for classification and monitoring purposes, and traffic is dropped as a result of the CoPP policy.
This example shows how to permit all traffic destined to UDP 1434 for policing:
This example shows how to define ACL 124 for all other traffic:
Monitoring CoPP
You can enter the show policy-map control-plane command for developing site-specific policies, monitoring statistics for the control plane policy, and troubleshooting CoPP. This command displays dynamic information about the actual policy applied, including rate information and the number of bytes (and packets) that conformed or exceeded the configured policies both in hardware and in software.
The output of the show policy-map control-plane command is as follows:
To display the hardware counters for bytes dropped and forwarded by the policy, enter the show platform qos ip command:
To display the CoPP access list information, enter the show access-lists coppacl-bgp command:
http://www.cisco.com/en/US/products/hw/switches/ps708/tsd_products_support_series_home.html
Participate in the Technical Documentation Ideas forum