Catalyst 6500 Series Software Configuration Guide, 8.7 - Configuring Access Control [Cisco Catalyst 6500 Series Switches]

Table Of Contents

Configuring Access Control

Understanding How ACLs Work

Hardware Requirements

Supported ACLs

QoS ACLs

Cisco IOS ACLs

VACLs

VACL Overview

ACEs Supported in VACLs

Handling Fragmented and Unfragmented Traffic

Applying Cisco IOS ACLs and VACLs on VLANs

Bridged Packets

Routed Packets

Multicast Packets

Using Cisco IOS ACLs in your Network

Hardware and Software Handling of Cisco IOS ACLs with PFC

Security Cisco IOS ACLs

Reflexive ACLs

TCP Intercept

Policy Routing

WCCP

NAT

Unicast RPF Check

Bridge-Groups

Hardware and Software Handling of Cisco IOS ACLs with PFC2 and PFC3A/PFC3B/PFC3BXL

Security Cisco IOS ACLs

Rate Limiting for Cisco IOS ACL Logging

Reflexive ACLs

TCP Intercept

Policy Routing

WCCP

NAT

Unicast RPF Check

Bridge-Groups

Using VACLs with Cisco IOS ACLs

Configuring Cisco IOS ACLs and VACLs on the Same VLAN Interface Guidelines

Using the Implicit Deny Action

Grouping Actions Together

Limiting the Number of Actions

Avoiding Layer 4 Port Information

Estimating Merge Results with Supervisor Engine Software Releases Prior to Release 7.1(1)

Estimating Merge Results with Supervisor Engine Software Releases 7.1(1) or Later Releases

Layer 4 Operations Configuration Guidelines

Determining Layer 4 Operation Usage

Determining Logical Operation Unit Usage

Using VACLs in Your Network

Wiring Closet Configuration

Redirecting Broadcast Traffic to a Specific Server Port

Restricting the DHCP Response for a Specific Server

Denying Access to a Server on Another VLAN

Restricting ARP Traffic

Inspecting ARP Traffic

Overview

Implementation

ARP Traffic-Inspection Configuration Guidelines

ARP Traffic-Inspection Configuration Procedures

Dynamic ARP Inspection

Overview

Dynamic ARP Inspection Configuration Procedures

Configuring ACLs on Private VLANs

Capturing Traffic Flows

Unsupported Features

Configuring VACLs

VACL Configuration Guidelines

VACL Configuration Summary

Configuring VACLs from the CLI

Specifying the ACL-Merge Algorithm

Creating an IP VACL and Adding ACEs

Creating an IPX VACL and Adding ACEs

Creating a Non-IP Version 4/Non-IPX VACL (MAC VACL) and Adding ACEs

Committing ACLs

Mapping a VACL to a VLAN

Displaying the Contents of a VACL

Displaying a VACL-to-VLAN Mapping

Clearing the Edit Buffer

Removing ACEs from Security ACLs

Clearing the Security ACL Map

Displaying VACL Management Information

Capturing Traffic Flows on Specified Ports

Configuring VACL Logging

Configuring MAC-Based ACL Lookups for All Packet Types

Overview of MAC-Based ACLs

Using MAC-Based ACL Lookups for All Packet Types

Including the VLAN and CoS in MAC-Based ACLs

VLAN Matching

CoS Matching

Configuration Guidelines

Configuring MAC-Based ACL Lookups for All Packet Types

Include CoS, VLAN and Packet Type in MAC ACLs and Extend EtherType

Configuring and Storing VACLs and QoS ACLs in Flash Memory

Automatically Moving the VACL and QoS ACL Configuration to Flash Memory

Manually Moving the VACL and QoS ACL Configuration to Flash Memory

Running with the VACL and QoS ACL Configuration in Flash Memory

Moving the VACL and QoS ACL Configuration Back to NVRAM

Redundancy Synchronization Support

Interacting with High Availability

Configuring Port-Based ACLs

PACL Configuration Overview

PACL Configuration Guidelines

PACL Interaction with VACLs and Cisco IOS ACLs

EtherChannel and PACL Interactions

Dynamic ACLs (Applies to Merge-Mode Only)

Trunking Mode (Applies to Merge-Mode Only)

Auxiliary VLANs (Applies to Merge-Mode Only)

Private VLANs (Applies to Merge-Mode Only)

Port-VLAN Association Changes (Applies to Merge-Mode Only)

Online Insertion and Removal

Configuring PACLs from the CLI

Specifying the PACL Mode

Displaying PACL Information

Mapping an ACL to Ports or to VLANs

Displaying ACL Mapping Information

Displaying ACL Information for an EtherChannel

PACL Configuration Examples

Example 1

Example 2

Example 3

Example 4

Example 5

Example 6

Example 7

Configuring ACL Statistics

ACL Statistics Overview

Configuring ACL Statistics from the CLI

Enabling the ACL Compiler Optimization

Enabling ACL Statistics on a Per-ACL Basis

Enabling ACL Statistics on a Per-VLAN Basis

Enabling ACL Statistics on a Per-ACE Basis

Clearing ACL Statistics

Displaying ACL Statistics Information

Configuring the Compression and Reordering of ACL Masks

Configuring the CRAM Feature from the CLI

Enabling a Test Run of the CRAM Feature

Enabling the CRAM Feature Manually

Enabling the Automatic Execution of the CRAM Feature

Displaying the CRAM Feature Status Information

Disabling the CRAM Feature Automatic Mode

