-
Catalyst 6500 Series Software Configuration Guide, 8.7
-
Index
-
Preface
-
Product Overview
-
Command-Line Interfaces
-
Configuring the Switch IP Address and Default Gateway
-
Configuring Ethernet, Fast Ethernet, Gigabit Ethernet, and 10-Gigabit Ethernet Switching
-
Configuring Ethernet VLAN Trunks
-
Configuring EtherChannel
-
Configuring IEEE 802.1Q Tunneling and Layer 2 Protocol Tunneling
-
Configuring Spanning Tree
-
Configuring Spanning Tree PortFast, UplinkFast, BackboneFast, and Loop Guard
-
Configuring VTP
-
Configuring VLANs
-
Configuring InterVLAN Routing
-
Configuring CEF for PFC2/PFC3
-
Configuring MLS
-
Configuring Access Control
-
Configuring NDE
-
Configuring GVRP
-
Configuring MVRP
-
Configuring Dynamic Port VLAN Membership with VMPS
-
Checking Status and Connectivity
-
Configuring Online Diagnostics
-
Administering the Switch
-
Configuring Redundancy
-
Configuring NSF with SSO MSFC Redundancy
-
Modifying the Switch Boot Configuration
-
Working with the Flash File System
-
Working with System Software Images
-
Working with Configuration Files
-
Configuring System Message Logging
-
Configuring DNS
-
Configuring CDP
-
Configuring UDLD
-
Configuring DHCP Snooping and IP Source Guard
-
Configuring NTP
-
Configuring Broadcast Suppression
-
Configuring Layer 3 Protocol Filtering
-
Configuring the IP Permit List
-
Configuring Port Security
-
Configuring Switch Access Using AAA
-
Configuring 802.1x Authentication
-
Configuring MAC Authentication Bypass
-
Configuring Web-Based Proxy Authentication
-
Tracking Host Aging
-
Configuring Network Admission Control
-
Configuring Unicast Flood Blocking
-
Configuring SNMP
-
Configuring RMON
-
Configuring SPAN, RSPAN and the Mini Protocol Analyzer
-
Using Switch TopN Reports
-
Configuring Multicast Services
-
Configuring QoS
-
Configuring Automatic QoS
-
Configuring ASLB
-
Configuring the Switch Fabric Module
-
Configuring a VoIP Network
-
Configuring MSFC IOS Features
-
Acronyms
-
Table Of Contents
Handling Fragmented and Unfragmented Traffic
Applying Cisco IOS ACLs and VACLs on VLANs
Using Cisco IOS ACLs in your Network
Hardware and Software Handling of Cisco IOS ACLs with PFC
Hardware and Software Handling of Cisco IOS ACLs with PFC2 and PFC3A/PFC3B/PFC3BXL
Rate Limiting for Cisco IOS ACL Logging
Using VACLs with Cisco IOS ACLs
Configuring Cisco IOS ACLs and VACLs on the Same VLAN Interface Guidelines
Using the Implicit Deny Action
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
Redirecting Broadcast Traffic to a Specific Server Port
Restricting the DHCP Response for a Specific Server
Denying Access to a Server on Another VLAN
ARP Traffic-Inspection Configuration Guidelines
ARP Traffic-Inspection Configuration Procedures
Dynamic ARP Inspection Configuration Procedures
Configuring ACLs on Private VLANs
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
Displaying the Contents of a VACL
Displaying a VACL-to-VLAN Mapping
Removing ACEs from Security ACLs
Displaying VACL Management Information
Capturing Traffic Flows on Specified Ports
Configuring MAC-Based ACL Lookups for All Packet Types
Using MAC-Based ACL Lookups for All Packet Types
Including the VLAN and CoS in MAC-Based ACLs
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
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)
Configuring PACLs from the CLI
Mapping an ACL to Ports or to VLANs
Displaying ACL Mapping Information
Displaying ACL Information for an EtherChannel
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
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
PBF Hardware and Software Requirements
Enabling PBF and Specifying a MAC Address for the PFC2 or PFC3A/PFC3B/PFC3BXL
Specifying the PBF MAC Address on a VLAN
Rolling Back Adjacency Table Entries in the Edit Buffer
Enhancements to PBF Configuration (Software Releases 7.5(1) and Later)
PBF Configuration Enhancement Overview
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
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
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
This chapter consists of these sections:
•
•
•
•
•
•
Note
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
Hardware Requirements
The hardware that is required to configure the ACLs on Catalyst 6500 series switches is as follows:
•
–
–
–
–
•
–
–
–
–
Note
Supported ACLs
These sections describe the ACLs that are supported by the Catalyst 6500 series switches:
QoS ACLs
You can configure the QoS ACLs on the switch; see Chapter 52, "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:
•
•
•
•
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:
•
•
•
•
•
VACLs
The following sections describe the VACLs:
•
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
Note
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:
•
•
•
Table 15-1 lists the parameters that are associated with each ACE type.
Table 15-1 ACE Types and Parameters
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
1 IP ACEs.
2 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.255This 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 34This 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 34In 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 fragments1.
2.
3.
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
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.
2.
3.
4.
5.
6.
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.
4.
5.
[...]
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
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.
2.
3.
4.
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.
a.
b.
2.
a.
b.
3.
a.
Figure 15-3 Applying ACLs on Multicast Packets
Using Cisco IOS ACLs in your Network
Note
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
Caution
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
This section describes how Cisco IOS ACLs with the PFC are handled by the hardware and the software.
Note
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
Note
These sections describe how the different types of ACLs and traffic flows are handled by the hardware and the software:
•
•
Security Cisco IOS ACLs
The IP and IPX security Cisco IOS ACLs with PFC are as follows:
•
•
•
•
•
•
•
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
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
Note
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
Note
Note
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
The IP and IPX security Cisco IOS ACLs in the switches that are configured with the PFC2 or PFC3A/PFC3B/PFC3BXL are as follows:
•
•
•
•
•
•
•
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, 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.
•
Configuring Rate Limiting for Cisco IOS ACL Logging
To configure rate limiting for Cisco IOS ACL logging, perform this task in privileged mode:
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 500If 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 acllogACL 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 acllogACL 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 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.
2.
a.
b.
3.
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
WCCP
Note
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
Note
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:
•
•
Note
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
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
These sections provide the Cisco IOS ACL and VACL configuration guidelines and examples:
•
•
•
•
•
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
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
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
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
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 example shows that the VACL does not follow the recommended guidelines (in line 9, a deny action is defined instead of using the implicit deny action at the end of the ACL), and the resultant merge increases the number of ACEs:
******** VACL ***********1 permit udp host 194.72.72.33 194.72.6.160 0.0.0.152 permit udp host 147.150.213.94 194.72.6.64 0.0.0.15 eq bootps3 permit udp 194.73.74.0 0.0.0.255 host 194.72.6.205 eq syslog4 permit udp host 167.221.23.1 host 194.72.6.198 eq tacacs5 permit udp 194.72.136.1 0.0.3.128 194.72.6.64 0.0.0.15 eq tftp6 permit udp host 193.6.65.17 host 194.72.6.205 gt 10237 permit tcp any host 194.72.6.528 permit tcp any host 194.72.6.52 eq 1139 deny tcp any host 194.72.6.51 eq ftp10 permit tcp any host 194.72.6.51 eq ftp-data11 permit tcp any host 194.72.6.5112 permit tcp any eq domain host 194.72.6.5113 permit tcp any host 194.72.6.51 gt 102314 permit ip any host 1.1.1.1******** Cisco IOS ACL ************1 deny ip any host 239.255.255.2552 permit ip any any******** MERGE **********has 91 entries entriesExample 2
In Example 1, if you follow the guidelines and remove line 9 (the implicit deny is then used at the end of the ACL) and modify lines 11 and 12 (lines 11 and 12 are modified so that the traffic that line 9 would have dropped is not permitted), you see the following equivalent ACL with improved merge results:
******** VACL **********1 permit udp host 194.72.72.33 194.72.6.160 0.0.0.152 permit udp host 147.150.213.94 194.72.6.64 0.0.0.15 eq bootps3 permit udp 194.73.74.0 0.0.0.255 host 194.72.6.205 eq syslog4 permit udp host 167.221.23.1 host 194.72.6.198 eq tacacs5 permit udp 194.72.136.1 0.0.3.128 194.72.6.64 0.0.0.15 eq tftp6 permit udp host 193.6.65.17 host 194.72.6.205 gt 10237 permit tcp any host 194.72.6.528 permit tcp any host 194.72.6.52 eq 1139 permit tcp any host 194.72.6.51 eq ftp-data10 permit tcp any host 194.72.6.51 neq ftp11 permit tcp any eq domain host 194.72.6.51 neq ftp12 permit tcp any host 194.72.6.51 gt 102313 permit ip any host 1.1.1.1******** Cisco IOS ACL ************1 deny ip any host 239.255.255.2552 permit ip any any******** MERGE ***********has 78 entriesExample 3
This example shows that the VACL does not follow the recommended guidelines (all the action types are not grouped), and the resultant merge significantly increases the number of ACEs:
******** VACL ***********1 deny ip 0.0.0.0 255.255.255.0 any2 deny ip 0.0.0.255 255.255.255.0 any3 deny ip any 0.0.0.0 255.255.255.04 permit ip any host 239.255.255.2555 permit ip any host 255.255.255.2556 deny ip any 0.0.0.255 255.255.255.07 permit tcp any range 0 65534 any range 0 655348 permit udp any range 0 65534 any range 0 655349 permit icmp any any10 permit ip any any******** Cisco IOS ACL **********1 deny ip any host 239.255.255.2552 permit ip any any******** MERGE **********has 329 entriesExample 4
This example shows that the VACL does not follow the recommended guidelines (three different actions are specified), and the resultant merge significantly increases the number of ACEs:
******** VACL ***********1 redirect 4/25 tcp host 192.168.1.67 host 255.255.255.2552 redirect 4/25 udp host 192.168.1.67 host 255.255.255.2553 deny tcp any any lt 304 deny udp any any lt 305 permit ip any any******* Cisco IOS ACL ***********1 deny ip any host 239.255.255.2552 permit ip any any******* MERGE **********has 142 entriesExample 5
This example shows that if you modify the VACL in Example 4 and specify only two different actions, the merge results are significantly improved:
******** VACL ***********1 redirect 4/25 tcp host 192.168.1.67 host 255.255.255.2552 redirect 4/25 udp host 192.168.1.67 host 255.255.255.2553 permit ip any any******* Cisco IOS ACL ***********1 deny ip any host 239.255.255.2552 permit ip any any******* MERGE **********has 4 entriesEstimating Merge Results with Supervisor Engine Software Releases 7.1(1) or Later Releases
In supervisor engine software releases prior to software release 7.1(1), the following formula is true for software release 7.1(1) and later releases: The size of ACL C = (size of ACL A) x (size of ACL B) x (2).
Note
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 software configuration information.
Note
Examples
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
******** VACL ***********1 permit udp host 194.72.72.33 194.72.6.160 0.0.0.152 permit udp host 147.150.213.94 194.72.6.64 0.0.0.15 eq bootps3 permit udp 194.73.74.0 0.0.0.255 host 194.72.6.205 eq syslog4 permit udp host 167.221.23.1 host 194.72.6.198 eq tacacs5 permit udp 194.72.136.1 0.0.3.128 194.72.6.64 0.0.0.15 eq tftp6 permit udp host 193.6.65.17 host 194.72.6.205 gt 10237 permit tcp any host 194.72.6.528 permit tcp any host 194.72.6.52 eq 1139 deny tcp any host 194.72.6.51 eq ftp10 permit tcp any host 194.72.6.51 eq ftp-data11 permit tcp any host 194.72.6.5112 permit tcp any eq domain host 194.72.6.5113 permit tcp any host 194.72.6.51 gt 102314 permit ip any host 1.1.1.1******** Cisco IOS ACL ************1 deny ip any host 239.255.255.2552 permit ip any any******* MERGE **********Using the new algorithm - 17 entriesUsing the old algorighm - 91 entriesExample 2
******** VACL **********1 permit udp host 194.72.72.33 194.72.6.160 0.0.0.152 permit udp host 147.150.213.94 194.72.6.64 0.0.0.15 eq bootps3 permit udp 194.73.74.0 0.0.0.255 host 194.72.6.205 eq syslog4 permit udp host 167.221.23.1 host 194.72.6.198 eq tacacs5 permit udp 194.72.136.1 0.0.3.128 194.72.6.64 0.0.0.15 eq tftp6 permit udp host 193.6.65.17 host 194.72.6.205 gt 10237 permit tcp any host 194.72.6.528 permit tcp any host 194.72.6.52 eq 1139 permit tcp any host 194.72.6.51 eq ftp-data10 permit tcp any host 194.72.6.51 neq ftp11 permit tcp any eq domain host 194.72.6.51 neq ftp12 permit tcp any host 194.72.6.51 gt 102313 permit ip any host 1.1.1.1******** Cisco IOS ACL ************1 deny ip any host 239.255.255.2552 permit ip any any******** MERGE ***********Using the new algorithm - 16 entriesUsing the old algorithm - 78 entriesExample 3
******** VACL ***********1 deny ip 0.0.0.0 255.255.255.0 any2 deny ip 0.0.0.255 255.255.255.0 any3 deny ip any 0.0.0.0 255.255.255.04 permit ip any host 239.255.255.2555 permit ip any host 255.255.255.2556 deny ip any 0.0.0.255 255.255.255.07 permit tcp any range 0 65534 any range 0 655348 permit udp any range 0 65534 any range 0 655349 permit icmp any any10 permit ip any any******** Cisco IOS ACL **********1 deny ip any host 239.255.255.2552 permit ip any any******** MERGE **********Using the new algorithm - 12 entriesUsing the old algorithm - 303 entriesExample 4
******** VACL ***********1 redirect 4/25 tcp host 192.168.1.67 host 255.255.255.2552 redirect 4/25 udp host 192.168.1.67 host 255.255.255.2553 deny tcp any any lt 304 deny udp any any lt 305 permit ip any any******* Cisco IOS ACL ***********1 deny ip any host 239.255.255.2552 permit ip any any******* MERGE **********Using the new algorithm - 6 entriesUsing the old algorithm - 142 entriesExample 5
******** VACL ***********1 redirect 4/25 tcp host 192.168.1.67 host 255.255.255.2552 redirect 4/25 udp host 192.168.1.67 host 255.255.255.2553 permit ip any any******* Cisco IOS ACL ***********1 deny ip any host 239.255.255.2552 permit ip any any******* MERGE **********Using the new algorithm - 4 entriesUsing the old algorithm - 4 entriesLayer 4 Operations Configuration Guidelines
These sections provide the guidelines for using Layer 4 port operations:
•
•
Determining Layer 4 Operation Usage
The switch hardware allows you to specify these types of operations:
•
•
•
•
•
We recommend that you do not specify more than nine different operations on the same ACL. If you exceed this number, each new operation might cause the affected ACE to be translated into more than one ACE.
Note
Use the following two guidelines to determine the Layer 4 operation usage:
1.
... gt 10 permit... lt 9 deny... gt 11 deny... neq 6 redirect
Note
2.
... Src gt 10 ...... Dst gt 10
Note
Determining Logical Operation Unit Usage
The LOUs are registers that store the operator/operand couples. All the ACLs use the LOUs. There can be up to 32 LOUs; each LOU can store two different operator/operand couples with the exception of the range operator. The LOU usage per Layer 4 operation is as follows:
•
•
•
•
•
For example, this ACL would use a single LOU to store two different operator/operand couples:
... Src gt 10 ...... Dst gt 10A more detailed example is as follows:
ACL1... (dst port) gt 10 permit... (dst port) lt 9 deny... (dst port) gt 11 deny... (dst port) neq 6 redirect... (src port) neq 6 redirect... (dst port) gt 10 denyACL2... (dst port) gt 20 deny... (src port) lt 9 deny... (src port) range 11 13 permit... (dst port) neq 6 redirectThe Layer 4 operations and LOU usage are as follows:
•
•
•
An explanation of the LOU usage is as follows:
•
•
•
•
Using VACLs in Your Network
These sections describe some typical uses for the VACLs:
•
•
•
•
Wiring Closet Configuration
In a wiring closet configuration, Catalyst 6500 series switches might not be equipped with the MSFCs (routers). In this configuration, the switch can still support a VACL and a QoS ACL. Suppose that Host X and Host Y are in different VLANs and are connected to wiring closet Switch A and Switch C (see Figure 15-4). The traffic from Host X to Host Y is eventually being routed by the switch that is equipped with the MSFC. The traffic from Host X to Host Y can be access controlled at the traffic entry point, Switch A.
If you do not want the HTTP traffic that is switched from Host X to Host Y, you can configure a VACL on Switch A. All HTTP traffic from Host X to Host Y would be dropped at Switch A and not be bridged to the switch with the MSFC.
Figure 15-4 Wiring Closet Configuration
Redirecting Broadcast Traffic to a Specific Server Port
Some application traffic uses the broadcast packets that reach every host in a VLAN. With the VACLs, you can redirect these broadcast packets to the intended application server port.
Figure 15-5 shows an application broadcast packet from Host A being redirected to the target application server port and preventing other ports from receiving the packet.
To redirect the broadcast traffic to a specific server port, perform this task in privileged mode (TCP port 5000 is the intended server application port):
Note
Figure 15-5 Redirecting Broadcast Traffic to a Specific Server Port
Restricting the DHCP Response for a Specific Server
When the Dynamic Host Configuration Protocol (DHCP) requests are broadcast, they reach every DHCP server in the VLAN and multiple responses are returned. With the VACLs, you can restrict the response from a specific DHCP server and drop the other responses.
To restrict the DHCP responses for a specific server, perform this task in privileged mode (the target DHCP server IP address is 1.2.3.4):
Figure 15-6 shows that only the target server returns a DHCP response from the DHCP request.
Figure 15-6 Redirecting a DHCP Response for a Specific Server
Denying Access to a Server on Another VLAN
You can restrict access to a server on another VLAN. For example, server 10.1.1.100 in VLAN 10 needs to have access restricted as follows (seeFigure 15-7):
•
•
To deny access to a server on another VLAN, perform this task in privileged mode:
Figure 15-7 Denying Access to a Server on Another VLAN
Restricting ARP Traffic
Note
The ARP traffic is permitted on each VLAN by default. You can disallow the ARP traffic on a per-VLAN basis using the set security acl ip acl_name deny arp command. When you enter this command, the ARP traffic is disallowed on the VLAN to which the ACL is mapped. To allow the ARP traffic on a VLAN that has had the ARP traffic disallowed, enter the set security acl ip acl_name permit arp command.
Inspecting ARP Traffic
Note
These sections describe the ARP traffic-inspection feature:
•
•
Overview
ARP is a simple protocol that does not have an authentication mechanism, so there is no way to ensure that the ARP requests and replies are genuine. Without an authentication mechanism, a malicious user/host can corrupt the ARP tables of the other hosts on the same VLAN in a Layer 2 network or bridge domain.
For example, user/Host A (the malicious user) can send unsolicited ARP replies (or gratuitous ARP packets) to the other hosts on the subnet with the IP address of the default router and the MAC address of Host A. With some earlier operating systems, even if a host already has a static ARP entry for the default router, the newly advertised binding from Host A is learned. If Host A enables IP forwarding and forwards all packets from the "spoofed" hosts to the router and vice versa, then Host A can carry out a man-in-the-middle attack (for example, using the program dsniff) without the spoofed hosts realizing that all of their traffic is being sniffed.
ARP traffic inspection allows you to configure a set of order-dependent rules within the security ACL (VACL) framework to prevent the ARP table attacks.
Implementation
If a specific rule in ARP traffic inspection exists in the VACL on a VLAN, all ARP packets are index-directed to the CPU through the ACEs in the VACL. The packets are inspected by the ARP traffic-inspection task for conformance to the specified rules. The conforming packets are forwarded while the nonconforming packets are dropped and logged (if logging is enabled).
The rules for ARP traffic inspection specify the ARP bindings for the specified IP addresses as shown in the example that follows:
permit arp-inspection host 10.0.0.1 00-00-00-01-00-02permit arp-inspection host 20.0.0.1 00-00-00-02-00-03deny arp-inspection host 10.0.0.1 anydeny arp-inspection host 20.0.0.1 anypermit arp-inspection any anyThe above set of rules allows only 00-00-00-01-00-02 to be advertised as the MAC address for IP address 10.0.0.1. Similarly, MAC address 00-00-00-02-00-03 is bound to IP address 20.0.0.1. The ARP packets that advertise any other MAC addresses for 10.0.0.1 and 20.0.0.1 are dropped (achieved by the deny actions in lines 3 and 4). All other ARP packets are allowed to go through (achieved by the permit action in line 5).
ARP Traffic-Inspection Configuration Guidelines
This section describes the guidelines for configuring ARP traffic inspection:
•
•
•
•
•
•
•
VACL logging uses the source MAC address and the following fields from the ARP header to define a logging flow: source IP address, source MAC address, and ARP opcode (request, reply).
You can limit the number of logged flows by entering the set security acl log maxflow max_flows command. However, the set security acl log ratelimit max_rate command does not apply to the ARP traffic inspection logged flows.
•
•
•
•
•
•
------------------------------set security acl ip my_arp---------------------------------------------------arp permit1. permit arp-inspection host 10.6.62.86 00-b0-c2-3b-db-fd2. deny arp-inspection host 10.6.62.86 any3. permit arp-inspection any any---------------------------This ACL ensures that only MAC address 00-b0-c2-3b-db-fd is advertised as the MAC address for IP address 10.6.62.86. This ACL will deny all IP packets because there is an implicit ip deny any any in an IP ACL.
If you want all IP traffic to pass through, there should be an explicit permit ip any any at the end of the ACL as follows:
--------------------set security acl ip my_arp---------------------------------------------------arp permit1. permit arp-inspection host 10.6.62.86 00-b0-c2-3b-db-fd2. deny arp-inspection host 10.6.62.86 any3. permit arp-inspection any any4. permit ip any any----------------------•
set security acl ip ACL_VLAN951 permit arp-inspection host 132.216.251.129 00-d0-b7-11-13-14set security acl ip ACL_VLAN951 deny arp-inspection host 132.216.251.129 any logset security acl ip ACL_VLAN951 permit arp-inspection host 132.216.251.250 00-d0-00-ea-43-fcset security acl ip ACL_VLAN951 deny arp-inspection host 132.216.251.250 any logset security acl ip ACL_VLAN951 permit arp-inspection any anyset security acl ip ACL_VLAN951 permit ip any anyARP Traffic-Inspection Configuration Procedures
These sections describe the ARP traffic-inspection configuration procedures:
Configuring ARP Traffic Inspection
•
•
•
•
•
•
•
•
Configuring Rate Limiting for ARP Traffic Inspection
•
•
•
Configuring Logging for ARP Traffic Inspection
•
Permitting or Denying ARP Packets Advertising a Specific IP-Address-to-MAC-Address Binding
To permit or deny the ARP packets that advertise a binding for a specific IP address and MAC address, perform this task in privileged mode:
This example shows how to permit the ARP packets that advertise a binding of IP address 172.20.52.54 to MAC address 00-01-64-61-39-c2:
Console> (enable) set security acl ip ACL1 permit arp-inspection host 172.20.52.54 00-01-64-61-39-c2
Operation successful.
Console> (enable) commit security acl ACL1Console> (enable) ACL commit in progress.
ACL 'ACL1' successfully committed.
Permitting or Denying ARP Packets Advertising a Particular IP Address Binding
To permit or deny the ARP packets that advertise a binding for the specified IP address, perform this task in privileged mode:
This example shows how to permit the ARP packets that advertise a binding of IP address 172.20.52.19:
Console> (enable) set security acl ip ACL2 permit arp-inspection host 172.20.52.19 anyOperation successful.Console> (enable) commit security acl ACL2
Console> (enable) ACL commit in progress.
ACL 'ACL2' successfully committed.
Permitting or Denying All ARP Packets
To permit or deny all ARP packets, perform this task in privileged mode:
Step 1
Permit or deny all ARP packets.
set security acl ip acl_name {permit | deny} arp-inspection any any
Step 2
Commit the VACL.
commit security acl {acl_name | all | adjacency}
This example shows how to permit all ARP packets:
Console> (enable) set security acl ip ACL3 permit arp-inspection any anyOperation successful.Console> (enable) commit security acl ACL3
Console> (enable) ACL commit in progress.
ACL 'ACL3' successfully committed.
Permitting or Denying ARP Packets that Advertise Bindings for IP Addresses on a Particular Network
To permit or deny the ARP packets that advertise a binding for the IP addresses on a particular network, perform this task in privileged mode:
Note
This example shows how to permit the ARP packets that advertise a binding for the IP addresses on the 10.3.5.0/24 subnet:
Console> (enable) set security acl ip ACL4 permit arp-inspection 10.3.5.6 0.0.0.255 anyOperation successful.Console> (enable) commit security acl ACL4
Console> (enable) ACL commit in progress.
ACL 'ACL4' successfully committed.
Dropping Packets Without Matching MAC Addresses
To drop the packets where the source Ethernet MAC address (in the Ethernet header) is not the same as the source MAC address in the ARP header, perform this task in privileged mode. If you do not specify the drop keyword, the packet is not dropped but a syslog message is displayed. Use the log keyword to send the packets to the VACL logging facility.
Tip
This example shows how to drop the packets where the source Ethernet MAC address is not the same as the source MAC address in the ARP header:
Console> (enable) set security acl arp-inspection match-mac enable dropARP Inspection match-mac feature enabled with drop option.Console> (enable)Console> (enable) show security acl arp-inspection configMatch-mac feature is enabled with drop option.Address-validation feature is disabled.Dynamic ARP Inspection is disabled on vlan(s) 1.Dynamic ARP Inspection is disabled on ports 5/1-48,7/1-2.Logging for Dynamic ARP Inspection rules is disabled.Console> (enable)Dropping Packets with Invalid MAC or IP Addresses
The following MAC addresses are invalid:
•
•
•
The following IP addresses are invalid:
•
•
•
To drop the packets with invalid MAC or IP addresses, perform this task in privileged mode (if you do not specify the drop keyword, the packet is not dropped but a syslog message is displayed):
This example shows how to drop the packets with the invalid MAC or IP addresses:
Console> (enable) set security acl arp-inspection address-validation enable dropARP Inspection address-validation feature enabled with drop option.Console> (enable)Console> (enable) show security acl arp-inspection configAddress-validation feature is enabled with drop option.Console> (enable)Displaying ARP Traffic-Inspection Statistics
To display the number of packets that are permitted and denied by the ARP traffic-inspection task, perform this task in normal mode:
Display the number of packets that are permitted and denied by the ARP traffic-inspection task.
show security acl arp-inspection statistics [acl_name]
Note
This example shows how to display the number of packets that are permitted and denied by the ARP traffic-inspection task:
Console> (enable) show security acl arp-inspection statisticsARP Inspection statisticsPackets forwarded = 0Packets dropped = 0RARP packets (forwarded) = 0Packets for which Match-mac failed = 0Packets for which Address Validation failed = 0IP packets dropped = 0Console> (enable)Clearing the ARP Traffic-Inspection Statistics
To clear the ARP traffic-inspection statistics, perform this task in privileged mode:
Clear the ARP traffic-inspection statistics.
clear security acl arp-inspection statistics [acl_name]
Without the optional argument, entering the command clears the ARP traffic-inspection global statistics counters and the ARP traffic-inspection statistics counters for all the ACLs. If you supply the optional acl_name argument, only the ARP traffic-inspection statistics for that particular ACL are cleared.
Note
Configuring Rate Limiting on a Global Basis
You can rate limit the number of ARP traffic-inspection packets that are sent to the supervisor engine CPU globally. By default, the ARP traffic-inspection traffic is rate limited to 500 packets per second. The minimum value is 500, and the maximum value is 2000 packets per second. For Supervisor Engine 720, the minimum value that is enforced by the hardware is 10 packets per second (values between 1- 9 are set to 10). To disable rate limiting, set the value to 0.
Note
To rate limit the number of ARP traffic-inspection packets that are sent to the CPU on a global basis, perform this task in privileged mode:
This example shows how to rate limit the number of ARP traffic-inspection packets that are sent to the CPU to 1000:
Console> (enable) set security acl feature ratelimit 1000Dot1x DHCP and ARP Inspection global rate limit set to 1000 pps.Console> (enable)Console> (enable) show security acl feature ratelimitRate limit value in packets per second = 1000Protocols set for rate limiting = Dot1x DHCP, ARP InspectionConsole> (enable)Console> (enable) show rate-limitConfigured Rate Limiter Settings:Rate Limiter Type Status Rate (pps) Burst-------------------- ------ -------------- -----VACL LOG On 2500 1ARP INSPECTION On 1000 1FIB RECEIVE Off * *FIB GLEAN Off * *L3 SEC FEATURES Off * *Console> (enable)Configuring Rate Limiting on a Per-Port Basis
You can rate limit the number of ARP traffic-inspection packets that are sent to the supervisor engine CPU on a per-port basis. If the rate exceeds the drop-threshold, the excess packets are dropped (and counted toward the shutdown-threshold limit). If the rate exceeds the shutdown-threshold, the port that is specified by mod/port is shut down. By default, both threshold values are 0 (no per-port rate limiting is applied). The maximum value for both thresholds is 1000 packets-per second (pps).
To rate limit the number of ARP traffic-inspection packets that are sent to the CPU per port, perform this task in privileged mode:
This example shows how to rate limit the number of ARP traffic-inspection packets that are sent to the CPU on a per-port basis. The drop-threshold is set to 700, and the shutdown threshold is set to 800 for port 3/1:
Console> (enable) set port arp-inspection 3/1 drop-threshold 700 shutdown-threshold 800Drop Threshold=700, Shutdown Threshold=800 set on port 3/1.Console> (enable)Console> (enable) show port arp-inspection 3/1Port Drop Threshold Shutdown Threshold------------------------ -------------- ------------------3/1 700 800Console> (enable)Configuring the errdisable-timeout Option for ARP Traffic Inspection
You configure the errdisable-timeout option for ARP traffic inspection by using the set errdisable-timeout {enable | disable} arp-inspection command. For detailed information on the errdisable-timeout option, see the "Configuring a Timeout Period for Ports in errdisable State" section on page 4-12.
Configuring Logging for ARP Traffic Inspection
To configure the logging option to log the ARP traffic-inspection packets that are dropped, perform this task in privileged mode:
Log the ARP traffic-inspection packets that are dropped.
set security acl ip acl_name deny arp-inspection {host ip_address {any | mac_address} | ip_address ip_mask any | any any} [log]
For detailed information on the VACL logging option, see the "Configuring VACL Logging" section. This section also provides information on limiting the number of logged flows using the set security acl log maxflow max_number command.
To display the logged ARP traffic-inspection packets, perform this task in normal mode:
Display the logged ARP traffic-inspection packets.
show security acl log flow arp [host ip_address [vlan vlan]]
If you specify the optional host IP address, only the ARP packets that advertise a binding for the specified host IP address are displayed. If you specify the optional vlan vlan keyword and argument, the search is restricted to the specified VLAN.
Dynamic ARP Inspection
Note
These sections describe DAI:
•
Overview
DAI uses the binding information that is built by DHCP snooping to enforce the advertisement of bindings to prevent "man-in-the-middle" attacks. These attacks can occur when an attacker intercepts and selectively modifies communicated data to masquerade as one or more of the entries in a communication association. DAI adds an extra layer of security to ARP inspection by verifying that the ARP packet's MAC address and IP address match an existing DHCP snooping binding in the same VLAN. The basic functionality and packet flow of ARP inspection remains unchanged except for the addition of checks to ensure that a DHCP binding exists (see Figure 15-8 for a logical flow chart).
Figure 15-8 Dynamic ARP Inspection Flow Chart
Note
When you create a security ACL, you need to be careful because the statically configured ARP inspection rules have a higher priority than the DAI checks of the DHCP bindings. Do not put a permit arp-inspection any any clause in the security ACL because it will prevent any checks from occurring.
You can enable or disable DAI on a per-VLAN basis. If you configure the DAI ports as untrusted, you must also configure them as DHCP-snooping untrusted ports. You should enable DHCP snooping in all VLANs that have DAI enabled. Optionally, you can enable logging for the ARP packets that are denied by DAI.
Note
If the static IP address assignments exist in a VLAN, you must configure the relevant ports as ARP inspection-trusted ports or you must configure the static ARP inspection nubs to permit these MAC and IP addresses.
Dynamic ARP Inspection Configuration Procedures
Note
Note
Before you configure DAI, you will need to enable dynamic ARP inspection on a per-port basis. Perform this task in privileged mode:
Note
Note
This example shows how to enable dynamic ARP on port 1/48:
Console> (enable) set port security-acl 1/48 port-basedWarning: Vlan-based ACL features will be disabled on ports 1/48ACL interface is set to port-based mode for port(s) 1/48.Console> (enable) set security acl arp-inspection dynamic enable port 1/48Dynamic ARP Inspection enabled on port 1/48.Console> (enable) show security acl arp-inspection configMatch-mac feature is disabled.Address-validation feature is disabled.Dynamic ARP Inspection is disabled on vlan(s) 1-20,50.Dynamic ARP Inspection is enabled on ports 1/48.Dynamic ARP Inspection is disabled on ports 1/1-47,4/1-48,5/1-2.Logging for Dynamic ARP Inspection rules is disabled.Console> (enable) set security acl ip dai permit dhcp-snoopingSuccessfully configured DHCP Snooping for ACL dai. Use 'commit' command to savechanges.Console> (enable) set security acl ip dai permit arp-inspection any anydai editbuffer modified. Use 'commit' command to apply changes.Console> (enable) set security acl ip dai permit ip any anydai editbuffer modified. Use 'commit' command to apply changes.Console> (enable) commit security acl daiConsole> (enable) ACL commit in progress.ACL 'dai' successfully committed.Console> (enable) set security acl map dai 1/48Mapping in progress.To configure DAI, perform this task in privileged mode:
This example shows how to enable DAI on VLAN 100:
Console> (enable) set security acl arp-inspection dynamic enable 100Dynamic ARP Inspection is enabled for vlan(s) 100.Console> (enable) set port arp-inspection 2/2 trust enablePort(s) 2/2 state set to trusted for ARP Inspection.Console> (enable) set security acl arp-inspection dynamic log enableDynamic ARP Inspection logging enabled.Console> show security acl arp-inspection configMatch-mac feature is disabled.Address-validation feature is disabled.Dynamic ARP Inspection is disabled on vlan(s) 1,1006-1013.Dynamic ARP Inspection is enabled on vlan(s) 100.Logging for Dynamic ARP Inspection rules is enabled.Console>Configuring ACLs on Private VLANs
Private VLANs allow you to split a primary VLAN into sub-VLANs (secondary VLANs) that can be either community VLANs or isolated VLANs. In releases prior to software release 6.1(1), you could configure ACLs on a primary VLAN only and the ACL would then be applied to all the secondary VLANs. In software release 6.1(1) and later releases, ACLs can be applied as follows:
•
•
•
•
•
If you map a VACL to a primary VLAN, it filters the traffic from the router to the host and if you map a VACL to a secondary VLAN, it filters the traffic from the host to the router.
Note
Note
Capturing Traffic Flows
See the "Capturing Traffic Flows on Specified Ports" section for complete configuration details.
Unsupported Features
Note
This section lists the ACL-related features that are not supported or have limited support on the Catalyst 6500 series switches:
•
–
–
–
–
–
–
–
–
–
–
•
•
Configuring VACLs
This section describes how to configure the VACLs. Prior to performing any configuration tasks, see the "VACL Configuration Guidelines" section.
These sections provide the guidelines and a summary for configuring the VACLs:
•
•
VACL Configuration Guidelines
This section describes the guidelines for configuring the VACLs:
Caution
Note
Note
•
•
•
•
•
•
•
•
•
•
•
•
•
–
–
–
–
–
VACL Configuration Summary
To create a VACL and map it to a VLAN, perform these steps:
Step 1
Step 2
Step 3
Note
Note
Configuring VACLs from the CLI
This section describes how to create and activate the VACLs on the Catalyst 6500 series switches. These tasks are listed in the order that they should be performed.
This section describes the following tasks:
•
•
•
•
•
•
•
•
•
•
Specifying the ACL-Merge Algorithm
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 the releases prior to software release 7.1(1). With ODM, after the merge, the resultant ACEs are order dependent. With BDD, after the merge, the resultant ACEs are order independent.
Note
Note
The default algorithm is ODM. If BDD is disabled, the merge algorithm can only be ODM. When BDD is enabled, you can choose either the BDD algorithm or the ODM algorithm. You must enable BDD to change the ACL merge algorithm. Use the set aclmerge bdd command to enable or disable BDD. When you enable or disable BDD, the change takes effect when your system is restarted.
Caution
The ACL merge algorithm that you select is in effect for all new ACL merges. The ACLs that are already configured are not modified and use the ACL merge algorithm that was enabled when the ACLs were merged.
To enable or disable BDD, perform this task in privileged mode:
This example shows how to disable BDD:
Console> (enable) set aclmerge bdd disableBdd will be disabled on system restart.Console> (enable)This example shows how to display the current BDD status and whether BDD will be enabled or disabled at the next system restart:
Console> (enable) show aclmerge bddBdd is not enabled.On system restart bdd will be disabled.Console> (enable)To specify the ACL-merge algorithm, perform this task in privileged mode:
Step 1
Specify the ACL-merge algorithm.
set aclmerge algo {bdd | odm}
Step 2
Display the ACL-merge algorithm that is currently in use.
show aclmerge {bdd | algo}
This example shows how to specify the ODM algorithm:
Console> (enable) set aclmerge algo odmAcl merge algorithm set to odm.Console> (enable)This example shows the ACL-merge algorithm that is currently in use:
Console> (enable) show aclmerge algoCurrent acl merge algorithm is odm.Console> (enable)Creating an IP VACL and Adding ACEs
To create a new IP VACL and add the ACEs, or to add the ACEs to an existing IP VACL, perform one of these tasks in privileged mode:
If an IP protocol specification is not required, use the following syntax.
set security acl ip {acl_name} {permit | deny} {src_ip_spec} [capture]
[before editbuffer_index | modify editbuffer_index] [log1 ]If an IP protocol is specified, use the following syntax.
set security acl ip {acl_name} {permit | deny | redirect mod_num/
port_num} {protocol} {src_ip_spec} {dest_ip_spec} [precedence precedence] [tos tos] [capture] [before editbuffer_index | modify editbuffer_index] [log1]
1 The log keyword provides logging messages for denied IP VACLs only.
This example shows how to create an ACE for IPACL1 to allow the traffic from source address 172.20.53.4:
Console> (enable) set security acl ip IPACL1 permit host 172.20.53.4 0.0.0.0IPACL1 editbuffer modified. Use `commit' command to apply changes.Console> (enable)
Note
This example shows how to create an ACE for IPACL1 to allow the traffic from all source addresses:
Console> (enable) set security acl ip IPACL1 permit anyIPACL1 editbuffer modified. Use `commit' command to apply changes.Console> (enable)This example shows how to create an ACE for IPACL1 to block the traffic from source address 171.3.8.2:
Console> (enable) set security acl ip IPACL1 deny host 171.3.8.2IPACL1 editbuffer modified. Use `commit' command to apply changes.Console> (enable)This example shows how to display the contents of the edit buffer:
Console> (enable) show security acl info IPACL1 editbufferset security acl ip IPACL1-----------------------------------------------------------------1. permit ip host 172.20.53.4 any2. permit ip any any3. deny ip host 171.3.8.2 anyConsole> (enable)This example shows how to commit the ACEs to NVRAM:
Console> (enable) commit security acl allACL commit in progress.ACL IPACL1 is committed to hardware.Console> (enable)
Note
Enter the show security acl info IPACL1 command to verify that the changes were committed. If this VACL has not been mapped to a VLAN, enter the set security acl map command to map it to a VLAN.
This example shows how to create an ACE for IPACL2 to block the traffic from source address 172.20.3.2 and place this ACE before ACE number 2 in the VACL. Optionally, you can enter the modify keyword to replace an existing ACE with a new ACE. Enter the show security acl info acl_name [editbuffer] command to see the current ACE listing that is stored in NVRAM (enter the editbuffer keyword to see edit buffer contents).
Console> (enable) set security acl ip IPACL2 deny host 172.20.3.2 before 2IPACL2 editbuffer modified. Use `commit' command to apply changes.Console> (enable)This example shows how to create an ACE for IPACL2 to redirect IP traffic to port 3/1 from source address 1.2.3.4 with the destination address of 255.255.255.255. The host can be used as an abbreviation for a source and source-wildcard of 0.0.0.0. This ACE also specifies the following:
•
•
Note
Console> (enable) set security acl ip IPACL2 redirect 3/1 ip 1.2.3.4 0.0.0.255 host 255.255.255.255 precedence 1 tos min-delayIPACL2 editbuffer modified. Use `commit' command to apply changes.Console> (enable)This example shows how to display the contents of the edit buffer:
Console> (enable) show security acl info IPACL2 editbufferset security acl ip IPACL2-----------------------------------------------------------------1. deny 172.20.3.22. redirect 1.2.3.4Console> (enable)
Note
This example shows how to commit the ACEs to NVRAM:
Console> (enable) commit security acl allACL commit in progress.ACL IPACL2 is committed to hardware.Console> (enable)
Note
Enter the show security acl info IPACL2 command to verify that the changes were committed. If this VACL has not been mapped to a VLAN, enter the set security acl map command to map it to a VLAN.
Creating an IPX VACL and Adding ACEs
Note
To create a new IPX VACL and add the ACEs, or to add the ACEs to an existing IPX VACL, perform this task in privileged mode:
This example shows how to create an ACE for IPXACL1 to block all traffic from source network 1234:
Console> (enable) set security acl ipx IPXACL1 deny any 1234IPXACL1 editbuffer modified. Use `commit' command to apply changes.Console> (enable)This example shows how to create an ACE for IPXACL1 to block all traffic with destination address 1.A.3.4:
Console> (enable) set security acl ipx IPXACL1 deny any any 1.A.3.4IPXACL1 editbuffer modified. Use `commit' command to apply changes.Console> (enable)This example shows how to create an ACE for IPXACL1 to redirect broadcast traffic to port 4/1 from source network 3456:
Console> (enable) set security acl ipx IPXACL1 redirect 4/1 any 3456IPXACL1 editbuffer modified. Use `commit' command to apply changes.Console> (enable)This example shows how to display the contents of the edit buffer:
Console> (enable) show security acl info IPXACL1 editbufferset security acl ipx IPXACL1-----------------------------------------------------------------1. deny any 12342. deny any any 1.A.3.43. redirect 4/1 any 3456Console> (enable)
Note
This example shows how to commit the ACEs to NVRAM:
Console> (enable) commit security acl allACL commit in progress.ACL IPXACL1 is committed to hardware.Console> (enable)Enter the show security acl info IPXACL1 command to verify that the changes were committed. If this VACL has not been mapped to a VLAN, enter the set security acl map command to map it to a VLAN.
This example shows how to create an ACE for IPXACL1 to allow all traffic from source network 1 and insert this ACE before ACE number 2:
Console> (enable) set security acl ipx IPXACL1 permit any 1 before 2IPXACL1 editbuffer modified. Use `commit' command to apply changes.Console> (enable)This example shows how to create an ACE for IPXACL1 to allow the traffic from all source addresses:
Console> (enable) set security acl ipx IPXACL1 permit any anyIPXACL1 editbuffer modified. Use `commit' command to apply changes.Console> (enable)This example shows how to display the contents of the edit buffer:
Console> (enable) show security acl info IPXACL1 editbufferset security acl ipx IPXACL1-----------------------------------------------------------------1. deny any 12342. permit any 13. deny any any 1.A.3.44. redirect 4/1 any 34565. permit any anyACL IPXACL1 Status: Not CommittedConsole> (enable)This example shows how to commit the ACEs to NVRAM:
Console> (enable) commit security acl allACL commit in progress.ACL IPXACL1 is committed to hardware.Console> (enable)
Note
Enter the show security acl info IPXACL1 command to verify that the changes were committed. If this VACL has not been mapped to a VLAN, enter the set security acl map command to map it to a VLAN.
Creating a Non-IP Version 4/Non-IPX VACL (MAC VACL) and Adding ACEs
Caution
To create a new non-IP version 4/non-IPX VACL and add the ACEs, or to add the ACEs to an existing non-IP version 4/non-IPX VACL, perform this task in privileged mode:
This example shows how to create an ACE for MACACL1 to block all traffic from 8-2-3-4-7-A:
Console> (enable) set security acl mac MACACL1 deny host 8-2-3-4-7-A anyMACACL1 editbuffer modified. Use `commit' command to apply changes.Console> (enable)This example shows how to create an ACE for MACACL1 to block all traffic to A-B-C-D-1-2:
Console> (enable) set security acl mac MACACL1 deny any host A-B-C-D-1-2MACACL1 editbuffer modified. Use `commit' command to apply changes.Console> (enable)This example shows how to create an ACE for MACACL1 to allow the traffic from all sources:
Console> (enable) set security acl mac MACACL1 permit any anyMACACL1 editbuffer modified. Use `commit' command to apply changes.Console> (enable)This example shows how to display the contents of the edit buffer:
Console> (enable) show security acl info MACACL1 editbufferset security acl mac MACACL1-----------------------------------------------------------------1. deny 8-2-3-4-7-A any2. deny any A-B-C-D-1-23. permit any anyConsole> (enable)
Note
This example shows how to commit the ACEs to NVRAM:
Console> (enable) commit security acl allACL commit in progress.ACL MACACL1 is committed to hardware.Console> (enable)
Note
Enter the show security acl info MACACL1 command to verify that the changes were committed. If this VACL has not been mapped to a VLAN, enter the set security acl map command to map it to a VLAN.
Committing ACLs
You can commit all ACLs or a specific ACL to NVRAM with the commit command. Any committed ACL with no ACEs will be deleted.
To commit an ACL to NVRAM, perform this task in privileged mode:
This example shows how to commit a specific security ACL to NVRAM:
Console> (enable) commit security acl IPACL2ACL commit in progress.ACL IPACL2 is committed to hardware.Console> (enable)Mapping a VACL to a VLAN
You can map a VACL to a VLAN with the set security acl map command. Note that there is no default ACL-to-VLAN mapping; all VACLs need to be mapped to a VLAN.
To map a VACL to a VLAN, perform this task in privileged mode:
This example shows how to map IPACL1 to VLAN 10:
Console> (enable) set security acl map IPACL1 10ACL IPACL1 mapped to vlan 10Console> (enable)This example shows the output if you try to map an ACL that has not been committed:
Console> (enable) set security acl map IPACL1 10Commit ACL IPACL1 before mapping.Console> (enable)Displaying the Contents of a VACL
You can display the contents of a VACL with the show security acl info command.
To display the contents of a VACL, perform this task in privileged mode:
Display the contents of a VACL.
show security acl info {acl_name | all} [editbuffer [editbuffer_index]]
This example shows how to display the contents of a VACL that has been saved in NVRAM:
Console> (enable) show security acl info IPACL1set security acl ip IPACL1------------------------------------------------------------------1. deny A2. deny ip B any3. deny c4. permit anyThis example shows how to display the contents of a VACL that is still in the edit buffer:
Console> (enable) show security acl info IPACL1 editbufferset security acl ip IPACL1-----------------------------------------------------------------1. deny A2. deny ip B any3. deny C4. deny D5. permit anyConsole> (enable)Displaying a VACL-to-VLAN Mapping
You can display a VACL-to-VLAN mapping for a specified ACL or VLAN with the show security acl map command.
To display a VACL-to-VLAN mapping, perform this task in privileged mode:
This example shows how to display the mappings of a specific VACL:
Console> (enable) show security acl map IPACL1ACL IPACL1 is mapped to VLANs:1Console> (enable)This example shows how to display the mappings of a specific VLAN:
Console> (enable) show security acl map 1VLAN 1 is mapped to IP ACL IPACL1.VLAN 1 is mapped to IPX ACL IPXACL1.VLAN 1 is mapped to MAC ACL MACACL1.Console> (enable)Clearing the Edit Buffer
You can clear the changes made to the ACL edit buffer since its last save with the rollback command. The ACL is rolled back to its state at the last commit command.
To clear the ACL edit buffer, perform this task in privileged mode:
This example shows how to clear the edit buffer of a specific security ACL:
Console> (enable) rollback security acl IPACL1Editbuffer for `IPACL1' rolled back to last commit state.Console> (enable)Removing ACEs from Security ACLs
You can remove a specific ACE or all ACEs from an ACL with the clear security acl command. This command deletes the ACEs from the edit buffer.
To remove an ACE from a security ACL, perform this task in privileged mode:
Remove an ACE from a security ACL.
clear security acl all
clear security acl acl_name
clear security acl acl_name editbuffer_index
This example shows how to remove the ACEs from all the ACLs:
Console> (enable) clear security acl allAll editbuffers modified. Use `commit' command to apply changes.Console> (enable)This example shows how to remove a specific ACE from a specific ACL:
Console> (enable) clear security acl IPACL1 2IPACL1 editbuffer modified. Use `commit' command to apply changes.Console> (enable)Clearing the Security ACL Map
You can remove a VACL-to-VLAN mapping with the clear security acl map command.
To clear the security ACL map, perform this task in privileged mode:
Clear the security ACL map.
clear security acl map all
clear security acl map acl_name
clear security acl map vlan
clear security acl map acl_name vlan
This example shows how to clear all VACL-to-VLAN mappings:
Console> (enable) clear security acl map allMap deletion in progress.Successfully cleared mapping between ACL ip1 and VLAN 10.Successfully cleared mapping between ACL ipx1 and VLAN 10..... display text omittedConsole> (enable)This example shows how to clear the mapping for a specific VACL on a specific VLAN:
Console> (enable) clear security acl map IPACL1 50Map deletion in progress.Successfully cleared mapping between ACL ipacl1 and VLAN 50.Console> (enable)Displaying VACL Management Information
You can display VACL management information with the show security acl resource-usage command.
To display VACL management information, perform this task in privileged mode:
This example shows how to display VACL management information:
Console> (enable) show security acl resource-usageACL resource usage:ACL storage (mask/value): 0.29%/0.10%ACL to switch interface mapping table: 0.39%ACL layer 4 port operators: 0.0%Console (enable)Capturing Traffic Flows on Specified Ports
You can enter the capture keyword in the set security acl (ip, ipx, and mac) commands to specify that the packets that match the specified flows are captured and transmitted out of the capture ports. You can specify the capture ports using the set security acl capture-ports mod/ports... command. When you use the capture keyword, the packets that match the specified flows are captured in parallel and transmitted out of the capture ports. The capture ports do not send out all the captured traffic; they send out only the traffic belonging to the VLANs of the captured port.
Configuration Guidelines
This section describes the guidelines for configuring the capture ports:
•
•
•
•
•
•
For the routed traffic, the capture ports transmit the packets only after they are Layer 3 switched; the packets are transmitted out of a port only if the output VLAN of the Layer 3-switched flow is the same as the capture port VLAN. For example, assume that you have flows from VLAN 10 to VLAN 20, you add a VACL on one of the VLANs permitting these flows, and you specify a capture port. This traffic gets transmitted out of the capture port only if it belongs to VLAN 20 or if the port is a trunk carrying VLAN 20. If the capture port is in VLAN 10, it does not transmit any traffic. Whether a capture port transmits the traffic or not is independent of the VLAN on which you placed the VACL.
If you want to capture the traffic from one VLAN going to many VLANs, the capture port has to be a trunk carrying all the output VLANs.
For the bridged traffic, because all the traffic remains in the same VLAN, ensure that the capture port is in the same VLAN as the bridged traffic.
•
To capture the traffic flows, perform these steps:
Note
version 4/non-IPX VACLs using the same basic steps.
Step 1
Step 2
Step 3
Step 4
Configuration Examples
This example shows how to create an ACE for my_cap and specify that the allowed traffic is captured:
Console> (enable) set security acl ip my_cap permit ip host 60.1.1.1 host 60.1.1.98 capturemy_cap editbuffer modified. Use 'commit' command to apply changes.Console> (enable)This example shows how to commit the my_cap ACL to NVRAM:
Console> (enable) commit security acl my_capACL commit in progress.ACL my_cap successfully committed.Console> (enable)This example shows how to map my_cap to VLAN 10:
Console> (enable) set security acl map my_cap 10Mapping in progress.VLAN 10 successfully mapped to ACL my_cap.The old mapping with ACL captest was replaced with the new one.Console> (enable)This example shows how to specify the capture ports:
Console> (enable) set security acl capture-ports 1/1-2,2/1-2Successfully set the following ports to capture ACL traffic:1/1-2,2/1-2Console> (enable)This example shows how to display the ports that have been specified as the capture ports:
Console> (enable) show security acl capture-portsACL Capture Ports: 1/1-2,2/1-2Console> (enable)This example shows how to clear the capture ports:
Console> (enable) clear security acl capture-ports 1/1,2/1Successfully cleared the following ports:1/1,2/1Console> (enable)This example shows that ports 1/1 and 2/1 were cleared:
Console> (enable) show security acl capture-portsACL Capture Ports:1/2,2/2Console> (enable)Configuring VACL Logging
Note
You can log the messages about the denied packets for the standard IP access list by entering the log keyword for the deny VACLs. Any packet that matches the access list causes an informational logging message about the packet to be sent to the console. The level of messages that is logged to the console is controlled by the set logging level acl severity command.
The first packet that triggers the access list causes a logging message right away, and the subsequent packets are collected over 5-minute intervals before they are displayed or logged. The logging message includes the flow pattern and the number of packets that are received in the past 5 minutes.
By default, the system logging messages are sent to the console. You can configure the switch to send the system logging messages to a syslog server. For information on configuring system message logging, see Chapter 29, "Configuring System Message Logging."
Configuration Guidelines
This section describes the guidelines for configuring VACL logging:
•
•
To enable VACL logging, perform these steps:
Step 1
Step 2
Note
Step 3
Note
Step 4
Step 5
Step 6
Configuration Examples
This example shows how to set the logging level:
Console> (enable) set logging level acl 6System logging facility <acl> for this session set to severity 6(information)This example shows how to allocate a new log table that is based on the maximum flow:
Console> (enable) set security acl log maxflow 512Set VACL Log table to 512 flow patterns.This example shows how to set the redirect rate:
Console> (enable) set security acl log ratelimit 1000Max logging eligible packet rate set to 1000pps.This example shows how to display the VACL log configuration:
Console> (enable) show security acl log configVACL LOG Configration-------------------------------------------------------------Max Flow Pattern : 512Max Logging Eligible rate (pps) : 1000This example shows how to create an ACE for my_cap and specify that the denied traffic is logged:
Console> (enable) set security acl ip my_cap deny ip host 21.0.0.1 logmy_cap editbuffer modified. Use 'commit' command to apply changes.Console> (enable)This example shows how to commit the my_cap ACL to NVRAM:
Console> (enable) commit security acl my_capACL commit in progress.ACL my_cap successfully committed.Console> (enable)This example shows how to map the VACL to a VLAN:
Console> (enable) set security acl map my_cap 1Mapping in progress.ACL my_cap successfully mapped to VLAN 1.::2000 Jul 19 01:14:06 %ACL-6-VACLLOG:VLAN 1(Port 2/1) denied ip tcp 21.0.0.1(2000) -> 255.255.255.255(3000), 1 packet2000 Jul 19 01:19:06 %ACL-6-VACLLOG:VLAN 1(Port 2/1) denied ip tcp 21.0.0.1(2000) -> 255.255.255.255(3000), 7 packets2000 Jul 19 01:25:06 %ACL-6-VACLLOG:VLAN 1(Port 2/2) denied ip tcp 21.0.0.1(2000) -> 255.255.255.255(3000), 1 packetsThis example shows how to display the flow information in the log table:
Console> (enable) show security acl log flow ip any anyTotal matched entry number = 1Entry No. #1, IP Packet----------------------------------------Vlan Number : 1Mod/Port Number : 2/1Source IP address : 21.0.0.1Destination IP address : 255.255.255.255TCP Source port : 2000TCP Destination port : 3000Received Packet Number : 10This example shows how to clear the log table:
Console> (enable) clear security acl log flowLog table is cleared.Console> (enable)Configuring MAC-Based ACL Lookups for All Packet Types
Note
These sections describe how to configure the MAC-based ACL lookups for all packet types:
•
•
•
Overview of MAC-Based ACLs
PFC3A supports two ACL protocol types, IP and MAC. The IP ACL matches only the IP version 4 packets and the MAC ACL matches all packet types unsupported by PFC3A (for more information, see the "Creating a Non-IP Version 4/Non-IPX VACL (MAC VACL) and Adding ACEs" section). The packet types that are supported by PFC3A are as follows: IP version 4, MPLS, ARP/RARP, and IP version 6. However, only IP version 4 ACLs can be created in software release 8.4(1) and earlier releases. The unsupported packet types, such as the IPX packet types, are matched using the MAC ACL.
Note
Using MAC-Based ACL Lookups for All Packet Types
PFC3B and PFC3BXL allow the ACL lookups on all packet types using the MAC ACL. This feature is useful for doing MAC-based matching on all packets regardless of whether the packet is IP version 4, IP version 6, IPX, MPLS, and so on. You can utilize this feature to rate limit all traffic ingressing a VLAN to some specific value by coupling an aggregate policer with a match-all MAC ACL.
This feature is enabled on a per-ingress VLAN basis and affects the security ACLs (VACLs) and the QoS ACLs. When this feature is enabled on an incoming VLAN, all packets coming in on that VLAN are matched against the MAC-based ACLs, even if they are, for example, IP version 4 packets.
The ethertype option has been extended in MAC ACLs to include the IP version 4 EtherType that allows you to set up an ACE to specifically target the IP version 4 packets.
Including the VLAN and CoS in MAC-Based ACLs
With PFC3B and PFC3BXL, you can include the CoS and the VLAN as part of the MAC ACL lookup key that provides support for port-VLAN lookups. This capability is useful on trunk ports where each VLAN can be treated independently. This enhancement affects the VACLs and the QoS MAC ACLs. PFC3B and PFC3BXL overload the VLAN field with the frame type field in the MAC lookup key. Because CoS and VLAN fields are maskable, both fields are added as optional parameters that allow support for the old MAC ACL configurations.
VLAN Matching
With PFC3B and PFC3BXL, if the MAC ACL is mapped to the input, the packet's input VLAN is used to match against the MAC ACL. Similarly, if the MAC ACL is mapped to the output, the output VLAN that is associated with the packet is used to match against the MAC ACL.
Note
VLAN matching can be used in with, or independent of, the MAC-based ACL lookup feature and can do lookups on a port-VLAN basis (the entire VLAN range is supported).
CoS Matching
In both the ingress and egress cases, the CoS that is used to match against the MAC ACL is the input CoS that is associated with the packet. The input CoS is the CoS in the DBus header and is constructed after consulting the port trust (trust-CoS/DSCP/IPprec/untrusted), the default CoS, and the CoS-to-CoS mapping table for the 802.1Q-enabled ports.
Note
CoS matching can be used with, or independent of, the MAC-based ACL lookup feature.
Configuration Guidelines
Use the following guidelines when configuring MAC-based ACL lookups:
•
•
–
Warning:IP RACLs, VACLs & some IP features will be ineffective on these vlans.–
Configuring MAC-Based ACL Lookups for All Packet Types
The commands described in this section affect both VACLs and QoS MAC ACLs. The set acl mac-packet-classify vlans command enables the MAC lookup for all packet types incoming on the source VLAN. The clear acl mac-packet-classify [vlans] command reverts the configuration back to the default for the specified VLAN. The default behavior is to match only MAC packets with MAC ACLs. If you do not specify a VLAN with the clear acl mac-packet-classify [vlans] command, the feature is disabled for all VLANs. The show acl mac-packet-classify command displays the list of VLANs that have the MAC packet classify feature enabled.
Include CoS, VLAN and Packet Type in MAC ACLs and Extend EtherType
The VACL and QoS ACL CLI has been enhanced to include optional parameters for matching on the CoS and VLAN. The commands are as follows:
Usage: set security acl mac {acl_name} {permit | deny}<src_mac_addr_spec> <dest_mac_addr_spec>[<ethertype>] [capture][cos <cos_value>][vlan <vlan>][before <editbuffer_index>|modify <editbuffer_index>](mac_addr_spec = <addr> <mask> or host <addr> or anyexample: 11-22-33-44-00-00 00-00-00-00-ff-ff, host 11-22-33-44-55-66)ethertype = names or 0x0, 0x05ff - 0xffff,cos_value = 0..7, vlan = 1..4094,Usage: set qos acl mac {acl_name} {dscp dscp | trust-cos}[aggregate <aggregate_name>]<src_mac_addr_spec> <dest_mac_addr_spec> [<ethertype>][cos <cos_value>][vlan <vlan>][before <editbuffer_index>|modify <editbuffer_index>](mac_addr_spec = <addr> <mask> or host <addr> or anyexample: 11-22-33-44-00-00 00-00-00-00-ff-ff, host 11-22-33-44-55-66)ethertype = names or 0x0, 0x05ff - 0xffff,cos_value = 0..7, vlan = 1..4094,The CoS and VLAN fields are optional and if left unspecified, they will match any CoS or VLAN value.
Note
Note
The EtherType has been extended to include an IP version 4 option to allow you to specifically target the IP version 4 packets using the MAC ACL lookup. If you select the IP version 4 option, you must ensure that the corresponding VLAN is enabled using the set acl mac-packet-classify vlans command. The IP version 4 option was added as follows:
Console> (enable) set security acl mac macacl1 permit any any ?<0x0, 0x0600 - 0xffff> Match an EtherType valueipv4 (0x8000)ipx-arpa (0x8137) Use 0xffff to match on non-arpa IPX.......Console> (enable)This example shows the MAC-based ACL lookup CLI:
Console> (enable) set acl mac-packet-classify 5Enabled mac-packet-classify on vlan(s) 5.Warning:IP RACLs, VACLs & some IP features will be ineffective on these vlans.Console> (enable) show acl mac-packet-classifyFeature enabled on source vlan(s) 1,5.Console> (enable) clear acl mac-packet-classify 5Disabled mac-packet-classify on vlan(s) 5.Console> (enable)
Note
Configuring and Storing VACLs and QoS ACLs in Flash Memory
This section describes how to configure and store the VACLs and the QoS ACLs in flash memory instead of NVRAM. Before this feature, all configuration information was stored in NVRAM. With the addition of the QoS and security ACLs (VACLs), NVRAM could become full. In addition to limiting the ACL configuration, filling up NVRAM can cause problems when you attempt to upgrade from one software version to another.
Note
This section describes these tasks:
•
•
•
•
•
•
Note
Automatically Moving the VACL and QoS ACL Configuration to Flash Memory
Moving the VACL and QoS ACL configuration to flash memory is done automatically only during the system software upgrades and then only if there is not sufficient NVRAM for the upgrade. If there is not enough NVRAM to perform a software upgrade, the QoS ACL and VACL configuration is deleted from NVRAM and the ACL configuration is automatically moved to flash memory. When this occurs, these syslog messages display:
1999 Sep 01 17:00:00 %SYS-1-CFG_FLASH:ACL configuration moved to bootflash:switchapp.cfg1999 Sep 01 17:00:00 %SYS-1-CFG_ACL_DEALLOC:NVRAM full. Qos/Security ACL configuration deleted from NVRAM.The VACL and QoS ACL configuration has now been successfully moved to flash memory. During this process, the system also does the following:
•
•
If an error occurs during the upgrade, these syslog messages display:
1999 Sep 01 17:00:00 %SYS-1-CFG_FLASH_ERR:Failed to write ACL configuration to bootflash:switchapp.cfg1999 Sep 01 17:00:00 %SYS-1-CFG_ACL_DEALLOC:NVRAM full. Qos/Security ACL configuration deleted from NVRAM.If you receive these error messages, the VACL and QoS ACL configuration is stored in DRAM only. You need to make more space available in flash memory and then save the configuration to flash memory (as described in the "Moving the VACL and QoS ACL Configuration Back to NVRAM" section). Alternatively, you might try to delete the unneeded VACLs and the QoS ACLs and save the ACL configuration to NVRAM using the set config acl nvram command.
Manually Moving the VACL and QoS ACL Configuration to Flash Memory
If your VACL and QoS ACL configuration requirements require more memory than the 512-KB NVRAM, you can manually move the VACL and QoS ACL configuration to flash memory as follows:
Step 1
Console> (enable) set boot auto-config bootflash:switchapp.cfgCONFIG_FILE variable = bootflash:switchapp.cfgConsole> (enable)Step 2
Console> (enable) set boot config-register auto-config recurringConfiguration register is 0x12Fignore-config: disabledauto-config: recurring, overwrite, sync disabledconsole baud: 9600boot: image specified by the boot system commandsConsole> (enable)Step 3
Console> (enable) set boot config-register auto-config appendConfiguration register is 0x12Fignore-config: disabledauto-config: recurring, append, sync disabledconsole baud: 9600boot: image specified by the boot system commandsConsole> (enable)Step 4
Console> (enable) set boot config-register auto-config sync enableConfiguration register is 0x12Fignore-config: disabledauto-config: recurring, append, sync enabledconsole baud: 9600boot: image specified by the boot system commandsConsole> (enable)Step 5
Console> (enable) copy acl-config bootflash:switchapp.cfgUpload ACL configuration to bootflash:switchapp.cfg2843644 bytes available on device bootflash, proceed (y/n) [n]? yACL configuration has been copied successfully.Console> (enable)Step 6
Console> (enable) clear config acl nvramACL configuration has been deleted from NVRAM.Warning: Use the copy commands to save the ACL configuration to a file andthe 'set boot config-register auto-config' commands to configure theauto-config feature.
Note
The VACL and QoS ACL configuration is no longer in NVRAM. It is saved in the auto-config file bootflash:switchapp.cfg and is appended to the NVRAM configuration at system startup.
After making any additional changes to the VACL and QoS ACL configuration and committing those changes, you must enter the copy acl-config bootflash:switchapp.cfg command to save the configuration to the auto-config file.
The auto-config file is synchronized automatically to the standby supervisor engine because synchronization was enabled.
If you cannot write the VACL and QoS ACL configuration to flash memory, it is removed from NVRAM and then the VACL and QoS ACL configuration exists in DRAM only. A system reset can cause the VACL and QoS ACL configuration to revert to the default.
Note
At system startup, if the VACL and QoS ACL configuration location is set to flash memory but either the CONFIG_FILE variable is not set or none of the files specified exist, this syslog message displays:
1999 Sep 01 17:00:00 %SYS-0-CFG_FLASH_ERR:ACL configuration set to flash but no ACL configuration file found.Running with the VACL and QoS ACL Configuration in Flash Memory
After you move the VACL and QoS ACL configuration to flash memory, the QoS ACLs and VACL commit operations are no longer written to NVRAM. You have to copy the configuration to the flash file manually as follows:
•
•
Moving the VACL and QoS ACL Configuration Back to NVRAM
This example shows how to move the VACL and QoS ACL configuration back to NVRAM:
Console> (enable) set config acl nvramACL configuration copied to NVRAM.Console> (enable)Console> (enable) clear boot auto-configCONFIG_FILE variable =Console> (enable)Redundancy Synchronization Support
The set boot commands contain an option to synchronize the auto-config file automatically.
When you enable the auto-config option, if the VACL and QoS ACL configuration resides in flash memory, the auto-config file on the active supervisor engine is automatically synchronized to the standby supervisor engine whenever a change is made. For example, deleting the auto-config file on the active supervisor engine causes the file to be deleted on the standby supervisor engine. Similarly, if you insert a new standby supervisor engine, the active supervisor engine automatically synchronizes the auto-config file.
Interacting with High Availability
After a supervisor engine switchover, the VACL and QoS ACL configuration on the standby supervisor engine is consistent with the configuration on the active supervisor engine, just as in the case where the VACL and QoS ACL configuration is saved in NVRAM. The only difference is that the data is stored in DRAM, but the functional behavior of a switchover does not change.
Configuring Port-Based ACLs
Note
These sections describe the port ACLs (PACLs):
•
•
PACL Configuration Overview
Before software release 8.3(1), there were only two types of access lists—the VACLs and Cisco IOS ACLs. The VACLs were applied to Layer 2 and Layer 3 forwarded traffic while Cisco IOS ACLs were applied only to the Layer 3 forwarded packets. Both access list types were applied to the VLANs and filtered traffic based on the packet header information.
In software release 8.3(1), there is an additional type of access list—a PACL. A PACL is an access list that is mapped to a physical port (typically, a VLAN is composed of many physical ports). A PACL provides you with the extra granularity to filter traffic on a specific physical port. Like the VACLs, the PACLs are applied to both the Layer 2 and Layer 3 forwarded packets.
Figure 15-9 shows the logical relationship between the access list types. A PACL is first applied on an incoming packet on a physical port. If the packet is permitted by the PACL, it is filtered by the VACL that is applied to the corresponding ingress VLAN. If the packet is Layer 3 forwarded and is permitted by the VACL, it is filtered by the Cisco IOS ACL on the same VLAN. The same process happens in reverse in the egress direction. However, there is currently no hardware support for the egress PACLs.
Figure 15-9
Logical Relationship Between Access List Types
The PACLs have three modes of operation that are configurable on a per-port basis:
•
•
•
A PACL can be configured on a trunking port except when the port is in merge mode. This restriction occurs because the trunking ports can have multiple VLANs with each VLAN having its own ACL. It would be incorrect to apply a VACL that is meant for VLAN x to a packet that is tagged with VLAN y. Because the PFC3A cannot perform a lookup based on a port-VLAN pair, you cannot map a PACL to a port in merge mode.
Note
PACL Configuration Guidelines
These sections describe the guidelines for configuring the PACLs:
•
•
•
•
•
•
•
PACL Interaction with VACLs and Cisco IOS ACLs
This section describes the guidelines for the PACL interaction with the VACLs and Cisco IOS ACLs:
•
–
–
The MSFC reapplies the ingress and egress Cisco IOS ACLs on any packet it sees. The PACL override model for the Layer 3 hardware- and software-forwarded packets is slightly different for Cisco IOS ACLs.
•
EtherChannel and PACL Interactions
This section describes the guidelines for the EtherChannel and PACL interactions:
•
•
•
•
Dynamic ACLs (Applies to Merge-Mode Only)
The dynamic ACLs are VLAN based and are used by two features: CBAC and IGMP. The merge mode does not support the merging of the dynamic ACLs with the PACLs. In merge mode, the following configurations are not allowed:
•
•
Trunking Mode (Applies to Merge-Mode Only)
The PACLs in merge mode are incompatible with the trunking ports. The trunking mode on a port must be set to off to allow it to be configured in merge mode. Conversely, a port in merge mode cannot be changed to trunking mode.
Auxiliary VLANs (Applies to Merge-Mode Only)
You cannot configure merge mode on a port that is auxiliary-VLAN enabled. Conversely, a port that is auxiliary-VLAN enabled cannot be changed to merge mode.
Private VLANs (Applies to Merge-Mode Only)
You can map the VACLs to either the primary or the secondary private VLAN. In contrast, you can map only Cisco IOS ACLs to the primary VLANs. An ingress Cisco IOS ACL that is mapped to the primary VLAN gets mapped to all the corresponding secondary VLANs and not to the primary VLAN. An egress Cisco IOS ACL that is mapped to the primary VLAN gets mapped to the primary VLAN.
The ingress lookups on the private VLANs are performed on the secondary VLAN only. In merge mode, the PACLs are merged with the ingress VACLs and Cisco IOS ACLs that are applied to the secondary VLANs.
Port-VLAN Association Changes (Applies to Merge-Mode Only)
The port-VLAN association changes are allowed in all cases. However, when a port is configured in merge mode, it is possible that a change in the port-VLAN association can result in a merge failure. In such cases, the port is placed in "merge disable" mode.
Unmapping and then mapping a PACL, VACL, or Cisco IOS ACL automatically triggers a remerge. This example shows where port 3/1 is associated with VLAN 1 and then VLAN 2:
Console> (enable) set port security-acl 3/1 mergeACL interface is set to merge mode for port(s) 3/1.Console> (enable) set security acl map ipacl1 3/1ACL ipacl1 is successfully mapped to port(s) 3/1.Console> (enable) set security acl map ipacl2 1ACL ipacl2 is successfully mapped to VLAN 1.Console> (enable) set security acl map ipacl3 2ACL ipacl3 is successfully mapped to VLAN 2.Console> (enable) set vlan 2 3/12003 Sep 05 22:34:50 %ACL-3-PACLMERGEFAILED:Failed to merge Security ACLs on Port(s) 3/1 with Vlan 2.VLAN 2 modified.VLAN 1 modified.VLAN Mod/Ports---- -----------------------2 3/1Console> (enable) show port security-acl 3/1Port Interface Type Interface Type Interface Merge Statusconfig runtime runtime----- -------------- -------------- ----------------------3/1 merge merge (VLAN=2) disabledConfig:Port ACL name Type----- -------------------------------- ----3/1 ipacl1 IPRuntime:Port ACL name Type----- -------------------------------- ----No ACL is mapped to port 3/1.dhcp-snooping:Port Trust Source-Guard Source-Guarded IP Addresses----- ----------- ------------ ---------------------------3/1 untrusted disabledConsole> (enable) show security acl map runtime 1Vlan ACL name Type---- -------------------------------- ----1 ipacl2 IPConsole> (enable) show security acl map runtime 2Vlan ACL name Type---- -------------------------------- ----2 ipacl3 IPConsole> (enable)Online Insertion and Removal
When you remove or reset a module, all the PACLs that are attached to the module are removed from the run-time configuration (which is programmed in the hardware) and the NVRAM configuration (which is stored in NVRAM). The configuration is retained in NVRAM but is not displayed. When you insert or bring a module online, the configuration is repopulated from NVRAM (or text-configuration file) and remapped in runtime.
Enabling or disabling a port has no impact on the ACL mapping or the security-ACL mode, unless the port is in merge mode. In the merge mode, a port that is disabled or cleared from a VLAN is placed in the "merge disable" state because the VLAN that is associated with the port is no longer available and the port cannot forward the packets or merge with any VLAN.
Configuring PACLs from the CLI
These sections describe how to create and activate PACLs on the Catalyst 6500 series switches:
•
•
•
Specifying the PACL Mode
The default PACL mode is VLAN based and keeps any existing VACL configurations active.
To specify the PACL mode, perform this task in privileged mode:
Specify the PACL mode.
set port security-acl mod/ports.. [port-based | vlan-based | merge]
This example shows how to specify the PACL mode for port 3/1:
Console> (enable) set port security-acl 3/1 port-basedWarning: Vlan-based ACL features will be disabled on port(s) 3/1.ACL interface is set to port-based mode for port(s) 3/1.Console> (enable) set port security-acl 3/1 mergeACL interface is set to merge mode for port(s) 3/1.Console> (enable) set port security-acl 3/1 vlan-basedACL interface is set to vlan-based mode for port(s) 3/1.Console> (enable)This example shows the response when trying to configure a trunk port (port 3/1) to merge mode:
Console> (enable) set port security-acl 3/1-4 mergeACL interface cannot be in merge mode on multi-vlan access port 3/1.ACL interface is set to merge mode for port(s) 3/2.ACL interface is set to merge mode for port(s) 3/3.ACL interface is set to merge mode for port(s) 3/4.Displaying PACL Information
The show port security-acl mod/port command displays PACL information for the specified port. The Config field displays what is stored in NVRAM. The Runtime field displays what is actually programmed in the hardware. The display also shows the status of the merge operation as follows:
•
•
•
The show port security-acl command also displays the VLAN with which the port is configured to merge.
To display PACL information, perform this task in normal mode:
This example shows how to display PACL information for port 3/1:
Console> (enable) show port security-acl 3/1Port Interface Type Interface Type Interface Merge Statusconfig runtime runtime----- -------------- -------------- ----------------------3/1 port-based port-based not applicableConfig:Port ACL name Type----- -------------------------------- ----3/1 ipacl1 IPRuntime:Port ACL name Type----- -------------------------------- ----No ACL is mapped to port 3/1.dhcp-snooping:Port Trust Source-Guard Source-Guarded IP Addresses----- ----------- ------------ ---------------------------3/1 untrusted disabledConsole> (enable)Mapping an ACL to Ports or to VLANs
An ACL may be mapped to a port even if the port is in VLAN-based mode. In such cases, the configuration is committed to NVRAM and is later restored to the hardware when the port is changed to port-based or merge mode. This functionality is similar to QoS.
Mapping an ACL to a VLAN causes the following operations to occur:
1.
2.
If (1) fails, the operation fails and a syslog message is generated. For (2), a syslog is generated for any ports that failed to merge with the VACL. These ports are temporarily placed in VLAN-based mode. If any ports fail to merge, the status of the merge displayed through the show port security-acl mod/port command is "merge disabled." For an example of the "merge disabled" status, see "Example 6" in the "PACL Configuration Examples" section.
To map an ACL to a port or a VLAN, perform this task in privileged mode:
This example shows how to map an ACL to port 3/1:
Console> (enable) set security acl map ipacl1 3/1Mapping in progress.ACL ipacl1 is successfully mapped to port(s) 3/1.Console> (enable) set port security-acl 3/1 vlan-basedACL interface is set to vlan-based mode for port(s) 3/1.Console> (enable) set security acl map ipacl1 3/1Port 3/1 is set to vlan-based mode, config is saved in Nvram.Config will be applied when the port is set to port-based/merge mode.Console> (enable)Displaying ACL Mapping Information
The show security acl map command is extended to display the port mappings as follows:
•
•
To display the ACL mapping information, perform this task in normal mode:
Display the ACL mapping information.
show security acl map [config | runtime] [acl_name | mod_num/port_num | vlan | all | all-vlans | all-ports]
These examples show how to display the ACL mapping information:
Console> (enable) show security acl map config allACL Name Type Ports/Vlans-------------------------------- ---- --------------ipacl1 IP 11ipacl2 IP 3/1Console> (enable) show security acl map config all-portsACL Name Type Ports-------------------------------- ---- --------------ipacl2 IP 3/1Console> (enable) show security acl map runtime 3/1Port ACL name Type----- -------------------------------- ----3 / 1 ipacl1 IPConsole> (enable)Displaying ACL Information for an EtherChannel
The show port channel command is extended to display the PACL mappings on the port channels. For type, you can specify security-acl.
To display the ACL information for an EtherChannel, perform this task in normal mode:
Display the ACL information for an EtherChannel.
show port channel [all | mod[/port]] {info [type]}
This example shows how to display the ACL information for an EtherChannel:
Console> (enable) show port channel 3/40 info security-aclPort ACL-Interface Type----- ------------------3/37 port-based3/38 port-basedPort ACL name Type----- -------------------------------- ------3/37 ipacl1 IP3/38 ipacl1 IPConsole> (enable)PACL Configuration Examples
This section contains the PACL configuration examples.
Note
Example 1
This example shows how to map an ACL to a port when the port is in VLAN-based mode:
Console> (enable) set port security-acl 3/1 vlan-basedACL interface is set to vlan-based mode for port(s) 3/1.Console> (enable) set security acl map ipacl1 3/1Port 3/1 is set to vlan-based mode, config is saved in Nvram.Config will be applied when the port is set to port-based/merge.Console> (enable) show security acl map config 3/1Port ACL name Type----- -------------------------------- ----3/1 ipacl1 IPConsole> (enable) show security acl map runtime 3/1Port ACL name Type----- -------------------------------- ----No ACL mapped to port 3/1.Console> (enable) set port security-acl 3/1 port-basedWarning: Vlan-based ACL features will be disabled on port(s) 3/1.ACL interface is set to port-based mode for port(s) 3/1.Console> (enable) show security acl map config 3/1Port ACL name Type----- -------------------------------- ----3/1 ipacl1 IPConsole> (enable) show security acl map runtime 3/1Port ACL name Type----- -------------------------------- ----3/1 ipacl1 IPConsole> (enable)Example 2
This example shows a failure that occurs when changing the security ACL mode due to an ACL mapping error. In this example, the ACL is mapped only in NVRAM and not in the hardware.
Console> (enable) set port security-acl 3/1 vlan-basedACL interface is set to vlan-based mode for port(s) 3/1.Console> (enable) set security acl map ipacl1 3/1Port 3/1 is set to vlan-based mode, config is saved in Nvram.Config will be applied when the port is set to port-based/merge.Console> (enable) set port security-acl 3/1 port-basedWarning: Vlan-based ACL features will be disabled on port(s) 3/1.ACL interface is set to port-based mode for port(s) 3/12003 Sep 05 22:34:50 %ACL-3-TCAMFULL:Acl engine TCAM table is full2003 Sep 05 22:34:50 %ACL-3-PACLMAPCOMMITFAIL:Failed to Map Security ACL ipacl1 to Port 3/1Console> (enable) show security acl map config 3/1Port ACL name Type----- -------------------------------- ----3/1 ipacl1 IPConsole> (enable) show security acl map runtime 3/1Port ACL name Type----- -------------------------------- ----No ACL is mapped to port 3/1.Console> (enable) show port security-acl 3/1Port Interface Type Interface Type Interface Merge Statusconfig runtime runtime----- -------------- -------------- ----------------------3/1 port-based port-based not applicableConfig:Port ACL name Type----- -------------------------------- ----3/1 ipacl1 IPRuntime:Port ACL name Type----- -------------------------------- ----No ACL is mapped to port 3/1.dhcp-snooping:Port Trust Source-Guard Source-Guarded IP Addresses----- ----------- ------------ ---------------------------3/1 untrusted disabledConsole> (enable)Example 3
This example shows a port that is configured in merge mode but the port has not been mapped to an ACL:
Console> (enable) set port security-acl 3/1 mergeACL interface is set to merge mode for port(s) 3/1.Console> (enable) show port security-acl 3/1Port Interface Type Interface Type Interface Merge Statusconfig runtime runtime----- -------------- -------------- ----------------------3/1 merge merge (VLAN 5) inactiveConfig:Port ACL name Type----- -------------------------------- ----No ACL is mapped to port 3/1.Runtime:Port ACL name Type----- -------------------------------- ----No ACL is mapped to port 3/1.dhcp-snooping:Port Trust Source-Guard Source-Guarded IP Addresses----- ----------- ------------ ---------------------------3/1 untrusted disabledConsole> (enable) set security acl map ipacl1 3/1ACL ipacl1 is successfully mapped to port(s) 3/1.Console> (enable) show port security-acl 3/1Port Interface Type Interface Type Interface Merge Statusconfig runtime runtime----- -------------- -------------- ----------------------3/1 merge merge (VLAN 5) activeConfig:Port ACL name Type----- -------------------------------- ----3/1 ipacl1 IPRuntime:Port ACL name Type----- -------------------------------- ----3/1 ipacl1 IPdhcp-snooping:Port Trust Source-Guard Source-Guarded IP Addresses----- ----------- ------------ ---------------------------3/1 untrusted disabledConsole> (enable)Example 4
This example shows that a merge failure occurs when mapping an ACL to a port. In this case, the configuration is not saved.
Console> (enable) set port security-acl 3/1 mergeACL interface is set to merge for port(s) 3/1.Console> (enable) set security acl map ipacl1 3/1Mapping in progress.2003 Oct 01 19:44:31 %ACL-3-PACLMAPCOMMITFAIL:Failed to Map Security ACL ipacl1 to Port 3/15Failed to attach ACL ipacl1 to port(s) 3/1.Console> (enable) show security acl map config 3/1Port ACL name Type----- -------------------------------- ----No ACL is mapped to port 3/1.Console> (enable) show security acl map runtime 3/1Port ACL name Type----- -------------------------------- ----No ACL is mapped to port 3/1.Console> (enable)Example 5
This example shows that you cannot change the mode if a failure occurs when changing port-based mode to merge mode:
Console> (enable) set port security-acl 3/1 port-basedACL interface is set to port-based for port(s) 3/1.Console> (enable) set security acl map ipacl1 3/1ACL ipacl1 is successfully mapped to port 3/1.Console> (enable) show security acl map config 3/1Port ACL name Type----- -------------------------------- ----3/1 ipacl1 IPConsole> (enable) show security acl map runtime 3/1Port ACL name Type----- -------------------------------- ----3/1 ipacl1 IPConsole> (enable) set port security-acl 3/1 mergeFailed to set interface to merge mode for port(s) 3/1.2003 Oct 01 19:53:01 %ACL-3-TCAMFULL:Acl engine TCAM table is fullConsole> (enable)Example 6
This example shows that a syslog is generated for any ports that fail to merge with the VACL and these ports are temporarily placed in VLAN-based mode. The status of the merge is "merge disabled."
Console> (enable) show port security-acl 3/1Port Interface Type Interface Type Interface Merge Statusconfig runtime runtime----- -------------- -------------- ----------------------3/1 merge merge (VLAN=5) activeConfig:Port ACL name Type----- -------------------------------- ----3/1 ipacl1 IP3/1 macacl1 MACRuntime:Port ACL name Type----- -------------------------------- ----3/1 ipacl1 IP3/1 macacl1 MACdhcp-snooping:Port Trust Source-Guard Source-Guarded IP Addresses----- ----------- ------------ ---------------------------3/1 untrusted disabledConsole> (enable) set security acl map ipacl2 5ACL ipacl2 is successfully mapped to VLAN 5.2003 Oct 01 20:01:04 %ACL-3-MERGEFAILED:Failed to merge Security ACLs on ports(s) 3/1-4 with VLAN 52003 Oct 01 20:01:04 %ACL-3-PACLSMERGEDFORVLAN:Merge completed for all ports on Vlan 5Console> (enable) show port security-acl 3/1Port Interface Type Interface Type Interface Merge Statusconfig runtime runtime----- -------------- -------------- ----------------------3/1 merge merge (VLAN=5) disabledConfig:Port ACL name Type----- -------------------------------- ----3/1 ipacl1 IP3/1 macacl1 MACRuntime:Port ACL name Type----- -------------------------------- ----3/1 ipacl1 IP3/1 macacl1 MACdhcp-snooping:Port Trust Source-Guard Source-Guarded IP Addresses----- ----------- ------------ ---------------------------3/1 untrusted disabledConsole> (enable)Example 7
This example is a continuation from Example 6 and shows that you can recover from the failure state by either mapping or unmapping the VACL or PACL. This example shows that detaching the MAC PACL can release some TCAM resources, allowing the merge to succeed. A syslog is generated when the merge is reenabled.
Console> (enable) clear security acl map macacl1Map deletion in progress.Successfully cleared mapping between ACL macacl1 and port 3/1.2003 Oct 01 20:01:04 %ACL-3-PACLMERGED:Merged Security ACLs on port(s) 3/1Console> (enable) show port security-acl 3/1Port Interface Type Interface Type Interface Merge Statusconfig runtime runtime----- -------------- -------------- ----------------------3/1 merge merge (VLAN=5) activeConfig:Port ACL name Type----- -------------------------------- ----3/1 ipacl1 IPRuntime:Port ACL name Type----- -------------------------------- ----3/1 ipacl1 IPdhcp-snooping:Port Trust Source-Guard Source-Guarded IP Addresses----- ----------- ------------ ---------------------------3/1 untrusted disabledConsole> (enable)Configuring ACL Statistics
These sections describe how to configure the ACL statistics:
•
ACL Statistics Overview
When you select the statistics keyword with the set security acl command set, the statistics are stored for the ACEs or the ACLs (VACLs and PACLs). The ACL statistics are disabled by default and can be enabled on a per-ACL, per-VLAN, or per-ACE basis.
Before an ACL is programmed in the TCAM, it is passed to the ACL compiler. The ACL compiler optimizes the ACL in terms of the number of ACEs and promotes mask sharing, where possible, to reduce the number of TCAM masks used. When there are multiple features/policies configured through the ACLs on an interface, the ACLs are merged and the resultant ACL is optimized. The resultant ACL is logically equivalent to the original ACL(s).
Optimizing an ACL involves removing the redundant ACEs, merging the ACEs, and reordering the ACEs. Removing the redundant ACEs and merging the ACEs reduces the number of TCAM entries. Reordering the ACEs reduces the number of TCAM entries and the number of TCAM masks.
The ACL statistics are derived from the counters of the ACEs that comprise the optimized ACL. A mapping function maps these ACEs to the ACEs corresponding to the original user-configured ACLs.
Note
Note
Configuring ACL Statistics from the CLI
This section provides these example procedures:
•
•
•
•
•
Enabling the ACL Compiler Optimization
Enter the set security acl comp-opt command to optimize the ACL compiler.
To enable ACL compiler optimization, perform this task in privileged mode:
This example shows how to enable ACL compiler optimization:
Console> (enable) set security acl comp-opt enableAcl Compiler Optimization Enabled.Console> (enable) show security acl comp-optAcl Compiler Optimization EnabledConsole> (enable)Enabling ACL Statistics on a Per-ACL Basis
Note
Enter the set security acl statistics {acl_name | all} command to enable the aggregated ACL statistics on a per-ACL basis or for all ACLs. In the aggregated statistics mode, the statistics are enabled for all the ACEs in the specified ACL. This command is effective only after you enter the commit command to commit all ACEs to NVRAM.
Note
Note
To enable the aggregated ACL statistics on a per-ACL basis, perform this task in privileged mode:
Enable the aggregated ACL statistics on a per-ACL basis.
set security acl statistics {acl_name | all}
This example shows how to enable the aggregated ACL statistics on a per-ACL basis:
Console> (enable) set security acl statistics ACL1ACL1 editbuffer modified. Use 'commit' command to save changes.Console> (enable) commit security acl ACL1ACL commit in progress.ACL 'ACL1' successfully committed.Console> (enable)Console> (enable) show security acl info ACL1set security acl ip ACL1 statistics---------------------------------------------------arp permit1. permit ip any anyConsole> (enable)Enabling ACL Statistics on a Per-VLAN Basis
Enter the set security acl map acl-name {vlan/mod_port} [statistics enable | disable] command to enable the ACL statistics on a per-VLAN basis.
Note
If the per-VLAN statistics are enabled on a VLAN, the subsequent maps that are configured on the same VLAN will also have the per-VLAN statistics enabled. If the per-VLAN statistics are disabled on a VLAN, the previous maps that are configured on the same VLAN will also have the per-VLAN statistics disabled.
For example, if you enter the set security acl map ip1 1 statistics enable command followed by the set security acl map mac1 1 command, the mac1 ACL will also have the per-VLAN statistics enabled.
If you enter the set security acl map ip1 1 statistics enable command followed by the set security acl map mac1 1 statistics disable command, the ip1 ACL will also have the per-VLAN statistics disabled.
To enable the ACL statistics on a per-VLAN basis, perform these tasks in privileged mode:
Enable the ACL statistics on a per-VLAN basis.
set security acl map acl-name {vlan/mod_port} [statistics enable | disable]
Display the configuration.
show security acl
