-
Catalyst 6500 Series Software Configuration Guide, 6.3 and 6.4
-
Product Overview
-
Command-Line Interfaces
-
Configuring the Switch IP Address and Default Gateway
-
Configuring Ethernet, Fast Ethernet, and Gigabit Ethernet Switching
-
Configuring Ethernet VLAN Trunks
-
Configuring EtherChannel
-
Configuring IEEE 802.1Q 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 Port 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 SNMP
-
Configuring RMON
-
Configuring SPAN and RSPAN
-
Using Switch TopN Reports
-
Configuring Multicast Services
-
Configuring QoS
-
Configuring a VoIP Network
-
Configuring ASLB
-
Configuring the Switch Fabric Modules
-
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
Using VACLs with Cisco IOS ACLs
Guidelines for Configuring Cisco IOS ACLs and VACLs on the Same VLAN Interface
Using the Implicit Deny Action
Limiting the Number of Actions
Avoiding Layer 4 Port Information
Guidelines for Using Layer 4 Operations
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
Configuring ACLs on Private VLANs
Configuring VACLs From the CLI
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
Understanding How Policy-Based Forwarding Works
Hardware and Software Requirements
Configuring Policy-Based Forwarding
Enabling PBF and Specifying a MAC Address for the PFC2
Rolling Back Adjacency Table Entries in the Edit Buffer
Policy-Based Forwarding Configuration Example
Configuring Access Control
This chapter describes how to configure access control lists (ACLs) on the Catalyst 6000 family switches. Configuration of the ACLs depends on the type of hardware 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 6000 Family 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 6000 family 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 6000 family switches is as follows:
•
–
–
•
–
–
Note
Supported ACLs
These sections describe the ACLs supported by the Catalyst 6000 family switches:
QoS ACLs
You can configure QoS ACLs on the switch; see "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 in Cisco IOS software 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 ACLs that are associated with features that are configured on a given interface and a direction. As packets enter the router on a given interface, Cisco IOS software examines ACLs that are associated with all 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 examines all ACLs that are associated with the outbound features that are 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 6000 family switch; you cannot enforce VACLs on traffic between hosts on a hub or another switch connected to the Catalyst 6000 family 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 6000 family 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 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 entry 1 as follows:
1. deny tcp any host 10.1.1.2 eq www
there will not be a permit tcp any any fragments ACE 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 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 TCP servers from TCP SYN-flooding attacks, which are a type of denial-of-service attack. The TCP intercept feature 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 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 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 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 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:
•
•
•
•
•
•
•
Reflexive ACLs
ICMP packets are handled in the software. For TCP/UDP flows, once the flow is established, they are handled in 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 TCP servers from TCP SYN-flooding attacks, which are a type of denial-of-service attack. The TCP intercept feature 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 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 hardware or 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 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 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 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 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 IOS ACL configuration, the flow is denied or redirected. The following caveats apply to IOS ACLs when used with VACLs:
•
•
Note
These sections describe Cisco IOS ACL and VACL configuration guidelines and guidelines for Layer 4 operations:
•
•
Guidelines for Configuring Cisco IOS ACLs and VACLs on the Same VLAN Interface
Follow these guidelines when you need to configure 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 6000 family 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 configuration.
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.
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, see the recommendations in the "Using the Implicit Deny Action" section, "Grouping Actions Together" section, and Example 6. If you cannot follow the recommendations 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
If you follow the ACL guidelines when configuring ACLs, you can get a rough estimate of the merge results for ACLs.
The following example 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)
If Layer 4 port information was specified, the upper limit could be higher.
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
This example shows that the VACL does not follow the recommended guidelines (see line 9) 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******** 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 and modify lines 11 and 12, you get the following equivalent ACL with improved merge results (note that a deny ACE is not specified):
******** 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******** IOS ACL ************1 deny ip any host 239.255.255.2552 permit ip any any******** MERGE ***********has 78 entriesExample 3
This example shows the VACL does not follow the recommended guidelines, 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******** 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******* IOS ACL ***********1 deny ip any host 239.255.255.2552 permit ip any any******* MERGE **********has 142 entriesExample 5
This example shows the VACL has two different actions specified and 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******* IOS ACL ***********1 deny ip any host 239.255.255.2552 permit ip any any******* MERGE **********has 4 entriesExample 6
This example shows that applying the merging guidelines on a large Cisco IOS ACL (no Layer 4 port information is specified on the Cisco IOS ACL), produces a merge result of 801 entries:
******** VACL **********1 redirect 4/25 tcp host 192.168.1.67 255.255.255.255 0.0.0.02 redirect 4/25 udp host 192.168.1.67 255.255.255.255 0.0.0.03 redirect 4/25 icmp host 192.168.1.67 host 255.255.255.2554 redirect 4/25 ip host 192.168.1.67 host 255.255.255.2555 deny tcp any any lt 306 deny udp any any lt 307 permit ip any any******** IOS ACL ***********1 permit ip 147.150.213.64 0.0.0.31 194.72.6.64 0.0.0.152 permit ip 147.150.213.64 0.0.0.31 194.72.6.160 0.0.0.153 permit ip 147.150.213.64 0.0.0.31 host 194.72.6.2054 permit ip 147.151.77.0 0.0.0.255 194.72.6.64 0.0.0.155 permit ip 147.151.77.0 0.0.0.255 194.72.6.160 0.0.0.156 permit ip 147.151.77.0 0.0.0.255 194.72.6.208 0.0.0.157 permit ip 147.151.77.0 0.0.0.255 host 194.72.6.2058 permit ip host 193.37.169.121 194.72.6.64 0.0.0.15[...] total 62 entries without L4 information******** MERGE **********has 801 ACEsExample 7
This example shows that the same Cisco IOS ACL that was used in Example 6 is merged with a VACL with Layer 4 port information. Following the guidelines in the "Using the Implicit Deny Action" section, the merge results are good.
******** VACL *********1 permit tcp host 193.131.248.24 194.73.73.0 0.0.0.15 gt 10232 permit tcp host 158.43.128.8 194.72.6.224 0.0.0.7 gt 10233 permit udp any 194.72.6.224 0.0.0.7 eq time4 permit udp any 194.73.73.0 0.0.0.15 eq time5 permit udp 194.72.7.128 0.0.0.7 194.72.6.224 0.0.0.7 eq 16456 permit udp 194.72.7.128 0.0.0.7 194.73.73.0 0.0.0.15 eq 16457 permit udp host 158.152.1.65 194.72.6.224 0.0.0.7 gt 10238 permit udp host 158.152.1.65 194.73.73.0 0.0.0.15 gt 1023[...] total 168 entries******** IOS ACL *********1 permit ip 147.150.213.64 0.0.0.31 194.72.6.64 0.0.0.152 permit ip 147.150.213.64 0.0.0.31 194.72.6.160 0.0.0.153 permit ip 147.150.213.64 0.0.0.31 host 194.72.6.2054 permit ip 147.151.77.0 0.0.0.255 194.72.6.64 0.0.0.155 permit ip 147.151.77.0 0.0.0.255 194.72.6.160 0.0.0.156 permit ip 147.151.77.0 0.0.0.255 194.72.6.208 0.0.0.157 permit ip 147.151.77.0 0.0.0.255 host 194.72.6.2058 permit ip host 193.37.169.121 194.72.6.64 0.0.0.15[...] total 62 entries without L4 information******* MERGE ********has 1259 ACEs.Guidelines for Using Layer 4 Operations
Follow these guidelines for configurations where you need to specify Layer 4 port operations.
These sections provide guidelines for specifying 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 6000 family switches might not be equipped with MSFCs (routers). In this configuration, the switch can still support a VACL and a QoS ACL. Suppose 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