Configuring Policy-Based Forwarding

Understanding How PBF Works

PBF Hardware and Software Requirements

Configuring PBF from the CLI

Enabling PBF and Specifying a MAC Address for the PFC2 or PFC3A/PFC3B/PFC3BXL

Specifying the PBF MAC Address on a VLAN

Configuring VACLs for PBF

Displaying PBF Information

Clearing Entries in PBF VACLs

Rolling Back Adjacency Table Entries in the Edit Buffer

Configuring Hosts for PBF

PBF Configuration Example

Enhancements to PBF Configuration (Software Releases 7.5(1) and Later)

PBF Configuration Enhancement Overview

Specifying a PBF_MAP_ACL

Displaying the PBF_MAP_ACL Information

Clearing the PBF_MAP_ACL Configuration

Enhancements to the PBF Configuration (Software Releases 8.3(1) and Later)

PBF Usage Guidelines and Restrictions

Setting and Committing Security ACLs and Adjacency Information

clear Commands

show Commands

Using the sc1 Interface as a Diagnostic Interface

Enhancements to PBF Configuration (Software Releases 8.6(1) and Later)

Configuring the PBF Before Software Release 8.6(1)

Configuring PBF in Software Release 8.6(1) and Later Releases

Downloadable ACLs

Configuring a Downloaded ACL for Dot1x

Sample Output of Show Commands

Configuring a Downloaded ACL for Dot1x for an IP Phone

Creating a Placeholder for a Downloaded ACL

Creating a Placeholder for an IP Phone

Displaying Downloaded ACL Information

Configuring Access Control

This chapter describes how to configure the access control lists (ACLs) on the Catalyst 6500 series switches. The configuration of the ACLs depends on the type of hardware that you install on your supervisor engine. See the "Hardware Requirements" section for more information.

Note For complete syntax and usage information for the commands that are used in this chapter, refer to the Catalyst 6500 Series Switch Command Reference publication.

Note For detailed information on configuring policy-based ACLs (PBACLs), see the "Configuring Policy-Based ACLs" section on page 44-21.

This chapter consists of these sections:

•Understanding How ACLs Work

•Hardware Requirements

•Supported ACLs

•Applying Cisco IOS ACLs and VACLs on VLANs

•Using Cisco IOS ACLs in your Network

•Using VACLs with Cisco IOS ACLs

•Using VACLs in Your Network

•Unsupported Features

•Configuring VACLs

•Configuring MAC-Based ACL Lookups for All Packet Types

•Configuring and Storing VACLs and QoS ACLs in Flash Memory

•Configuring Port-Based ACLs

•Configuring ACL Statistics

•Configuring Policy-Based Forwarding

•Downloadable ACLs

Note Except where specifically differentiated, the information and procedures in this chapter apply to Supervisor Engine 32 with Policy Feature Card 3B/3BXL (PFC3B/PFC3BXL), Supervisor Engine 720 with PFC3A/PFC3B/PFC3BXL, Supervisor Engine 2 with PFC2, and Supervisor Engine 1 with PFC.

Understanding How ACLs Work

Traditionally, switches operated at Layer 2 only; switches switched traffic within a VLAN and routers routed traffic between the VLANs. Catalyst 6500 series switches with the Multilayer Switch Feature Card (MSFC) can accelerate packet routing between VLANs by using Layer 3 switching (Multilayer Switching [MLS]). The switch first bridges the packet, the packet is then routed internally without going to the router, and then the packet is bridged again to send it to its destination. During this process, the switch can access control all packets that it switches including the packets that are bridged within a VLAN.

Cisco IOS ACLs provide access control for the routed traffic between the VLANs, and the VLAN ACLs (VACLs) provide access control for all packets.

The standard and extended Cisco IOS ACLs are used to classify the packets. The classified packets can be subject to a number of features such as access control (security), encryption, policy-based routing, and so on. The standard and extended Cisco IOS ACLs are configured only on the router interfaces and applied on the routed packets.

The VACLs can provide access control that is based on the Layer 3 addresses for the IP and IPX protocols. The unsupported protocols are access controlled through the MAC addresses. A VACL is applied to all packets (bridged and routed) and can be configured on any VLAN interface. Once a VACL is configured on a VLAN, all packets (routed or bridged) entering the VLAN are checked against the VACL. The packets can either enter the VLAN through a switch port or through a router port after being routed.

Note With Supervisor Engine 720 (PFC3A/PFC3B/PFC3BXL) and Supervisor Engine 32 (PFC3B/PFC3BXL), the IPX routing is done through the software and the IPX Cisco IOS ACLs and IPX VACLs are not supported. You can match the IPX packets using the MAC VACLs. You can enter the ipx-arpa keyword to match the IPX ARPA frames. Use 0xffff EtherType to match on IPX non-ARPA frames and frames with an EtherType of 0xffff. For information on configuring the MAC VACLs, see the "Creating a Non-IP Version 4/Non-IPX VACL (MAC VACL) and Adding ACEs" section.

Hardware Requirements

The hardware that is required to configure the ACLs on Catalyst 6500 series switches is as follows:

•Cisco IOS ACLs:

–Supervisor Engine 1 and Policy Feature Card (PFC) and MSFC or MSFC2

–Supervisor Engine 2 and PFC2 and MSFC2

–Supervisor Engine 720 and PFC3A/PFC3B/PFC3BXL and MSFC3

–Supervisor Engine 32 and PFC3B/PFC3BXL and MSFC2A

