-
null
The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
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
– 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
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 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).
– For IPv4 or IPv6 traffic, no support for UDP or TCP port range matching
– For IPv6 traffic, no support for precedence or DSCP matching
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.
– 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.
|
|
|
---|---|---|
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:
|
|
|
|
---|---|---|---|
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.
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:
Use these QoS sections and the global protocol packet policing policy map configuration section:
To configure a global protocol packet policing policy map, perform this task:
|
|
---|---|
Router(config)# platform qos service-policy input policy_map_name |
– 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.
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.
Note The following commands exist in the CLI, but have no function:
To configure unicast RPF check mode, perform this task:
– 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:
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:
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:
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.
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:
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”
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