-
Catalyst 6500 Series Software Configuration Guide, 7.6
-
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
-
Configuring MLS
-
Configuring NDE
-
Configuring Access Control
-
Configuring GVRP
-
Configuring Dynamic Port VLAN Membership with VMPS
-
Checking Status and Connectivity
-
Administering the Switch
-
Configuring Switch Access Using AAA
-
Configuring 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 NTP
-
Configuring Broadcast Suppression
-
Configuring Layer 3 Protocol Filtering
-
Configuring the IP Permit List
-
Configuring Port Security
-
Configuring 802.1x Authentication
-
Configuring Unicast Flood Blocking
-
Configuring SNMP
-
Configuring RMON
-
Configuring SPAN and RSPAN
-
Using Switch TopN Reports
-
Configuring Multicast Services
-
Configuring QoS
-
Configuring Automatic QoS
-
Configuring ASLB
-
Configuring the Switch Fabric Module
-
Configuring a VoIP Network
-
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
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
Configuring ACLs on Private VLANs
Configuring VACLs on the Switch
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
Showing the Contents of a VACL
Removing ACEs from Security ACLs
Displaying VACL Management Information
Capturing Traffic Flows on Specified Ports
Configuring and Storing VACLs and QoS ACLs in Flash Memory
Automatically Moving the VACL and QoS ACL Configuration to Flash Memory
Manually Moving the VACL and QoS ACL Configuration to Flash Memory
Running with the VACL and QoS ACL Configuration in Flash Memory
Moving the VACL and QoS ACL Configuration Back to NVRAM
Redundancy Synchronization Support
Interacting with High Availability
Configuring Policy-Based Forwarding
PBF Hardware and Software Requirements
Enabling PBF and Specifying a MAC Address for the PFC2
Rolling Back Adjacency Table Entries in the Edit Buffer
Enhancements to PBF Configuration
PBF Configuration Enhancement Overview
Displaying the PBF_MAP_ACL Information
Clearing the PBF_MAP_ACL Configuration
Configuring Access Control
This chapter describes how to configure access control lists (ACLs) on the Catalyst 6500 series switches. Configuration of the ACLs depends on the type of hardware that you install on your supervisor engine. See the "Hardware Requirements" section for details.
Note
For complete syntax and usage information for the commands used in this chapter, refer to the Catalyst 6500 Series Switch Command Reference publication.
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 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 it switches including packets bridged within a VLAN.
Cisco IOS ACLs provide access control for routed traffic between VLANs, and VLAN ACLs (VACLs) provide access control for all packets.
Standard and extended Cisco IOS ACLs are used to classify packets. Classified packets can be subject to a number of features such as access control (security), encryption, policy-based routing, and so on. Standard and extended Cisco IOS ACLs are only configured on router interfaces and applied on routed packets.
VACLs can provide access control based on Layer 3 addresses for IP and IPX protocols. Unsupported protocols are access controlled through 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. Packets can either enter the VLAN through a switch port or through a router port after being routed.
Hardware Requirements
The hardware that is required to configure 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 QoS ACLs on the switch; see Chapter 43, "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 ACLs to specify HTTP flows that can be redirected to a Web cache engine.
Most Cisco IOS features are applied on interfaces for specific directions (inbound versus outbound). However, some features use ACLs globally. For such features, ACLs are applied on all interfaces for a given direction. As an example, TCP intercept uses a global ACL that is applied on all interfaces for outbound direction.
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 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 packets are routed and before they are forwarded out to the next hop, Cisco IOS software examines all ACLs that are associated with outbound features configured on the egress interface for the following:
•
•
•
•
•
VACLs
The following sections describe VACLs:
•
VACL Overview
VACLs can access control all traffic. You can configure VACLs on the switch to apply to all packets that are routed into or out of a VLAN or are bridged within a VLAN. VACLs are strictly for security packet filtering and redirecting traffic to specific physical switch ports. Unlike Cisco IOS ACLs, VACLs are not defined by direction (input or output).
You can configure VACLs on Layer 3 addresses for IP and IPX. All other protocols are access controlled through MAC addresses and Ethertype using MAC VACLs.
Caution
You can enforce VACLs only on packets going through the Catalyst 6500 series switch; you cannot enforce VACLs on traffic between 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 16-1 lists the parameters associated with each ACE type.
Table 16-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 fragments and distinguish them from the rest of the TCP/UDP traffic.
Layer 4 parameters of ACEs can filter unfragmented traffic and fragmented traffic with fragments that have offset 0. IP fragments that have an offset other than 0 miss the Layer 4 port information and cannot be filtered. The following examples show how ACEs handle 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 packets are fragmented, the first fragment hits this entry and is permitted; fragments that have an offset other than 0 are also permitted as a default result for 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 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.
In software release 6.1(1) and later releases, there is a fragment option. If you do not specify the fragment keyword, the behavior is the same as in previous releases. If you specify the fragment keyword, the system does not automatically install a global permit statement for fragments. This keyword allows you to control how fragments are handled.
In this example, 10.1.1.2 is configured to serve HTTP connections. If you do not use a fragment ACE, all the fragments for 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 will not be added at the top of 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 ACEs to permit 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 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 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, 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 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 Cisco IOS ACLs and VACLs to the VLAN for bridged packets, routed packets, and multicast packets.
These sections show how ACLs and VACLs are applied:
Bridged Packets
Figure 16-1 shows how an ACL is applied on bridged packets. For bridged packets, only Layer 2 ACLs are applied to the input VLAN.
Figure 16-1 Applying ACLs on Bridged Packets
Routed Packets
Figure 16-2 shows how ACLs are applied on routed/Layer 3-switched packets. For routed/Layer 3-switched packets, the ACLs are applied in the following order:
1.
2.
3.
4.
Figure 16-2 Applying ACLs on Routed Packets
Multicast Packets
Figure 16-3 shows how ACLs are applied on packets that need multicast expansion. For packets that need multicast expansion, the ACLs are applied in the following order:
1.
a.
b.
2.
a.
b.
3.
a.
Figure 16-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 Layer 3 switched. The router then applies the feature and routes the packet normally. Note that there are some exceptions to this process as described in the "Hardware and Software Handling of Cisco IOS ACLs with PFC" section.
Note
Caution
For PFC2: If IP unreachables or IP redirect is enabled on an interface, the deny is performed in hardware although a small number of packets are sent to the MSFC2 to generate the appropriate ICMP-unreachable messages.
These sections describe hardware and software handling of ACLs with PFC and PFC2:
•
•
Hardware and Software Handling of Cisco IOS ACLs with PFC
This section describes hardware and software handling of Cisco IOS ACLs with the PFC.
Note
ACL feature processing requires forwarding of some flows by the software. The forwarding rate for software-forwarded flows is substantially less than for hardware-forwarded flows. 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
These sections describe how 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. Note that when reflexive ACLs are applied, the flow mask is changed to VLAN-full flow.
TCP Intercept
The TCP intercept feature implements software to protect the TCP servers from TCP SYN-flooding attacks, which are denial-of-service attacks. TCP intercept helps prevent SYN-flooding attacks by intercepting and validating TCP connection requests. In intercept mode, the TCP intercept software intercepts TCP synchronization (SYN) packets from clients to 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 connection attempts from the unreachable hosts never reach the server. The software continues to intercept and forward packets throughout the duration of the connection.
Policy Routing
Policy routing-required flows are handled in the software without impacting non-policy routed flow forwarding in the hardware. When a route map contains multiple "match" clauses, all conditions imposed by these match clauses must be met before a packet is policy routed. However, for route maps containing 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 route maps that only contain 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
HTTP requests that are subject to Web Cache Coordination Protocol (WCCP) redirection are handled in the software; HTTP replies from the server and the Cache Engine are handled in the hardware.
NAT
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 hardware on the PFC. For ACL-based RPF checks, 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
This section describes hardware and software handling of Cisco IOS ACLs with the PFC2.
ACL feature processing requires forwarding some flows to the software. The forwarding rate for software-forwarded flows is substantially less than for hardware-forwarded flows. 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
These sections describe how different types of ACLs and traffic flows are handled by the hardware and the software in systems with PFC2:
•
•
•
Security Cisco IOS ACLs
The IP and IPX security Cisco IOS ACLs with PFC2 are as follows:
•
•
•
•
•
•
•
Rate Limiting for Cisco IOS ACL Logging
The rate limiting feature for Cisco IOS ACL logging limits the number of packets that are sent to the MSFC CPU for 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, the reset or shut/no shut action causes the bridged ACEs to be redirected to the MSFC with rate limiting.
After entering the clear acllog command, the reset or shut/no shut action causes the system 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 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 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
ICMP packets are handled in the software. For TCP/UDP flows, once the flow is established, they are handled in the hardware. When reflexive ACLs are applied, the flow mask is changed to VLAN-full flow.
TCP Intercept
The TCP intercept feature implements software to protect TCP servers from TCP SYN-flooding attacks, which are denial-of-service attacks. TCP intercept helps prevent SYN-flooding attacks by intercepting and validating TCP connection requests. In intercept mode, the TCP intercept software intercepts TCP synchronization (SYN) packets from clients to 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 connection attempts from the unreachable hosts never reach the server. The software continues to intercept and forward 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
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" 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 route maps containing both a 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 route maps that only contain match length clauses, all packets that are received on the interface are forwarded to the software.
Note
WCCP
HTTP requests subject to WCCP redirection are handled in the software; HTTP replies from the server and the Cache Engine are handled in the hardware.
NAT
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 hardware on the PFC2. For ACL-based RPF checks, traffic that is denied by the unicast RPF ACL is forwarded to the MSFC2 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 bridged and routed traffic, you can use VACLs only or a combination of Cisco IOS ACLs and VACLs. You can define Cisco IOS ACLs on both 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 used with VACLs:
•
•
Note
These sections describe 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 configurations where you are mapping Cisco IOS ACLs and VACLs on different VLANs.
The Catalyst 6500 series switch hardware provides one lookup for 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 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 ACEs to permit only allowed traffic. You can achieve this same effect by defining all the deny entries, and at the end of the list specifying permit ip any any (see Example 1).
Grouping Actions Together
To define multiple actions in an ACL (permit, deny, redirect), group each action type together. Example 3 shows what can happen when you do not group each type together. In the example, the deny action in line 6 was grouped with permit actions. If this deny action is removed, the result of merging would be 53 entries, instead of 329.
Limiting the Number of Actions
An ACL with only 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; adding this information will complicate the merging process. You will obtain the best merge results if the ACLs are filtered based on 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 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 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 ACLs, you can get a rough estimate of the merge results for 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
There are two ACL-merge algorithms available—the binary decision diagram (BDD) and the order dependent merge (ODM). ODM is the enhanced algorithm introduced in software release 7.1(1). The BDD algorithm is used in software releases prior to release 7.1(1). See the "Specifying the ACL-Merge Algorithm" section for detailed configuration information.These examples show the merge results for various Cisco IOS ACL and VACL configurations. Note that in these examples, 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 get 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 action types are not grouped together), 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
There are two ACL-merge algorithms available—the binary decision diagram (BDD) and the order dependent merge (ODM). ODM is the enhanced algorithm introduced in software release 7.1(1). The BDD algorithm is used in software releases prior to release 7.1(1).See the "Specifying the ACL-Merge Algorithm" section for detailed configuration information.
Examples
These examples show the merge results for various Cisco IOS ACL and VACL configurations. Note that in these examples, 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 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
LOUs are registers that store operator/operand couples. All ACLs use LOUs. There can be up to 32 LOUs; each LOU can store two different operator/operand couples with the exception of the range
operator. 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 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 is as follows:
•
•
•
An explanation of the LOU usage follows:
•
•
•
•
Using VACLs in your Network
This section describes some typical uses for VACLs and includes the following:
•
•
•
•
Wiring Closet Configuration
In a wiring closet configuration, Catalyst 6500 series switches might not be equipped with 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 16-4). Traffic from Host X to Host Y is eventually being routed by the switch equipped with the MSFC. Traffic from Host X to Host Y can be access controlled at the traffic entry point, Switch A.
If you do not want HTTP traffic 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 16-4 Wiring Closet Configuration
Redirecting Broadcast Traffic to a Specific Server Port
Some application traffic uses broadcast packets that reach every host in a VLAN. With VACLs, you can redirect these broadcast packets to the intended application server port.
Figure 16-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 broadcast traffic to a specific server port, perform this task in privileged mode (TCP port 5000 is the intended server application port):
Note
Figure 16-5 Redirecting Broadcast Traffic to a Specific Server Port
Restricting the DHCP Response for a Specific Server
When Dynamic Host Configuration Protocol (DHCP) requests are broadcast, they reach every DHCP server in the VLAN and multiple responses are returned. With VACLs, you can restrict the response from a specific DHCP server and drop the other responses.
To restrict DHCP responses for a specific server, perform this task in privileged mode (the target DHCP server IP address is 1.2.3.4):
Figure 16-6 shows that only the target server returns a DHCP response from the DHCP request.
Figure 16-6 Redirect 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 (see Figure 16-7):
•
•
To deny access to a server on another VLAN, perform this task in privileged mode:
Figure 16-7 Deny Access to a Server on Another VLAN
Restricting ARP Traffic
Note
ARP traffic is permitted on each VLAN by default. You can disallow ARP traffic on a per-VLAN basis using the set security acl ip acl_name deny arp command. When you enter this command, ARP traffic is disallowed on the VLAN to which the ACL is mapped. To allow ARP traffic on a VLAN that has had 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 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 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.
The ARP inspection feature allows you to configure a set of order-dependent rules within the security ACL (VACL) framework to prevent 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 inspection task for conformance to the specified rules. Conforming packets are forwarded while nonconforming packets are dropped and logged (if logging is enabled).
The rules for ARP traffic inspection specify the ARP bindings for 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. ARP packets advertising 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 using the set security acl log maxflow max_flows command. However, the set security acl log ratelimit max_rate command does not apply to ARP 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. The problem with this ACL is that this will deny all IP packets because there is an implicit ip deny any any in an IP ACL.
Therefore, 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 Inspection
•
•
•
•
•
•
•
•
Configuring Rate Limiting for ARP Inspection
•
•
•
Configuring Logging for ARP Inspection
•
Permitting or Denying ARP Packets Advertising a Specific IP-Address-to-MAC-Address Binding
To permit or deny 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 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 ARP packets that advertise a binding for the specified IP address, perform this task in privileged mode:
This example shows how to permit 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 ARP packets that advertise bindings for IP addresses on a particular network, perform this task in privileged mode:
Note
This example shows how to permit ARP packets that advertise bindings for 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 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 option, the packet is not dropped but a syslog message is displayed. Use the log option to send the packets to the VACL logging facility.
Tip
This example shows how to drop 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.Console> (enable)Dropping Packets with Invalid MAC or IP Addresses
The following MAC addresses are invalid:
•
•
•
The following IP addresses are invalid:
•
•
•
To drop packets with invalid MAC or IP addresses, perform this task in privileged mode (if you do not specify the drop option, the packet is not dropped but a syslog message is displayed):
This example shows how to drop packets with 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 Inspection Statistics
To display the number of packets that are permitted and denied by the ARP inspection task, perform this task in normal mode:
Display the number of packets that are permitted and denied by the ARP 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 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 ARP Inspection Statistics
To clear ARP inspection statistics, perform this task in privileged mode:
Clear ARP inspection statistics.
clear security acl arp-inspection statistics [acl_name]
Without the optional argument, entering the command clears the ARP inspection global statistics counters and ARP inspection statistics counters for all the ACLs. If you supply the optional acl_name argument, only the ARP inspection statistics for that particular ACL are cleared.
Note
Configuring Rate Limiting on a Global Basis
You can rate limit the number of ARP inspection packets that are sent to the supervisor engine CPU on a global basis. By default, ARP inspection traffic is rate limited to 500 packets per second. The minimum value is 0, and the maximum value is 1000 packets per second.
Note
To rate limit the number of ARP 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 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)Configuring Rate Limiting on a Per-Port Basis
You can rate limit the number of ARP 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 shutdown. 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 inspection packets that are sent to the CPU on a per-port basis, perform this task in privileged mode:
This example shows how to rate limit the number of ARP 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 Inspection
You configure the errdisable-timeout option for ARP 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-11.
Configuring Logging for ARP Inspection
To configure the logging option to log ARP inspection packets that are dropped, perform this task in privileged mode:
Log ARP 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 inspection packets, perform this task in normal mode:
Display the logged ARP inspection packets.
show security acl log flow arp [host ip_address [vlan vlan]]
If you specify the optional host IP address, only ARP packets that advertise a binding for the specified host IP address are displayed. If you specify the optional vlan vlan argument, the search is restricted to the specified VLAN.
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
This section lists the ACL-related features that are not supported or have limited support on the Catalyst 6500 series switches:
•
–
–
–
–
–
–
–
–
–
–
•
•
Configuring VACLs on the Switch
This section describes how to configure VACLs. Prior to performing any configuration tasks, see the "VACL Configuration Guidelines" section.
These sections provide the guidelines and a summary for configuring VACLs:
•
•
VACL Configuration Guidelines
This section describes the guidelines for configuring VACLs:
Caution
Note
•
•
•
•
•
•
•
•
•
•
•
•
•
–
–
–
–
–
VACL Configuration Summary
To create a VACL and map it to a VLAN, perform these steps:
Step 1
Step 2
Step 3
Note
version 4/non-IPX VACLs using the same basic steps.
Note
Configuring VACLs from the CLI
This section describes how to create and activate 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 introduced in software release 7.1(1). The BDD algorithm is used in software releases prior to 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
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. BDD must be enabled in order 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 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 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 specifiy 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 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 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 ACEs, or to add ACEs to an existing IP VACL, perform these tasks in privileged mode:
If an IP protocol specification is not required, use the following syntax.
If an IP protocol is specified, use the following syntax.
set security acl ip {acl_name} {permit | deny} {src_ip_spec} [capture]
[before editbuffer_index | modify editbuffer_index] [log1 ]
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 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 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 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 traffic from source address 172.20.3.2 and place this ACE before ACE number 2 in the VACL. Optionally, you can use 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. Note that 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
To create a new IPX VACL and add ACEs, or to add 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 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 ACEs, or to add 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 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)Showing the Contents of a VACL
You can display the contents of a VACL with the show security acl info command.
To show the contents of a VACL, perform this task in privileged mode:
Show the contents of a VACL.
show security acl info {acl_name | all} [editbuffer [editbuffer_index]]
This example shows how to show 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 show 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)Showing VACL-to-VLAN Mapping
You can display VACL-to-VLAN mapping for a specified ACL or VLAN with the show security acl map command.
To show VACL-to-VLAN mapping, perform this task in privileged mode:
This example shows how to show 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 show 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 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 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 use the capture option in the set security acl (ip, ipx, and mac) commands to specify that packets that match the specified flows are captured and transmitted out of capture ports. You can specify capture ports using the set security acl capture-ports mod/ports... command. When you use the capture option, the packets that match the specified flows are captured in parallel and transmitted out of the capture ports. 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 capture ports:
•
•
•
•
•
•
For routed traffic, capture ports transmit packets only after they are Layer 3 switched; 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 traffic from one VLAN going to many VLANs, the capture port has to be a trunk carrying all output VLANs.
For 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 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 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 ports that have been specified as capture ports:
Console> (enable) show security acl capture-portsACL Capture Ports: 1/1-2,2/1-2Console> (enable)This example shows how to clear 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 messages about denied packets for the standard IP access list by entering the log keyword for 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 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, system logging messages are sent to the console. You can configure the switch to send system logging messages to a syslog server. For information on configuring system message logging, see Chapter 27, "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 1000Set Redirect Rate to 1000 pps.This example shows how to display the VACL log configuration:
Console> (enable) show security acl log configVACL LOG Configration-------------------------------------------------------------Max Flow Pattern : 512Redirect Rate (pps) : 1000This example shows how to create an ACE for my_cap and specify that denied traffic be 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 and Storing VACLs and QoS ACLs in Flash Memory
This section describes how to configure and store VACLs and QoS ACLs in Flash memory instead of NVRAM. Prior to this feature, all configuration information was stored in NVRAM. With the addition of QoS and security ACLs (VACLs), NVRAM could become full. In addition to limiting ACL configuration, filling up NVRAM can cause problems when you attempt to upgrade from one software version to another.
Note
This section describes the following 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 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 unneeded VACLs and 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
At this point, the VACL and QoS ACL configuration is no longer in NVRAM, it is saved in the auto-config file bootflash:switchapp.cfg and will be 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. At this point, the VACL and QoS ACL configuration exists in DRAM only. A system reset for any reason 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, the following 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 what was 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 Policy-Based Forwarding
Policy-based forwarding (PBF) is an extension of VACL redirection supported by the PFC2. PBF is particularly beneficial in any flat Layer 2 network that is used for transparent bridging where a limited amount of inter-VLAN communication is required and in server farms or demilitarized zones (DMZs) where bridging devices (like server load-balancing appliances) are involved or where firewall load balancing is performed.
Note
Note
Note
Note
PBF is described in these sections:
•
•
Understanding How PBF Works
PBF configuration involves these tasks:
•
•
•
Note
When a router is not present in the network, you need to specify static ARP entries on participating hosts.
PBF Hardware and Software Requirements
PBF hardware and software requirements are as follows:
•
•
If you try to configure PBF with an MSFC2 present and booted, the system responds with a message indicating the feature is not supported with an MSFC2.
If an MSFC2 is present but has not booted, you can configure PBF.
•
Configuring PBF
This section describes the guidelines and the configuration examples for PBF. The configuration examples use the example configuration shown in Figure 16-8. The Catalyst 6500 series switch redirects all the traffic coming from Host A on VLAN 10 to Host B on VLAN 11 and redirects traffic from Host B to Host A. This section contains the following example procedures:
•
•
•
Figure 16-8 Policy-Based Forwarding
Enabling PBF and Specifying a MAC Address for the PFC2
Note
We recommend that you use the default MAC address that is provided by the MAC address PROM. When you specify your own MAC address using the set pbf mac command, if the MAC address is a duplicate of a MAC address already in use, packets might get dropped.To display the PBF status and the MAC address, perform this task in privileged mode:
To enable PBF, perform one of these tasks in privileged mode:
Enable PBF with a default MAC address.
set pbf
Enable PBF with a specific MAC address.
set pbf [mac mac_address]
This example shows how to check the PBF status and the MAC address, enable PBF with a default MAC address, and verify the change:
Console> (enable) show pbfPbf status Mac address----------- ------------------not set 00-00-00-00-00-00Console> (enable)Console> (enable) set pbfPBF committed successfully.Operation successful.Console> (enable)Console> (enable) show pbfPbf status Mac address----------- ------------------ok 00-01-64-61-39-c2Console> (enable)This example shows how to enable PBF with a specific MAC address:
Console> (enable) set pbf mac 00-11-11-11-11-11PBF committed successfully.Operation successful.Console> (enable)Console> (enable) show pbfPbf status Mac address----------- ------------------ok 00-11-11-11-11-11Console> (enable)To disable PBF and clear the PBF MAC address, perform this task in privileged mode:
This example shows how to clear the PBF MAC address:
Console> (enable) clear pbfPBF cleared.Console> (enable)Console> (enable) show pbfPbf status Mac address----------- ------------------not set 00-00-00-00-00-00Console> (enable)Configuring VACLs for PBF
Note
The source MAC address is optional. If you do not specify the source MAC address, the system defaults to the PBF MAC address.
Note
Note
1.
2.
3.
4.
5.
Note
Note
To specify an adjacency table entry for the PFC2, perform this task in privileged mode:
Specify an adjacency table entry for the PFC2.
set security acl adjacency adjacency_name dest_vlan dest_mac [[source_mac] | [source_mac mtu mtu_size] | [ mtu mtu_size]]
This example shows how to specify the adjacency table entry:
Console> (enable) set security acl adjacency ADJ1 11 00-00-00-00-00-0BADJ1 editbuffer modified. Use 'commit' command to apply changes.Console> (enable)This example shows how to create the PBF VACL for VLAN 10 (shown in Figure 16-8):
Console> (enable) set security acl adjacency ADJ1 11 00-00-00-00-00-0BADJ1 editbuffer modified. Use 'commit' command to apply changes.Console> (enable) set security acl ip IPACL1 redirect ADJ1 ip host 10.0.0.1 host 11.0.0.1IPACL1 editbuffer modified. Use 'commit' command to apply changes.Console> (enable) set security acl ip IPACL1 permit anyIPACL1 editbuffer modified. Use 'commit' command to apply changes.Console> (enable) commit security acl adjacencyCommit operation in progress.Adjacency successfully committed.Console> (enable) commit security acl IPACL1ACL commit in progress.ACL 'IPACL1' successfully committed.Console> (enable) set security acl map IPACL1 10Mapping in progress.ACL IPACL1 successfully mapped to VLAN 10.Console> (enable)This example shows how to create the PBF VACL for VLAN 11 (see Figure 16-8):
Console> (enable) set security acl adjacency ADJ2 10 00-00-00-00-00-0AADJ2 editbuffer modified. Use 'commit' command to apply changes.Console> (enable) set security acl ip IPACL2 redirect ADJ2 ip host 11.0.0.1 host 10.0.0.1IPACL2 editbuffer modified. Use 'commit' command to apply changes.Console> (enable) set security acl ip IPACL2 permit anyIPACL2 editbuffer modified. Use 'commit' command to apply changes.Console> (enable) commit security acl adjacencyCommit operation in progress.Adjacency successfully committed.Console> (enable) commit security acl IPACL2ACL commit in progress.ACL 'IPACL2' successfully committed.Console> (enable) set security acl map IPACL2 11Mapping in progress.ACL IPACL2 successfully mapped to VLAN 11.Console> (enable)Displaying PBF Information
This section describes how to display PBF-related information.
To display adjacency table entries, perform these tasks in normal mode:
This example shows how to display the adjacency table entries:
Console> show security acl info adjacencyset security acl adjacency ADJ1---------------------------------------------------1. 11 00-00-00-00-00-0bset security acl adjacency ADJ2---------------------------------------------------1. 10 00-00-00-00-00-0aConsole> show pbf adjacencyIndex DstVlan DstMac SrcMac Name------------------------------------------------------------------1 11 00-00-00-00-00-0a 00-00-00-00-00-0b ADJ12 10 00-00-00-00-00-0a 00-00-00-00-00-0b ADJ2Console> show pbf statisticsIndex DstVlan DstMac SrcMac HitCount(hex) Name-------------------------------------------------------------------------1 11 00-00-00-00-00-0a 00-00-00-00-00-0b 0x00000000 ADJ12 10 00-00-00-00-00-0a 00-00-00-00-00-0b 0x00000000 ADJ2Console> show pbf mapAdjacency ACL------------------ --------------------ADJ1 IPACL1ADJ2 IPACL2Console> (enable)Clearing Entries in PBF VACLs
You cannot clear the adjacency table entry before the redirect ACE. You should clear the redirect ACE and the adjacency table entry in PBF VACLs in the following order:
1.
2.
3.
4.
To clear a PBF adjacency table entry, perform this task in privileged mode:
This example shows how to clear a PBF adjacency table entry:
Console> (enable) clear security acl adjacency ADJ1Adj is in use by a VACL, clear the VACL first then clear adj.Console> (enable) clear security acl IPACL1IPACL1 editbuffer modified. Use 'commit' command to save changes.Console> (enable) commit security acl IPACL1ACL commit in progress.ACL 'IPACL1' successfully deleted.Console> (enable) clear security acl adjacency ADJ1ADJ1 editbuffer modified. Use 'commit' command to apply changes.Console> (enable) commit security acl adjacencyConsole> (enable) Adjacency committed successfullyCommit operation in progress.Console> (enable)Rolling Back Adjacency Table Entries in the Edit Buffer
You can clear adjacency table entries in the edit buffer that were made prior to the last commit by using the rollback command. The adjacency table entries are rolled back to their state at the last commit.
To roll back the adjacency table entries in the edit buffer, perform this task in privileged mode:
Roll back the adjacency table entries in the edit buffer.
rollback security acl {acl_name | all | adjacency}
This example shows how to roll back the adjacency table entries in the edit buffer:
Console> (enable) rollback security acl adjacencyEditbuffer for adjacency info rolled back to last commit state.Console> (enable)Configuring Hosts for PBF
This section describes the host configuration procedures for the following platforms and operating systems:
Note
Note
Linux
These examples show how to configure the ARP table for hosts running the Linux operating system.
This example shows how to configure Host A:
arp -s 11.0.0.1 00:11:11:11:11:11 -i eth0route add 11.0.0.1 eth0arp -s 10.0.0.1 00:11:11:11:11:11 -i eth1route add 10.0.0.1 eth1Sun Workstation
When using PBF to enable forwarding between two VLANs with Sun Workstation end hosts, note that there are limitations you must take into account when configuring the hosts:
•
PBF does not support ARP; you must set a static ARP entry on each Sun Workstation that participates in PBF. Each static ARP entry must point to the PBF MAC address that is mapped to the destination host.
You must also configure the Sun Workstation to have a gateway. If the Sun Workstation needs to communicate to a different network, you must define the host routes for all networks that go through PBF, and if required, you must define a default gateway.
For example, if host 10.0.0.1 on VLAN 40 needs to communicate with host 11.0.0.1 on VLAN 50, and assuming the PBF MAC address is 00-11-11-11-11-11, the static ARP entry would be as follows:
arp -s 11.0.0.1 00:11:11:11:11:11where 00-11-11-11-11-11 is the PBF MAC address, and 11.0.0.1 is the IP address of the destination host.
•
Sun Workstations do not allow you to set a static ARP entry if the destination is part of a different network (11.x.x.x in this example). This is a limitation of ARP in all Sun Workstations. To overcome this problem, you need to define a dummy gateway, which is a host route, and set a static ARP entry pointing to the PBF MAC address that is mapped to the destination host.
Using the example above, you need to first define a dummy static ARP entry for the gateway. The IP address of the gateway is one of the host addresses within that network as follows:
(A) Kubera# arp -s 10.0.0.2 00:11:11:11:11:11(B) Kubera# route add host 11.0.0.1 10.0.0.2You need to set only one dummy ARP entry for PBF-related traffic and the host routes for each destination host.
If the number of hosts increase, you need to set the host route entries for each destination host. You can set up a startup file in /etc/rc2.d that has host route entries for each destination host. Setting up this file prevents you from having to key in all the host route entries after the Sun Workstation is reset or rebooted.
Entries in the file should use this form:
Route add host <destination Host IP Address> <dummy gateway IP Address>You need to use the file that contains the host route entries as one of the startup scripts. You can create the file in a directory that has full permissions for the root/superuser, set a soft link pointing to that file in /etc/rc2.d, or create the file in the /etc/rc2.d directory itself.
MS-Windows/NT/2000 Hosts
Similar to the Sun Workstations setup, you must also set the static ARP entries on Windows-based PCs. For Windows-based PCs, you do not need to set up any dummy gateways for switching between VLANs with PBF.
This example shows how to configure the static ARP entries in Windows-based platforms:
C:\> arp -s 11.0.0.1 00-11-11-11-11-11In this example, 00-11-11-11-11-11 is the PBF MAC address and 11.0.0.1 is the IP address of the destination host.
If you need to configure more hosts, you can create a batch file with ARP entries to each destination host and specify that Windows use this file at startup.
PBF Configuration Example
This section provides the example configurations to enable PBF between hosts on VLAN 1 and hosts on VLAN 2 (see Figure 16-9).
Figure 16-9 Policy-Based Forwarding Configuration Example
This example shows the switch configuration file that was created to enable PBF between the hosts on VLAN 1 and VLAN 2. Only the first four hosts from each VLAN are shown in the example (44.0.0.1 through 44.0.0.4 and 43.0.0.1 through 43.0.0.4).
#security ACLsclear security acl all#adj setset security acl adjacency a_1 2 00-0a-0a-0a-0a-0aset security acl adjacency a_2 2 00-0a-0a-0a-0a-0bset security acl adjacency a_3 2 00-0a-0a-0a-0a-0cset security acl adjacency a_4 2 00-0a-0a-0a-0a-0dset security acl adjacency b_1 1 00-20-20-20-20-20set security acl adjacency b_2 1 00-20-20-20-20-21set security acl adjacency b_3 1 00-20-20-20-20-22set security acl adjacency b_4 1 00-20-20-20-20-23#ip1set security acl ip ip1 permit arpset security acl ip ip1 redirect a_1 ip host 44.0.0.1 host 43.0.0.1set security acl ip ip1 redirect a_2 ip host 44.0.0.2 host 43.0.0.2set security acl ip ip1 redirect a_3 ip host 44.0.0.3 host 43.0.0.3set security acl ip ip1 redirect a_4 ip host 44.0.0.4 host 43.0.0.4set security acl ip ip1 permit ip any any#ip2set security acl ip ip2 permit arpset security acl ip ip2 redirect b_1 ip host 43.0.0.1 host 44.0.0.1set security acl ip ip2 redirect b_2 ip host 43.0.0.2 host 44.0.0.2set security acl ip ip2 redirect b_3 ip host 43.0.0.3 host 44.0.0.3set security acl ip ip2 redirect b_4 ip host 43.0.0.4 host 44.0.0.4set security acl ip ip2 permit ip any any#pbf setset pbf mac 00-11-22-33-44-55#commit security acl allset security acl map ip1 1set security acl map ip2 2This example shows how to display the MAC addresses that were learned by the switch for port 6/17 on VLAN 1:
Console> (enable) show cam dynamic 6/17* = Static Entry. + = Permanent Entry. # = System Entry. R = Router Entry.X = Port Security Entry $ = Dot1x Security EntryVLAN Dest MAC/Route Des [CoS] Destination Ports or VCs / [Protocol Type]---- ------------------ ----- -------------------------------------------1 00-20-20-20-20-23 6/17 [ALL]1 00-20-20-20-20-22 6/17 [ALL]1 00-20-20-20-20-21 6/17 [ALL]1 00-20-20-20-20-20 6/17 [ALL]1 00-20-20-20-20-27 6/17 [ALL]1 00-20-20-20-20-26 6/17 [ALL]1 00-20-20-20-20-25 6/17 [ALL]1 00-20-20-20-20-24 6/17 [ALL]1 00-20-20-20-20-2b 6/17 [ALL]1 00-20-20-20-20-2a 6/17 [ALL]1 00-20-20-20-20-29 6/17 [ALL]1 00-20-20-20-20-28 6/17 [ALL]1 00-20-20-20-20-2f 6/17 [ALL]1 00-20-20-20-20-2e 6/17 [ALL]1 00-20-20-20-20-2d 6/17 [ALL]1 00-20-20-20-20-2c 6/17 [ALL]Total Matching CAM Entries Displayed for 6/17 = 16 for port 6/9, vlan 2This example shows how to display the MAC addresses that were learned by the switch for port 6/9 on VLAN 2:
Console> (enable) show cam dynamic 6/9* = Static Entry. + = Permanent Entry. # = System Entry. R = Router Entry.X = Port Security Entry $ = Dot1x Security EntryVLAN Dest MAC/Route Des [CoS] Destination Ports or VCs / [Protocol Type]---- ------------------ ----- -------------------------------------------2 00-0a-0a-0a-0a-0e 6/9 [ALL]2 00-0a-0a-0a-0a-0f 6/9 [ALL]2 00-0a-0a-0a-0a-0c 6/9 [ALL]2 00-0a-0a-0a-0a-0d 6/9 [ALL]2 00-0a-0a-0a-0a-0a 6/9 [ALL]2 00-0a-0a-0a-0a-0b 6/9 [ALL]2 00-0a-0a-0a-0a-19 6/9 [ALL]2 00-0a-0a-0a-0a-18 6/9 [ALL]2 00-0a-0a-0a-0a-17 6/9 [ALL]2 00-0a-0a-0a-0a-16 6/9 [ALL]2 00-0a-0a-0a-0a-15 6/9 [ALL]2 00-0a-0a-0a-0a-14 6/9 [ALL]2 00-0a-0a-0a-0a-13 6/9 [ALL]2 00-0a-0a-0a-0a-12 6/9 [ALL]2 00-0a-0a-0a-0a-11 6/9 [ALL]2 00-0a-0a-0a-0a-10 6/9 [ALL]Total Matching CAM Entries Displayed for 6/9 = 16This example shows how to display the PBF status and the PFC2 MAC address:
Console> (enable) show pbfPbf status Mac address----------- ------------------ok 00-11-22-33-44-55This example shows how to display the PBF statistics:
Console> (enable) show pbf statisticsIndex DstVlan DstMac SrcMac HitCount(hex) Name-------------------------------------------------------------------------1 2 00-0a-0a-0a-0a-0a 00-11-22-33-44-55 0x00026d7c a_12 2 00-0a-0a-0a-0a-0b 00-11-22-33-44-55 0x00026d83 a_23 2 00-0a-0a-0a-0a-0c 00-11-22-33-44-55 0x00026d89 a_34 2 00-0a-0a-0a-0a-0d 00-11-22-33-44-55 0x00026d90 a_45 1 00-20-20-20-20-20 00-11-22-33-44-55 0x000260e3 b_16 1 00-20-20-20-20-21 00-11-22-33-44-55 0x000260ea b_27 1 00-20-20-20-20-22 00-11-22-33-44-55 0x000260f1 b_38 1 00-20-20-20-20-23 00-11-22-33-44-55 0x000260f8 b_4Enhancements to PBF Configuration
This section describes how to configure PBF using the configuration commands that are available in software release 7.5(1) and later releases. The enhancements added to the PBF feature simplify the process of setting and committing the security ACLs and adjacency information.
These sections describe the PBF configuration enhancements:
•
•
•
PBF Configuration Enhancement Overview
The new set pbf-map command creates the security ACLs and adjacency information based on your input and then automatically commits the ACLs. The set pbf-map command involves two steps, as follows:
Step 1
This step creates an entry in the adjacency table for each redirect-to-adjacency ACE that is added to the ACL.
Step 2
This step creates an ACE in each ACL for the redirect-to-adjacency entry, and if necessary, adds a permit ip any any ACE to the end of the ACL (this ACE is added only if the permit ip any any ACE is not already in the ACL).
The set pbf-map command syntax is set pbf-map ip_addr_1 mac_1 vlan_1 ip_addr_2 mac_2 vlan_2.
An example of the simplified syntax is set pbf-map 1.1.1.1 0-0-0-0-0-1 11 2.2.2.2 0-0-0-0-0-2 12.
The new set pbf-map command is equivalent to all of the following pre-release 7.5(1) commands:
set security acl adjacency PBF_MAP_ADJ_0 11 0-0-0-0-0-1set security acl adjacency PBF_MAP_ADJ_1 12 0-0-0-0-0-2commit security acl adjacencyset security acl ip PBF_MAP_ACL_11 redirect PBF_MAP_ADJ_1 ip host 1.1.1.1 host 2.2.2.2set security acl ip PBF_MAP_ACL_12 redirect PBF_MAP_ADJ_0 ip host 2.2.2.2 host 1.1.1.1If the permit ip any any ACE is missing, the following two permit ip any any entries are added:
set security acl ip PBF_MAP_ACL_11 permit ip any anyset security acl ip PBF_MAP_ACL_12 permit ip any anycommit security acl ip PBF_MAP_ACL_11commit security acl ip PBF_MAP_ACL_12set security acl map PBF_MAP_ACL_11 11set security acl map PBF_MAP_ACL_12 12Each entry in the ACL that is added by the set pbf-map command is inserted before the default permit ip any any ACE.
If you want to add entries other than the redirect ACEs to the adjacency table, use the set security acl ip PBF_MAP_ACL_(VLAN_ID) command. The PBF_MAP_ACL_(VLAN_ID) ACL name is based on the following algorithm: The VLAN number of the corresponding host is added to the PBF_MAP_ACL_ string.
Use the clear pbf-map command to delete the redirect-to-adjacency ACEs and adjacency information that is contained in the PBF_MAP_ACL_(VLAN_ID) ACL. Use the clear security acl command to clear all other ACE types that are part of the PBF_MAP_ACL_(VLAN_ID) ACL.
Specifying a PBF_MAP_ACL
Note
To specify a PBF_MAP_ACL, perform this task in privileged mode:
This example shows how to specify a PBF_MAP_ACL:
Console> (enable) set pbf-map 1.1.1.1 0-0-0-0-0-1 11 2.2.2.2 0-0-0-0-0-2 22Commit operation successful.Commit operation successful.ACL 'PBF_MAP_ACL_11' successfully committed.Console> (enable)ACL PBF_MAP_ACL_11 successfully mapped to VLAN 11.Console> (enable)ACL 'PBF_MAP_ACL_22' successfully committed.Console> (enable)ACL PBF_MAP_ACL_22 successfully mapped to VLAN 22.Console> (enable) Operation successful.Console> (enable)Displaying the PBF_MAP_ACL Information
To display the PBF_MAP_ACL information, perform this task in normal mode:
This example shows how to display all the PBF maps that have been configured:
Console> (enable) show pbf-map allIndex DstVlan DstMac SrcMac HitCount(hex) Name-------------------------------------------------------------------------1 11 00-00-00-00-00-01 00-00-00-00-00-00 0x00000000 PBF_MAP_ADJ_02 22 00-00-00-00-00-02 00-00-00-00-00-00 0x00000000 PBF_MAP_ADJ_1Console> (enable)This example shows how to display the PBF-related ACEs for the specified VLAN and the statistics for each adjacency used:
Console> (enable) show pbf-map 11Index DstVlan DstMac SrcMac HitCount(hex) Name-------------------------------------------------------------------------1 22 00-00-00-00-00-02 00-00-00-00-00-00 0x00000000 PBF_MAP_ADJ_1Console> (enable)This example shows the PBF map configuration:
Console> (enable) show pbf-map configset pbf_map 1.1.1.1 00-00-00-00-00-01 11 2.2.2.2 00-00-00-00-00-02 22Console> (enable)Clearing the PBF_MAP_ACL Configuration
To clear the PBF_MAP_ACL configuration, perform this task in normal mode:
Clear the PBF_MAP_ACL configuration.
clear pbf-map all | vlan vlan | ip_addr_1 mac_1 vlan_1 ip_addr_2 mac_2 vlan_2
This example shows how to clear all the ACLs and adjacency information that were created by the set pbf-map command:
Console> (enable) clear pbf-map allACL 'PBF_MAP_ACL_11' successfully deleted.Console> (enable)ACL 'PBF_MAP_ACL_22' successfully deleted.Console> (enable)This example shows how to clear the ACL with the name PBF_MAP_ACL_VLAN_# and the adjacency table that was used by that ACL:
Console> (enable) clear pbf-map vlan 11ACL 'PBF_MAP_ACL_11' successfully deleted.Console> (enable) Commit operation successful.Console> (enable)This example shows how to clear all the ACEs that were created by the set pbf-map command except the permit ip any any ACE. The command removes the entries that enable traffic between the hosts with ip_addr_1 and ip_addr_2 on vlan_1 and vlan_2. If the entries were already deleted using the clear security acl command, a message is displayed indicating that the specific entry was already cleared. The actual entries that were deleted are two ACEs (redirect-to-adjacency ACEs) and two entries in the adjacency table.
Console> (enable) clear pbf-map 1.1.1.1 0-0-0-0-0-1 11 2.2.2.2 0-0-0-0-0-2 22ACL 'PBF_MAP_ACL_11' successfully committed.Console> (enable)ACL 'PBF_MAP_ACL_22' successfully committed.Console> (enable)