•VACLs and QoS ACLs:

–Supervisor Engine 1 and PFC

–Supervisor Engine 2 and PFC2

–Supervisor Engine 720 and PFC3A/PFC3B/PFC3BXL

–Supervisor Engine 32 and PFC3B/PFC3BXL

Note The quality of service (QoS) feature set that is supported on your switch is determined by the switching engine daughter card that is installed on the supervisor engine. See Chapter 51, "Configuring QoS" for more information.

Supported ACLs

These sections describe the ACLs that are supported by the Catalyst 6500 series switches:

•QoS ACLs

•Cisco IOS ACLs

•VACLs

QoS ACLs

You can configure the QoS ACLs on the switch; see Chapter 51, "Configuring QoS."

Cisco IOS ACLs

Cisco IOS ACLs are configured on the MSFC VLAN interfaces. An ACL provides access control and consists of an ordered set of access control entries (ACEs). Many other features also use ACLs for specifying flows. For example, Web Cache Redirect (through the Web Cache Coordination Protocol [WCCP]) uses the ACLs to specify the HTTP flows that can be redirected to a Web cache engine.

Most Cisco IOS features are applied on the interfaces for specific directions (inbound versus outbound). However, some features use the ACLs globally. For such features, the ACLs are applied on all interfaces for a given direction. As an example, TCP intercept uses a global ACL that is applied on all outbound interfaces.

One Cisco IOS ACL can be used with multiple features for a given interface, and one feature can use multiple ACLs. When a single ACL is used by multiple features, Cisco IOS software examines it multiple times.

Cisco IOS software examines the ACLs that are associated with the features that are configured on a given interface and a direction. As the packets enter the router on a given interface, Cisco IOS software examines the ACLs that are associated with all the inbound features that are configured on that interface for the following:

•Inbound ACLs (standard, extended, and/or reflexive)

•Encryption ACLs (not supported on the MSFC)

•Policy routing ACLs

•Network Address Translation (NAT) for outside-to-inside translation

After the packets are routed and before they are forwarded out to the next hop, Cisco IOS software examines all ACLs that are associated with the outbound features configured on the egress interface for the following:

•Outbound ACLs (standard, extended, and/or reflexive)

•Encryption ACLs (not supported on the MSFC)

•NAT ACLs (for inside-to-outside translation)

•WCCP ACL

•TCP intercept ACL

VACLs

The following sections describe the VACLs:

•VACL Overview

•ACEs Supported in VACLs

•Handling Fragmented and Unfragmented Traffic

VACL Overview

The VACLs can access control all traffic. You can configure the VACLs on the switch to apply to all packets that are routed into or out of a VLAN or are bridged within a VLAN. The VACLs are strictly for security packet filtering and redirecting traffic to specific physical switch ports. Unlike the Cisco IOS ACLs, the VACLs are not defined by direction (input or output).

You can configure the VACLs on the Layer 3 addresses for IP and IPX. All other protocols are access controlled through the MAC addresses and EtherType using the MAC VACLs.

Caution The IP traffic and IPX traffic are not access controlled by the MAC VACLs. All other traffic types (AppleTalk, DECnet, and so on) are classified as MAC traffic; the MAC VACLs are used to access control this traffic.

Note With Supervisor Engine 720 (PFC3A/PFC3B/PFC3BXL) and Supervisor Engine 32 (PFC3B/PFC3BXL), the IPX routing is done through the software and the IPX Cisco IOS ACLs and IPX VACLs are not supported. You can match the IPX packets using the MAC VACLs. You can enter the ipx-arpa keyword to match the IPX ARPA frames. Use 0xffff EtherType to match on the IPX non-ARPA frames and the frames with an EtherType of 0xffff. For information on configuring the MAC VACLs, see the "Creating a Non-IP Version 4/Non-IPX VACL (MAC VACL) and Adding ACEs" section.

You can enforce the VACLs only on the packets going through the Catalyst 6500 series switch; you cannot enforce the VACLs on the traffic between the hosts on a hub or another switch that is connected to the Catalyst 6500 series switch.

ACEs Supported in VACLs

A VACL contains an ordered list of access control entries (ACEs). Each VACL can contain ACEs of only one type. Each ACE contains a number of fields that are matched against the contents of a packet. Each field can have an associated bit mask to indicate which bits are relevant. An action is associated with each ACE that describes what the system should do with the packet when a match occurs. The action is feature dependent. Catalyst 6500 series switches support three types of ACEs in the hardware:

•IP ACEs

•IPX ACEs

•Ethernet ACEs

Table 15-1 lists the parameters that are associated with each ACE type.

Table 15-1 ACE Types and Parameters

ACE Type

TCP or UDP¹

ICMP1

Other IP1

IPX

Ethernet²

Layer 4 parameters

Source port

Source port operator

Destination port

Destination port operator

ICMP code1

N/A

ICMP type

N/A

Layer 3 parameters

IP ToS byte

IP ToS byte

IP ToS byte

IP source address

IP source address

IP source address

IPX source network

IP destination address

IP destination address

IP destination address

IPX destination network

IPX destination node

TCP or UDP

ICMP

Other protocol

IPX packet type

Layer 2 parameters

EtherType

Ethernet source address

Ethernet destination address

¹IP ACEs.

²For Ethernet packets that are not IP version 4 or IPX.

Handling Fragmented and Unfragmented Traffic

