- Release 15.4SY 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)
- 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
- 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
- Security ACLs and VACLs
- QoS Rate Limiting
- Global Protocol Packet Policing
Denial of Service (DoS) Protection
- Security ACLs and VACLs
- QoS Rate Limiting
- Global Protocol Packet Policing
- Unicast Reverse Path Forwarding (uRPF) Check
- Configuring Sticky ARP
- Monitoring Packet Drop Statistics
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
- Cisco IOS Release 15.4SY supports only Ethernet interfaces. Cisco IOS Release 15.4SY does not support any WAN features or commands.
- Also see:
– Chapter 72, “MAC Address-Based Traffic Blocking”
– Chapter 81, “Traffic Storm Control”
– Chapter 77, “Control Plane Policing (CoPP)”
– http://www.cisco.com/en/US/docs/ios-xml/ios/security/config_library/15-sy/secdata-15-sy-library.html
http://www.cisco.com/en/US/products/hw/switches/ps708/tsd_products_support_series_home.html
Participate in the Technical Documentation Ideas forum
Security ACLs and VACLs
If the network is under a DoS attack, ACLs can be an efficient method for dropping the DoS packets before they reach the intended target. Use security ACLs if an attack is detected from a particular host.
In this example, the host 10.1.1.10 and all traffic from that host is denied:
Security ACLs also protect against the spoofing of addresses. For example, assume that a source address A is on the inside of a network and a switch interface that is pointing to the Internet. You can apply an inbound ACL on the switch Internet interface that denies all addresses with a source of A (the inside address). This action stops attacks where the attackers spoof inside source addresses. When the packet arrives at the switch interface, it matches on that ACL and drops the packet before it causes damage.
When the switch is used with a Cisco Intrusion Detection Module (CIDM), you can dynamically install the security ACL as a response to the detection of the attack by the sensing engine.
VACLs are a security enforcement tool based on Layer 2, Layer 3, and Layer 4 information. The result of a VACL lookup against a packet can be a permit, a deny, a permit and capture, or a redirect. When you associate a VACL with a particular VLAN, all traffic must be permitted by the VACL before the traffic is allowed into the VLAN. VACLs are enforced in hardware, so there is no performance penalty for applying VACLs to a VLAN.
See “Cisco IOS ACL Support,” and Chapter74, “VLAN ACLs (VACLs)”
QoS Rate Limiting
QoS ACLs limit the amount of a particular type of traffic that is processed by the RP. If a DoS attack is initiated against the RP, QoS ACLs can prevent the DoS traffic from reaching the RP data path and congesting it. The PFC and DFCs perform QoS in hardware, which offers an efficient means of limiting DoS traffic (once that traffic has been identified) to protect the switch from impacting the RP.
For example, if the network is experiencing ping-of-death or smurf attacks, the administrator should rate limit the ICMP traffic to counteract the DoS attack and still allow legitimate traffic through the processor, or allow it to be forwarded to the RP or host. This rate limiting configuration must be done for each flow that should be rate limited and the rate-limiting policy action should be applied to the interface.
In the following example, the access-list 101 permits and identifies ping (echo) ICMP messages from any source to any destination as traffic. Within the policy map, a policing rule defines a specified committed information rate (CIR) and burst value (96000 bps and 16000 bps) to rate limit the ping (ICMP) traffic through the chassis. The policy map then is applied to an interface or VLAN. If the ping traffic exceeds the specified rate on the VLAN or interface where the policy map is applied, it is dropped as specified in the markdown map (the markdown map for the normal burst configurations is not shown in the example).
Global Protocol Packet Policing
- Prerequisites for Global Protocol Packet Policing
- Restrictions for Global Protocol Packet Policing
- Information About Global Protocol Packet Policing
- How to Configure Single-Command Global Protocol Packet Policing
- How to Configure Policy-Based Global Protocol Packet Policing
Prerequisites for Global Protocol Packet Policing
Restrictions for Global Protocol Packet Policing
- The minimum values supported by the platform qos protocol arp police command are too small for use in production networks.
- ARP packets are approximately 40 bytes long and ARP reply packets are approximately 60 bytes long. The policer rate value is in bits per second. The burst value is in bytes per second. Together, an ARP request and reply are approximately 800 bits.
- The configured rate limits are applied separately to the PFC and each DFC. The RP CPU will receive the configured value times the number of forwarding engines.
- Policy-based protocol packet policing is applied per-forwarding engine (PFC and any DFCs).
- With Supervisor Engine 6T, policy-based protocol packet policing supports distributed aggregate policing (see the “Enabling Distributed Aggregate Policing” section).
- The protocol packet policing mechanism effectively protects the RP CPU against attacks such as line-rate ARP attacks, but it polices both routing protocols and ARP packets to the switch and also polices traffic through the switch with less granularity than CoPP.
- The policing mechanism shares the root configuration with a policing-avoidance mechanism. The policing-avoidance mechanism lets the routing protocol and ARP packets flow through the network when they reach a QoS policer. This mechanism can be configured using the platform qos protocol protocol_name pass-through command.
- Policy-based protocol packet policing does not support microflow policers.
- Only ingress Policy-based protocol packet policing is supported.
- Policy-based protocol packet policing does not support Layer 4 ACL operators (see the “Restrictions for Layer 4 Operators in ACLs” section), which imposes these subsequent restrictions:
– For IPv4 or IPv6 traffic, no support for UDP or TCP port range matching
– For IPv6 traffic, no support for precedence or DSCP matching
- Protocol packet policing policies can share an aggregate policer with QoS policies.
- An aggregate policer cannot be applied to both ingress and egress traffic.
- With Supervisor Engine 6T, policy-based protocol packet policing supports a maximum of 1,000 global TCAM entries.
- Policy-based protocol packet policing supports the class default and permit protocol_name any any commands, but traffic flow might be affected significantly because the protocol packet policing policy processes all matched traffic.
- With Supervisor Engine 6T, policy-based protocol packet policing works with any configured port trust state.
- You can configure both single-command protocol packet policing and policy-based protocol packet policing. Single-command protocol packet policing is applied first and then policy-based protocol packet policing.
Note The software does not detect or attempt to resolve any configuration conflicts between single-command protocol packet policing and policy-based protocol packet policing.
- You can configure both policy-based protocol packet policing and control plane policing (see Chapter 77, “Control Plane Policing (CoPP)”). Policy-based protocol packet policing is applied first and then CoPP.
- Single-command protocol packet policing programs the configured protocol-specific action for ingress traffic and automatically programs a corresponding egress-traffic pass-through action to preserve the ingress result egress traffic.
- Policy-based protocol packet policing does not automatically preserve the ingress policing result in egress traffic.
– To preserve the ingress policing result in egress traffic with policy-based protocol packet policing, configure an appropriate output policy. To pass egress traffic through unchanged, duplicate each ingess class in the output policy and configure trust dscp as the class-map action.
– Without an output policy-map, egress traffic is processed by any configured interface-based policy-map and ingress global policy result will be overwritten.
- The PFC and any DFCs supports a single match command in class-map match-all class maps, except that the match protocol command can be configured in a class map with the match dscp or match precedence command.
- The PFC and any DFCs supports multiple match commands in class-map match-any class maps.
- Class maps can use the match commands listed in Table 76-1 to configure a traffic class that is based on the match criteria.
|
|
|
---|---|---|
match access-group { access_list_number | name access_list_name } |
Note Use ACLs to match the following: |
|
Note The match protocol command can be configured in a class map with the match dscp command. |
||
Layer 2 traffic flooded in a VLAN because it is addressed to a currently unlearned MAC-Layer destination address. |
||
Note The match protocol command can be configured in a class map with the match precedence command. |
||
match protocol { arp | ip | ipv6 } Note The match protocol command can be configured in a class map with the match dscp or match precedence command. |
||
The PFC and any DFCs supports these ACL types for use with the match access group command:
|
|
|
|
---|---|---|---|
Information About Global Protocol Packet Policing
Attackers may try to overwhelm the RP CPU with routing protocol control packets (for example, ARP packets). Protocol packet policing rate limits this traffic in hardware. Release 15.1(1)SY1 and later releases support policy-based global protocol packet policing, shown in Cisco Feature Navigator as the Global QoS Policy feature.
How to Configure Single-Command Global Protocol Packet Policing
Enter the platform qos protocol ? to display the supported routing protocols.
The platform qos protocol arp police command rate limits ARP packets. This example shows how to allow 200 ARP requests and replies per second:
This example shows how to display the available protocols to use with protocol packet policing:
This example shows how to display the available keywords to use with the platform qos protocol command:
How to Configure Policy-Based Global Protocol Packet Policing
Use these QoS sections and the global protocol packet policing policy map configuration section:
Configuring a Global Protocol Packet Policing Policy Map
To configure a global protocol packet policing policy map, perform this task:
|
|
---|---|
Router(config)# platform qos service-policy input policy_map_name |
Unicast Reverse Path Forwarding (uRPF) Check
- Prerequisites for uRPF Check
- Restrictions for uRPF Check
- Information about uRPF Check
- Configuring the Unicast RPF Check Mode
- Enabling Self-Pinging
Prerequisites for uRPF Check
Restrictions for uRPF Check
- Unicast RPF does not provide complete protection against spoofing. Spoofed packets can enter a network through unicast RPF-enabled interfaces if an appropriate return route to the source IP address exists.
- You can configure a unicast RPF mode on each interface.
- The “allow default” options of the unicast RPF modes do not offer significant protection against spoofing.
– Strict unicast RPF Check with Allow Default—Received IP traffic that is sourced from a prefix that exists in the routing table passes the unicast RPF check if the prefix is reachable through the input interface. If a default route is configured, any IP packet with a source prefix that is not in the routing table passes the unicast RPF check if the ingress interface is a reverse path for the default route.
– Loose unicast RPF Check with Allow Default—If a default route is configured, any IP packet passes the unicast RPF check.
- Unicast RPF Strict Mode—The unicast RPF strict mode provides the greatest security against spoofed traffic. If, on all unicast RPF-check enabled interfaces, the switch receives valid IP traffic through interfaces that are reverse paths for the traffic, then strict mode is an option.
- Unicast RPF Loose Mode—The unicast RPF loose mode provides less protection than strict mode, but it is an option on switches that receive valid IP traffic on interfaces that are not reverse paths for the traffic. The unicast RPF loose mode verifies that received traffic is sourced from a prefix that exists in the routing table, regardless of the interface on which the traffic arrives.
Information about uRPF Check
The unicast RPF check verifies that the source address of received IP packets is reachable. The unicast RPF check discards IP packets that lack a verifiable IP source prefix (route), which helps mitigate problems that are caused by traffic with malformed or forged (spoofed) IP source addresses.
The PFC4 and DFC4s provide hardware support for the unicast RPF check on up to 16 paths, both with and without ACL filtering, for both IPv4 and IPv6 traffic.
To ensure that no more than 16 reverse-path interfaces exist in the routing table for each prefix, enter the maximum-paths 16 command in config-router mode when configuring OSPF, EIGRP, or BGP.
How to Configure Unicast RPF Check
Note The following commands exist in the CLI, but have no function:
- platform ip cef rpf interface-group
- platform ip cef rpf multipath interface-group
- platform ip cef rpf multipath pass
- platform ip cef rpf multipath punt
Configuring the Unicast RPF Check Mode
To configure unicast RPF check mode, perform this task:
- Use the rx keyword to enable strict check mode.
- Use the any keyword to enable exist-only check mode.
- Use the allow-default keyword to allow use of the default route for RPF verification.
- Use the list option to identify an access list.
– If the access list denies network access, denied packets are dropped at the port.
– If the access list permits network access, packets are forwarded to the destination address. Forwarded packets are counted in the interface statistics.
– If the access list includes the logging action, information about the packets is sent to the log server.
This example shows how to enable unicast RPF exist-only check mode on Gigabit Ethernet port 4/1:
This example shows how to enable unicast RPF strict check mode on Gigabit Ethernet port 4/2:
Enabling Self-Pinging
With unicast RPF check enabled, by default the switch cannot ping itself. To enable self-pinging, perform this task:
|
|
|
---|---|---|
Router(config)# interface {{ vlan vlan_ID } | { type slot/port } | { port-channel number }} |
||
Router(config-if)# ip verify unicast source reachable-via any allow-self-ping |
||
This example shows how to enable self-pinging:
Configuring Sticky ARP
Sticky ARP prevents MAC address spoofing by ensuring that ARP entries (IP address, MAC address, and source VLAN) do not get overridden. The switch maintains ARP entries in order to forward traffic to end devices or other switches. ARP entries are usually updated periodically or modified when ARP broadcasts are received. During an attack, ARP broadcasts are sent using a spoofed MAC address (with a legitimate IP address) so that the switch learns the legitimate IP address with the spoofed MAC address and begins to forward traffic to that MAC address. With sticky ARP enabled, the switch learns the ARP entries and does not accept modifications received through ARP broadcasts. If you attempt to override the sticky ARP configuration, you will receive an error message.
To configure sticky ARP on a Layer 3 interface, perform this task:
|
|
|
---|---|---|
Router(config)# interface type 1 slot/port |
||
1.type = fastethernet, gigabitethernet, or tengigabitethernet |
This example shows how to enable sticky ARP on interface 5/1:
Monitoring Packet Drop Statistics
- Prerequisites for Packet Drop Statistics
- Restrictions for Packet Drop Statistics
- Information About Packet Drop Statistics
- How to Monitor Dropped Packets
Prerequisites for Packet Drop Statistics
Restrictions for Packet Drop Statistics
Information About Packet Drop Statistics
You can use show commands to display packet drop statistics. You can capture the traffic on an interface and send a copy of this traffic to a traffic analyzer connected to a port, which can aggregate packet drop statistics.
How to Monitor Dropped Packets
Using show Commands
The PFC and DFCs support ACL hit counters in hardware. You can use the show platform hardware acl entry interface command to display each entry in the ACL TCAM. You can also use the TTL and IP options counters to monitor the performance of the Layer 3 forwarding engine.
This example shows how to use the show platform hardware acl entry interface command to display packet statistics and errors associated with the Layer 3 forwarding engine:
Using SPAN
This example shows how to use the monitor session command to capture and forward traffic to an external interface:
This example shows how to use the show monitor session command to display the destination port:
For more information, see Chapter56, “Local SPAN, RSPAN, and ERSPAN”
Using VACL Capture
The VACL capture feature allows you to direct traffic to ports configured to forward captured traffic. The capture action sets the capture bit for the forwarded packets so that ports with the capture function enabled can receive the packets. Only forwarded packets can be captured.
You can use VACL capture to assign traffic from each VLAN to a different interface.
VACL capture does not allow you to send one type of traffic, such as HTTP, to one interface and another type of traffic, such as DNS, to another interface. Also, VACL capture granularity is only applicable to traffic switched locally; you cannot preserve the granularity if you direct traffic to a remote switch.
For more information, see Chapter74, “VLAN ACLs (VACLs)”
http://www.cisco.com/en/US/products/hw/switches/ps708/tsd_products_support_series_home.html
Participate in the Technical Documentation Ideas forum