TCP/UDP or any Layer 4 protocol traffic, when fragmented, loses the Layer 4 information (Layer 4 source/destination ports). This situation makes it difficult to enforce security that is based on the application. However, you can identify the fragments and distinguish them from the rest of the TCP/UDP traffic.

The Layer 4 parameters of the ACEs can filter the unfragmented and fragmented traffic with fragments that have offset 0. The IP fragments that have an offset other than 0 miss the Layer 4 port information and cannot be filtered. The following examples show how the ACEs handle the packet fragmentation.

This example shows that if the traffic from 1.1.1.1, port 68 is fragmented, only the first fragment goes to port 4/3, and the rest of the traffic from port 68 does not hit this entry.
redirect 4/3 tcp host 1.1.1.1 eq 68 host 255.255.255.255
This example shows that the traffic coming from 1.1.1.1, port 68 and going to 2.2.2.2, port 34 is permitted. If the packets are fragmented, the first fragment hits this entry and is permitted; the fragments that have an offset other than 0 are also permitted as a default result for the fragments.
permit tcp host 1.1.1.1 eq 68 host 2.2.2.2 eq 34
This example shows that the fragment that has offset 0 of the traffic from 1.1.1.1, port 68 going to 2.2.2.2, port 34 is denied. The fragments that have an offset other than 0 are permitted as a default.
deny tcp host 1.1.1.1 eq 68 host 2.2.2.2 eq 34
In the releases prior to software release 6.1(1), the fragment filtering was completely transparent; you would type an ACE such as permit tcp .... port eq port_number and the software would implicitly install the following ACE at the top of the ACL: permit tcp any any fragments.

Software release 6.1(1) and later releases, have a fragment option. If you do not specify the fragment keyword, the behavior is the same as in the previous releases. If you specify the fragment keyword, the system does not automatically install a global permit statement for the fragments. This keyword allows you to control how the fragments are handled.

In this example, 10.1.1.2 is configured to serve the HTTP connections. If you do not use a fragment ACE, all the fragments for the TCP traffic are permitted as the permit tcp any any fragments ACE is added automatically at the top of the ACL as follows:
permit tcp any any fragments
1. permit tcp any host 10.1.1.2 eq www

2. deny ip any host 10.1.1.2

3. permit ip any any

In the above example, if you change the entry 1 as follows:

1. deny tcp any host 10.1.1.2 eq www

A permit tcp any any fragments ACE is not added at the top of the ACL. If the entry is a deny statement, the next access-list entry is processed.

Note The deny statements are handled differently for the noninitial fragments versus the nonfragmented or initial fragments.

When you specify the fragment keyword, the system does not install the global permit TCP or UDP fragments statement. When you specify the fragment keyword for at least one ACE, the software implicitly installs the ACEs to permit the flows to a specific IP address (or subnet) that you specify.

In this ACL example, the deny tcp any host 10.1.1.2 fragment entry stops the fragmented traffic going to all TCP ports on host 10.1.1.2. Later in the ACL, the permit udp any host 10.1.1.2 eq 69 entry allows the clients to connect to the TFTP server 10.1.1.2. The system automatically installs a permit for all fragments of udp traffic to host 10.1.1.2 ACE; otherwise, the fragments would be denied by the entry deny ip any host 10.1.1.2.

1. deny tcp any host 10.1.1.2 fragment

2. permit tcp any host 10.1.1.2 eq www

3. permit udp any host 10.1.1.2 eq 69

4. permit udp any gt 1023 10.1.1.2 gt 1023

5. deny ip any host 10.1.1.2

6. permit ip any any

If you explicitly want to stop the fragmented UDP traffic to host 10.1.1.2, enter deny udp any host 10.1.1.2 fragment before entry number 3 as shown in this example:

[...]

3. deny udp any host 10.1.1.2 fragment

4. permit udp any host 10.1.1.2 eq 69

5. permit udp any gt 1023 10.1.1.2 gt 1023

[...]

Applying Cisco IOS ACLs and VACLs on VLANs

This section describes how to apply the Cisco IOS ACLs and VACLs to the VLAN for the bridged, routed, and multicast packets.

These sections show how the ACLs and the VACLs are applied:

•Bridged Packets

•Routed Packets

•Multicast Packets

Bridged Packets

Figure 15-1 shows how an ACL is applied on the bridged packets. For the bridged packets, only the Layer 2 ACLs are applied to the input VLAN.

Figure 15-1 Applying ACLs on Bridged Packets

Routed Packets

Figure 15-2 shows how the ACLs are applied on the routed/Layer 3-switched packets. For the routed/Layer 3-switched packets, the ACLs are applied in the following order:

1. VACL for input VLAN

2. Input Cisco IOS ACL

3. Output Cisco IOS ACL

4. VACL for output VLAN

Figure 15-2 Applying ACLs on Routed Packets

Multicast Packets

Figure 15-3 shows how the ACLs are applied on the packets that need multicast expansion. For the packets that need multicast expansion, the ACLs are applied in the following order:

1. Packets that need multicast expansion:

a. VACL for input VLAN

b. Input Cisco IOS ACL

2. Packets after multicast expansion:

a. Output Cisco IOS ACL

b. VACL for output VLAN

3. Packets originating from the router:

a. VACL for output VLAN

Figure 15-3 Applying ACLs on Multicast Packets

Using Cisco IOS ACLs in your Network

Note Configuring Cisco IOS ACLs on the Catalyst 6500 series switch routed-VLAN interfaces is the same as configuring the ACLs on the other Cisco routers. To configure the Cisco IOS ACLs, see the "Unsupported Features" section and the "VACL Configuration Guidelines" section. In addition, refer to the Cisco IOS configuration guides and command reference publication. To configure the ACLs for IP, refer to the "Configuring IP Services" chapter in the Network Protocols Configuration Guide, Part 1.

When a feature is configured on the router to process traffic (such as NAT), the Cisco IOS ACL that is associated with the feature determines the specific traffic that is bridged to the router instead of being switched in Layer 3. The router then applies the feature and routes the packet normally. Some exceptions to this process are described in the "Hardware and Software Handling of Cisco IOS ACLs with PFC" section.

Note In the systems with redundant MSFCs, the ACL configurations for Cisco IOS ACLs and VACLs must be the same on both MSFCs.

Caution For PFC: By default, the MSFC sends Internet Control Message Protocol (ICMP) unreachables when a packet is denied by an access group. These access-group denied packets are not dropped in the hardware but are bridged to the MSFC so that the MSFC can generate the ICMP-unreachable message. To drop the access-group denied packets in the hardware, you must disable the ICMP unreachables using the no ip unreachables interface configuration command. The ip unreachables command is enabled by default.

For PFC2 and PFC3A/PFC3B/PFC3BXL: If the IP unreachables or IP redirect is enabled on an interface, the deny is performed in the hardware although a small number of packets are sent to the MSFC2/MSFC3 to generate the appropriate ICMP-unreachable messages.

These sections describe the hardware and software handling of the ACLs with PFC, PFC2, and PFC3A/PFC3B/PFC3BXL:

•Hardware and Software Handling of Cisco IOS ACLs with PFC

•Hardware and Software Handling of Cisco IOS ACLs with PFC2 and PFC3A/PFC3B/PFC3BXL

Hardware and Software Handling of Cisco IOS ACLs with PFC

This section describes how Cisco IOS ACLs with the PFC are handled by the hardware and the software.

Note For information on Cisco IOS ACLs with PFC2 and PFC3A/PFC3B/PFC3BXL, see the "Hardware and Software Handling of Cisco IOS ACLs with PFC2 and PFC3A/PFC3B/PFC3BXL" section.

ACL feature processing requires forwarding of some flows by the software. The forwarding rate for the software-forwarded flows is substantially less than for the hardware-forwarded flows. The flows that require logging, as specified by the ACL, are handled in the software without impacting the non-log flow forwarding in the hardware.

Note When you enter the show ip access-list command, the match count that is displayed does not account for the packets that are access controlled in the hardware.

Note IPX Cisco IOS ACLs with the source host node number specified cannot be enforced on the switch in the hardware; the MSFC has to process the ACL in the software. This process significantly degrades system performance.

These sections describe how the different types of ACLs and traffic flows are handled by the hardware and the software:

•Security Cisco IOS ACLs

•Reflexive ACLs

•TCP Intercept

•Policy Routing

•WCCP

•NAT

•Unicast RPF Check

•Bridge-Groups

Security Cisco IOS ACLs

The IP and IPX security Cisco IOS ACLs with PFC are as follows:

•The flows that match a "deny" statement in a security ACL are dropped by the hardware if "ip unreachables" is disabled. The flows matching a "permit" statement are switched in the hardware.

•Permit and deny actions of the standard and extended ACLs (input and output) for security access control are handled in the hardware.

•IP accounting for an ACL access violation on a given interface is supported by forwarding all denied packets for that interface to the software without impacting other flows.

•Dynamic (lock and key) ACL flows are supported in the hardware; however, idle timeout is not supported.

•IPX standard input and output ACLs are supported in the hardware when the ACL parameters are IPX source network, destination network, and/or destination node. If the ACL contains any other parameters, it is handled in the software.

•IPX extended input and output ACLs are supported in the hardware when the ACL parameters are IPX source network, destination network, destination node, and/or protocol type.

•ACL flows requiring logging are handled in the software without impacting non-log flow forwarding in the hardware.

Reflexive ACLs

Up to 512 simultaneous reflexive sessions are supported in the hardware. When the reflexive ACLs are applied, the flow mask is changed to VLAN-full flow.

TCP Intercept

TCP intercept implements the software to protect the TCP servers from the TCP SYN-flooding attacks, which are denial-of-service attacks. TCP intercept helps prevent the SYN-flooding attacks by intercepting and validating the TCP connection requests. In intercept mode, the TCP intercept software intercepts the TCP synchronization (SYN) packets from the clients to the servers that match an extended access list. The software establishes a connection with the client on behalf of the destination server, and if successful, establishes the connection with the server on behalf of the client and binds the two half-connections together transparently. This process ensures that the connection attempts from the unreachable hosts never reach the server. The software continues to intercept and forward the packets throughout the duration of the connection.

Policy Routing

The policy routing-required flows are handled in the software without impacting the non-policy routed flow forwarding in the hardware. When a route map contains multiple "match" clauses, all conditions that are imposed by these match clauses must be met before a packet is policy routed. However, for the route maps that contain both "match ip address" and "match length," all traffic matching the ACL in the "match ip address" clause is forwarded to the software regardless of the match length criteria. For the route maps that contain only the match length clauses, all packets that are received on the interface are forwarded to the software.

When you enable hardware policy routing using the mls ip pbr global command, all policy routing occurs in the hardware.

Caution If you use the mls ip pbr command to enable policy routing, policy routing is applied in the hardware for all interfaces regardless of which interface was configured for the policy routing.

WCCP

The HTTP requests that are subject to Web Cache Coordination Protocol (WCCP) redirection are handled in the software; the HTTP replies from the server and the Cache Engine are handled in the hardware.

NAT

The NAT-required flows are handled in the software without impacting non-NAT flow forwarding in the hardware.

Unicast RPF Check

The unicast RPF feature is supported in the hardware on the PFC. For ACL-based RPF checks, the traffic that is denied by the unicast RPF ACL is forwarded to the MSFC for RPF validation.

Caution With ACL-based unicast RPF, the packets that are denied by the ACL are sent to the CPU for RPF validation. In the event of DoS attacks, these packets will most likely match the deny ACE and be forwarded to the CPU. Under heavy traffic conditions, this process could cause high CPU utilization.

Note The drop-suppress statistics for the ACL-based RPF check is not supported.

Bridge-Groups

Cisco IOS bridge-group ACLs are handled in the software.

Hardware and Software Handling of Cisco IOS ACLs with PFC2 and PFC3A/PFC3B/PFC3BXL

This section describes how Cisco IOS ACLs are handled by the hardware and the software in the switches that are configured with the PFC2 and PFC3A/PFC3B/PFC3BXL.

ACL feature processing requires forwarding some flows to the software. The forwarding rate for software-forwarded flows is substantially less than for the hardware-forwarded flows. The flows that require logging as specified by the ACL are handled in the software without impacting non-log flow forwarding in the hardware.

Note When you enter the show ip access-list command, the match count displayed does not account for the packets that are access controlled in the hardware.

Note The IPX Cisco IOS ACLs with the source host node number specified cannot be enforced on the switch in the hardware; the MSFC has to process the ACL in the software. This process significantly degrades the system performance.

Note With Supervisor Engine 720 (PFC3A/PFC3B/PFC3BXL) and Supervisor Engine 32 (PFC3B/PFC3BXL), the IPX routing is done through the software and the IPX Cisco IOS ACLs and IPX VACLs are not supported. You can match the IPX packets using the MAC VACLs. You can enter the ipx-arpa keyword to match the IPX ARPA frames. Use 0xffff EtherType to match on the IPX non-ARPA frames and the frames with an EtherType of 0xffff. For information on configuring the MAC VACLs, see the "Creating a Non-IP Version 4/Non-IPX VACL (MAC VACL) and Adding ACEs" section.

These sections describe how the different types of Cisco IOS ACLs and traffic flows are handled by the hardware and the software in the switches that are configured with the PFC2 or PFC3A/PFC3B/PFC3BXL:

•Security Cisco IOS ACLs

•Rate Limiting for Cisco IOS ACL Logging

•Reflexive ACLs

•TCP Intercept

•Policy Routing

•WCCP

•NAT

•Unicast RPF Check

•Bridge-Groups

Security Cisco IOS ACLs

The IP and IPX security Cisco IOS ACLs in the switches that are configured with the PFC2 or PFC3A/PFC3B/PFC3BXL are as follows:

•If either the "ip unreachables" or "ip redirect" options are enabled, most of the packets of the flows that match a "deny" statement in an ACL are dropped by the hardware. Only a few packets are processed in the software in order for the router to send the appropriate ICMP-unreachable message.

•The permit and deny actions of the standard and extended ACLs (input and output) for security access control are handled in the hardware.

•The IP accounting for an ACL access violation on a given interface is supported by forwarding all denied packets for that interface to the software without impacting other flows.

•The dynamic (lock and key) ACL flows are supported in the hardware; however, idle timeout is not supported.

•The IPX standard input and output ACLs are supported in the hardware when the ACL parameters are IPX source network, destination network, and/or destination node. If the ACL contains any other parameters, it is handled in the software.

•The IPX extended input and output ACLs are supported in the hardware when the ACL parameters are IPX source network, destination network, destination node, and/or protocol type.

•The ACL flows that require logging are handled in the software without impacting non-log flow forwarding in the hardware.

Rate Limiting for Cisco IOS ACL Logging

Rate limiting for Cisco IOS ACL logging limits the number of packets that are sent to the MSFC CPU for the bridged ACEs. An ACE is bridged when the result for the Cisco IOS ACL is a deny or permit with the log option specified. The bridge action can result in Cisco IOS ACL logging overloading the MSFC CPU. When you configure rate limiting for Cisco IOS ACL logging, the bridged ACEs are redirected to the MSFC with rate limiting.

Configuring Rate Limiting for Cisco IOS ACL Logging Guidelines

This section describes the guidelines for configuring rate limiting for Cisco IOS ACL logging:

•After entering the set acllog ratelimit rate command or the clear acllog command, you must either reset the MSFC or perform a shutdown/no shutdown on the MSFC interface(s) that have the ACEs with the log keyword applied.

After entering the set acllog ratelimit rate command, performing a reset or shutdown/no shutdown causes the bridged ACEs to be redirected to the MSFC with rate limiting.

After entering the clear acllog command, performing a reset or shutdown/no shutdown causes the switch to return to its previous behavior; the bridge action remains unchanged.

•The rate that is specified by entering the set acllog ratelimit rate command can be from 500 to 2000. The rate is the number of packets per second that hit a redirect ACE and are sent to the MSFC. If the actual number of packets per second is greater than the rate that you specify, the packets that exceed the specified rate are dropped. We recommend that you specify a rate of 500 packets per second.

Configuring Rate Limiting for Cisco IOS ACL Logging

To configure rate limiting for Cisco IOS ACL logging, perform this task in privileged mode:

Task

Command

Step 1

Enable the ACL logging and specify a rate for Cisco IOS ACL logging rate limiting.

set acllog ratelimit rate

Step 2

Show the ACL logging status.

show acllog

This example shows how to enable the ACL logging and specify a rate of 500 for Cisco IOS ACL logging rate limiting:
Console> (enable) set acllog ratelimit 500
If the ACLs-LOG were already applied, the rate limit mechanism will be effective on system 
restart, or after shut/no shut the interface.
Console> (enable) 
Console> (enable) show acllog
ACL log rate limit enabled, rate = 500 pps.
Console> (enable) 
This example shows how to clear (disable) ACL logging. After clearing ACL logging, the bridge action remains unchanged; the system behavior is the same as before the set acllog ratelimit command was issued.
Console> (enable) clear acllog
ACL log rate limit is cleared.
If the ACLs-LOG were already applied, the rate limit mechanism will be disabled on system 
restart, or after shut/no shut the interface.
Console> (enable) 
Reflexive ACLs

The ICMP packets are handled in the software. For the TCP/UDP flows, once the flow is established, they are handled in the hardware. When the reflexive ACLs are applied, the flow mask is changed to VLAN-full flow.

TCP Intercept

Note TCP intercept is not supported with Supervisor Engine 720 (PFC3A/PFC3B/PFC3BXL) or Supervisor Engine 32 (PFC3B/PFC3BXL).

TCP intercept implements the software to protect the TCP servers from the TCP SYN-flooding attacks, which are denial-of-service attacks. TCP intercept helps prevent the SYN-flooding attacks by intercepting and validating the TCP connection requests. In intercept mode, the TCP intercept software intercepts the TCP synchronization (SYN) packets from the clients to the servers that match an extended access list. The software establishes a connection with the client on behalf of the destination server, and if successful, establishes the connection with the server on behalf of the client and binds the two half-connections together transparently. This process ensures that the connection attempts from the unreachable hosts never reach the server. The software continues to intercept and forward the packets throughout the duration of the connection.

The hardware support for TCP intercept on a PFC2 is as follows:

1. Once you configure TCP intercept, all TCP SYN packets that match the ACEs with a permit clause in the TCP intercept ACL, and which are permitted by the security ACL, are sent to the software to apply the TCP intercept functionality. This process occurs even if the security ACL does not have the SYN flag specified.

2. If a connection is established successfully, the following applies:

a. If the TCP intercept is using intercept mode with timeout, all traffic belonging to the given connection/flow is handled in the software.

b. For the other modes of TCP intercept, once the connection is successfully established, the software installs a hardware shortcut to switch the rest of the flow in the hardware.

3. If a connection is not established successfully, no other traffic can belong to that flow.

Policy Routing

The policy routing-required flows are handled in the hardware or the software depending on the route map. If the route map contains only a match IP address clause, and the set clause contains the next hop and the next hop is reachable, then the packet is forwarded in the hardware. When a route map contains multiple match clauses, all conditions that are imposed by these match clauses must be met before a packet is policy routed. However, for the route maps that contain both a match IP address clause and match length clause, all traffic matching the ACL in the match IP address clause is forwarded to the software regardless of the match length criteria. For the route maps that contain only match length clauses, all packets that are received on the interface are forwarded to the software.

Note The mls ip pbr command is not required (and not supported) on the PFC2 or PFC3A/PFC3B/PFC3BXL.

WCCP

Note WCCP is not supported with Supervisor Engine 720 or Supervisor Engine 32 in software releases 8.1(x) through 8.4(x).

The HTTP requests that are subject to WCCP redirection are handled in the software; the HTTP replies from the server and the cache engine are handled in the hardware.

NAT

The NAT-required flows are handled in the software without impacting the non-NAT flow forwarding in the hardware.

Unicast RPF Check

Unicast RPF is supported in the hardware on the PFC2 and PFC3A/PFC3B/PFC3BXL. For the ACL-based RPF checks, the traffic that is denied by the unicast RPF ACL is forwarded to the MSFC2 or MSFC3 for RPF validation.

Caution With ACL-based unicast RPF, the packets that are denied by the ACL are sent to the CPU for RPF validation. In the event of DoS attacks, these packets will most likely match the deny ACE and be forwarded to the CPU. Under heavy traffic conditions, this process could cause high CPU utilization.

Note The drop-suppress statistics for the ACL-based RPF check is not supported.

Bridge-Groups

Cisco IOS bridge-group ACLs are handled in the software.

Using VACLs with Cisco IOS ACLs

To access control both the bridged and routed traffic, you can use the VACLs only or a combination of Cisco IOS ACLs and VACLs. You can define Cisco IOS ACLs on both the input and output routed-VLAN interfaces, and you can define a VACL to access control the bridged traffic.

If a flow matches a VACL deny or redirect clause in the ACL, irrespective of the Cisco IOS ACL configuration, the flow is denied or redirected. The following caveats apply to Cisco IOS ACLs when they are used with VACLs:

•Packets that require logging on the outbound ACLs are not logged if they are denied by a VACL.

•NAT—VACLs are applied on the packets before NAT translation. If the translated flow should not be access controlled, the flow might get access controlled after the translation because of the VACL configuration.

Note The VACLs have an implicit deny at the end of the list; a packet is denied if it does not match any VACL ACE.

These sections describe the Cisco IOS ACL and VACL configuration guidelines and guidelines for Layer 4 operations:

•Configuring Cisco IOS ACLs and VACLs on the Same VLAN Interface Guidelines

•Layer 4 Operations Configuration Guidelines

Configuring Cisco IOS ACLs and VACLs on the Same VLAN Interface Guidelines

This section describes the guidelines for configuring a Cisco IOS ACL and a VACL on the same VLAN. These guidelines do not apply to the configurations where you are mapping Cisco IOS ACLs and VACLs on different VLANs.

The Catalyst 6500 series switch hardware provides one lookup for the security ACLs for each direction (input and output); you must merge a Cisco IOS ACL and a VACL when they are configured on the same VLAN. Merging the Cisco IOS ACL with the VACL might significantly increase the number of ACEs.

If you must configure a Cisco IOS ACL and a VACL on the same VLAN, use the following guidelines for both Cisco IOS ACL and VACL configurations.

Note To display the percentage of ACL storage that is being used, enter the show security acl resource-usage command.

These sections provide the Cisco IOS ACL and VACL configuration guidelines and examples:

•Using the Implicit Deny Action

•Grouping Actions Together

•Limiting the Number of Actions

•Avoiding Layer 4 Port Information

•Estimating Merge Results with Supervisor Engine Software Releases Prior to Release 7.1(1)

•Estimating Merge Results with Supervisor Engine Software Releases 7.1(1) or Later Releases

Using the Implicit Deny Action

If possible, use the implicit deny action at the end of an ACL (deny any any) and define the ACEs to permit only allowed traffic. You can achieve this same effect by defining all the deny entries and specifying permit ip any any at the end of the list (see Example 1).

Grouping Actions Together

To define multiple actions in an ACL (permit, deny, redirect), group each action type. Example 3 shows what can happen when you do not group each type. In the example, the deny action in line 6 was grouped with the permit actions. If this deny action is removed, the result of merging would be 53 entries, instead of 329 entries.

Limiting the Number of Actions

An ACL with only the permit ACEs has two actions: permit and deny (because of the implicit deny at the end of the list). An ACL with permit and redirect has three actions: permit, redirect, and deny (because of the implicit deny at the end of the list).

When configuring an ACL, the best merge results are obtained when you specify only two different actions: permit and deny, redirect and permit, or redirect and deny.

Note With supervisor engine software release 7.1(1) or later releases, due to an improved algorithm for merging ACLs, you do not need to limit the number of actions when configuring an ACL.

To specify a redirect and deny ACL, do not use any permit ACEs. To specify a redirect and permit ACL, use permit ACEs, redirect ACEs, and for the last ACE, specify permit ip any any. If you specify permit ip any any, you will override the implicit deny ip any at the end of the list (see Example 4).

Avoiding Layer 4 Port Information

Avoid including Layer 4 information in an ACL because it will complicate the merging process. You will obtain the best merge results if the ACLs are filtered based on the IP addresses (source and destination) and not on the full flow (source IP address, destination IP address, protocol, and protocol ports).

If you need to specify the full flow, follow the recommendations in the "Using the Implicit Deny Action" section and "Grouping Actions Together" section. If you cannot follow the recommendation because the ACL has both the IP and TCP/UDP/ICMP ACEs with Layer 4 information, put the Layer 4 ACEs at the end of the list to prioritize the traffic filtering based on the IP addresses.

Estimating Merge Results with Supervisor Engine Software Releases Prior to Release 7.1(1)

Note To see a comparison of the merge results when using supervisor engine software releases before software release 7.1(1) versus software release 7.1(1) or later releases, see the "Estimating Merge Results with Supervisor Engine Software Releases 7.1(1) or Later Releases" section.

If you follow the ACL guidelines when configuring the ACLs, you can get a rough estimate of the merge results for the ACLs.

The following formula uses ACL A, ACL B, and ACL C. If ACL C is the result of merging ACL A and ACL B, and you know the size of ACL A and ACL B, you can estimate the upper limit of the size of ACL C when no Layer 4 port information has been specified on ACL A and ACL B, as follows:

size of ACL C = (size of ACL A) x (size of ACL B) x (2)

Note In software releases prior to release 7.1(1), the formula is used as a guideline but the number of entries could go beyond the predicted range. In software release 7.1(1) and later releases, with the new ACL merge algorithm, the formula is accurate for all cases. If Layer 4 port information is specified, the upper limit could be higher even with the new algorithm. See the "Layer 4 Operations Configuration Guidelines" section for detailed information.

Two ACL-merge algorithms are available—the binary decision diagram (BDD) and the order-dependent merge (ODM). ODM is the enhanced algorithm that was introduced in software release 7.1(1). The BDD algorithm was used in releases prior to software release 7.1(1). See the "Specifying the ACL-Merge Algorithm" section for detailed configuration information.

Note With software release 8.1(1) and later releases, the BDD algorithm is no longer supported on any platform (PFC, PFC2, or PFC3A/PFC3B/PFC3BXL). The default ACL-merge algorithm is ODM. In software release 8.1(1) and later releases, the following command changes appear: The set aclmerge algo and set aclmerge bdd commands have been removed. The show aclmerge {bdd | algo} command has been reduced to show aclmerge algo.

These examples show the merge results for the various Cisco IOS ACL and VACL configurations. One VACL and one Cisco IOS ACL are configured on the same VLAN.

Example 1

This exampl