|
|
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.
This chapter contains these sections:
Standard and extended 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 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.
The hardware that is required to configure ACLs on Catalyst 6000 family switches is as follows:
The following sections describe the ACLs supported by the Catalyst 6000 family switches: IOS ACLs, VACLs, and QoS ACLs.
IOS ACLs are configured on the MSFC (router) VLAN interfaces. An ACL provides access control and consists of an ordered set of access control entries (ACEs). Many other features in IOS 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 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 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, IOS examines it multiple times.
IOS examines ACLs associated with features configured on a given interface and a direction. As packets enter the router on a given interface, IOS examines ACLs associated with all inbound features configured on that interface for the following:
After packets are routed and before they are forwarded out to the next hop, IOS examines all ACLs associated with outbound features configured on the egress interface for the following:
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 IP and IPX traffic is not access controlled by MAC VACLs. All other traffic types (AppleTalk, DecNet, and so on) are classified as MAC traffic and MAC VACLs are used to access control this traffic. |
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.
You can configure QoS ACLs on the switch; refer to the Catalyst 6000 Family Software Configuration Guide for more information.
An ACL contains an ordered list of access control entries (ACEs). 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:
Each ACL can contain ACEs of only one type. Table 7-1 lists the parameters associated with each ACE type.
| ACE Type | TCP or UDP1 | IGMP1 | ICMP1 | Other IP1 | IPX | Ethernet2 |
Source port |
|
|
|
|
| |
Source port operator |
|
|
|
|
| |
Destination |
|
|
|
|
| |
Destination |
| ICMP code3 |
|
|
| |
N/A | IGMP4 message type | ICMP type | N/A |
|
| |
IP ToS byte | IP ToS byte | IP ToS byte | IP ToS byte |
|
| |
IP source address | IP source address | IP source address | IP source address | IPX source network |
| |
IP destination address | IP destination address | IP destination address | IP destination address | IPX destination network |
| |
|
|
|
| IPX destination node |
| |
TCP or UDP | IGMP | ICMP | Other protocol | IPX packet type |
| |
Layer 2 parameters |
|
|
|
|
| Ethertype |
|
|
|
|
| Ethernet source address | |
|
|
|
|
| Ethernet destination address |
| 1IP ACEs. 2For Ethernet packets that are not IP version 4 or IPX. 3ICMP echo-reply cannot be filtered. All other ICMP code/types can be filtered. 4IGMP traffic can be filtered only when IGMP snooping is not enabled on the switch. |
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.
In the example below, 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.
Console>(enable) redirect 4/3 tcp host 1.1.1.1 eq 68 host 255.255.255.255
In the example below, 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 with an offset other than 0 are also permitted as a default result for fragments.
Console>(enable) permit tcp host 1.1.1.1 eq 68 host 2.2.2.2 eq 34
In the example below, 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.
Console>(enable) deny tcp host 1.1.1.1 eq 68 host 2.2.2.2 eq 34
This section describes how to apply IOS ACLs and VACLs to the VLAN for bridged packets, routed packets, and multicast packets.
Figure 7-1 shows how an ACL is applied on bridged packets. For bridged packets, only
Layer 2 ACLs are applied to the input VLAN.
Figure 7-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. VACL for input VLAN
2. Input IOS ACL
3. Output IOS ACL
4. VACL for output VLAN
Figure 7-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. Packets that need multicast expansion:
(a) VACL for input VLAN
(b) Input IOS ACL
2. Packets after multicast expansion:
(a) Output IOS ACL
(a) VACL for output VLAN
3. Packets originating from router:
(a) VACL for output VLAN
When a feature is configured on the router to process traffic (such as NAT), the 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 IOS ACLs" section.
| Caution By default, the router sends Internet Control Message Protocol (ICMP) unreachables when a packet is denied by an access group; these access-group denied packets are not dropped in the hardware but are bridged to the router so that it can generate the ICMP-unreachable message. To drop access-group denied packets in the hardware, you must disable ICMP unreachables using the no ip unreachables interface configuration command. Note that the ip unreachables command is enabled by default. |
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.
The IP and IPX security ACLs are as follows:
Up to 512 simultaneous reflexive sessions are supported in the hardware.
TCP-intercept required flows are handled in the software without impacting non-TCP intercept flow forwarding in the hardware.
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 If you use the mls ip pbr command to enable policy routing, policy routing is applied in the hardware for all interfaces regardless of which interface was configured for policy routing. |
Hypertext Transfer Protocol (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-required flows are handled in the software without impacting non-NAT flow forwarding in the hardware.
Unicast RPF check is supported by forwarding all incoming Layer 3 unicast traffic in the software that is received on the RPF-configured interface.
IOS bridge-group ACLs are handled in the software.
To access control both bridged and routed traffic, you can use VACLs only or a combination of IOS ACLs and VACLs. You can define 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:
Follow these guidelines when you need to configure an IOS ACL and a VACL on the same VLAN. These guidelines do not apply to configurations where you are mapping 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); therefore you must merge an IOS ACL and a VACL when they are configured on the same VLAN. Merging the IOS ACL with the VACL might significantly increase the number of ACEs.
If you must configure an IOS ACL and a VACL on the same VLAN, use the following guidelines for both IOS ACL and VACL configuration.
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).
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.
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).
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 and see Example 6. 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.
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.
These examples show the merge results for various IOS ACL and VACL configurations. Note that in these examples, one VACL and one IOS ACL are configured on the same VLAN.
This example shows 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.15 2 permit udp host 147.150.213.94 194.72.6.64 0.0.0.15 eq bootps 3 permit udp 194.73.74.0 0.0.0.255 host 194.72.6.205 eq syslog 4 permit udp host 167.221.23.1 host 194.72.6.198 eq tacacs 5 permit udp 194.72.136.1 0.0.3.128 194.72.6.64 0.0.0.15 eq tftp 6 permit udp host 193.6.65.17 host 194.72.6.205 gt 1023 7 permit tcp any host 194.72.6.52 8 permit tcp any host 194.72.6.52 eq 113 9 deny tcp any host 194.72.6.51 eq ftp 10 permit tcp any host 194.72.6.51 eq ftp-data 11 permit tcp any host 194.72.6.51 12 permit tcp any eq domain host 194.72.6.51 13 permit tcp any host 194.72.6.51 gt 1023 14 permit ip any host 1.1.1.1 ******** IOS ACL ************ 1 deny ip any host 239.255.255.255 2 permit ip any any ******** MERGE ********** has 91 entries entries
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.15 2 permit udp host 147.150.213.94 194.72.6.64 0.0.0.15 eq bootps 3 permit udp 194.73.74.0 0.0.0.255 host 194.72.6.205 eq syslog 4 permit udp host 167.221.23.1 host 194.72.6.198 eq tacacs 5 permit udp 194.72.136.1 0.0.3.128 194.72.6.64 0.0.0.15 eq tftp 6 permit udp host 193.6.65.17 host 194.72.6.205 gt 1023 7 permit tcp any host 194.72.6.52 8 permit tcp any host 194.72.6.52 eq 113 9 permit tcp any host 194.72.6.51 eq ftp-data 10 permit tcp any host 194.72.6.51 neq ftp 11 permit tcp any eq domain host 194.72.6.51 neq ftp 12 permit tcp any host 194.72.6.51 gt 1023 13 permit ip any host 1.1.1.1 ******** IOS ACL ************ 1 deny ip any host 239.255.255.255 2 permit ip any any ******** MERGE *********** has 78 entries
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 any 2 deny ip 0.0.0.255 255.255.255.0 any 3 deny ip any 0.0.0.0 255.255.255.0 4 permit ip any host 239.255.255.255 5 permit ip any host 255.255.255.255 6 deny ip any 0.0.0.255 255.255.255.0 7 permit tcp any range 0 65534 any range 0 65534 8 permit udp any range 0 65534 any range 0 65534 9 permit icmp any any 10 permit igmp any any 11 permit ip any any ******** IOS ACL ********** 1 deny ip any host 239.255.255.255 2 permit ip any any ******** MERGE ********** has 329 entries
This example shows 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.255 2 redirect 4/25 udp host 192.168.1.67 host 255.255.255.255 3 deny tcp any any lt 30 4 deny udp any any lt 30 5 permit ip any any ******* IOS ACL *********** 1 deny ip any host 239.255.255.255 2 permit ip any any ******* MERGE ********** has 142 entries
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.255 2 redirect 4/25 udp host 192.168.1.67 host 255.255.255.255 3 permit ip any any ******* IOS ACL *********** 1 deny ip any host 239.255.255.255 2 permit ip any any ******* MERGE ********** has 4 entries
This example shows that applying the merging guidelines on a large IOS ACL (no Layer 4 port information is specified on the 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.0 2 redirect 4/25 udp host 192.168.1.67 255.255.255.255 0.0.0.0 3 redirect 4/25 icmp host 192.168.1.67 host 255.255.255.255 4 redirect 4/25 ip host 192.168.1.67 host 255.255.255.255 5 deny tcp any any lt 30 6 deny udp any any lt 30 7 permit ip any any ******** IOS ACL *********** 1 permit ip 147.150.213.64 0.0.0.31 194.72.6.64 0.0.0.15 2 permit ip 147.150.213.64 0.0.0.31 194.72.6.160 0.0.0.15 3 permit ip 147.150.213.64 0.0.0.31 host 194.72.6.205 4 permit ip 147.151.77.0 0.0.0.255 194.72.6.64 0.0.0.15 5 permit ip 147.151.77.0 0.0.0.255 194.72.6.160 0.0.0.15 6 permit ip 147.151.77.0 0.0.0.255 194.72.6.208 0.0.0.15 7 permit ip 147.151.77.0 0.0.0.255 host 194.72.6.205 8 permit ip host 193.37.169.121 194.72.6.64 0.0.0.15 [...] total 62 entries without L4 information ******** MERGE ********** has 801 ACEs
This example shows that the same 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 1023 2 permit tcp host 158.43.128.8 194.72.6.224 0.0.0.7 gt 1023 3 permit udp any 194.72.6.224 0.0.0.7 eq time 4 permit udp any 194.73.73.0 0.0.0.15 eq time 5 permit udp 194.72.7.128 0.0.0.7 194.72.6.224 0.0.0.7 eq 1645 6 permit udp 194.72.7.128 0.0.0.7 194.73.73.0 0.0.0.15 eq 1645 7 permit udp host 158.152.1.65 194.72.6.224 0.0.0.7 gt 1023 8 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.15 2 permit ip 147.150.213.64 0.0.0.31 194.72.6.160 0.0.0.15 3 permit ip 147.150.213.64 0.0.0.31 host 194.72.6.205 4 permit ip 147.151.77.0 0.0.0.255 194.72.6.64 0.0.0.15 5 permit ip 147.151.77.0 0.0.0.255 194.72.6.160 0.0.0.15 6 permit ip 147.151.77.0 0.0.0.255 194.72.6.208 0.0.0.15 7 permit ip 147.151.77.0 0.0.0.255 host 194.72.6.205 8 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.
Follow these guidelines for configurations where you need to specify operations to be performed on Layer 4 ports.
The switch hardware allows you to specify the following types of operations: gt, lt, neq, and range. Operations are different if the operator or the operand are different. For example "lt 5" is one operation, "lt 6" is another, and so on.
We recommend that you do not specify more than seven 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 that if you have an IOS ACL and a VACL on the same VLAN interface, the recommended total number of Layer 4 operations is still 7 or less.
We recommend you check the resource usage using the show security acl resource-usage command in order to see the impact of having exceeded the recommended number of Layer 4 operations.
This section describes some typical uses for VACLs and includes the following:
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 7-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.
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 7-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):
| Task | Command |
|---|---|
Step 1 Redirect the broadcast packets. | set security acl ip SERVER redirect 4/1 tcp any host 255.255.255.255 eq 5000 |
Step 2 Permit all other traffic. | set security acl ip SERVER permit ip any any |
Step 3 Commit the VACL. | commit security acl SERVER |
Step 4 Map the VACL to VLAN 10. | set security acl map SERVER 10 |
When 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.
| Task | Command |
|---|---|
Step 1 Permit DHCP response from host 1.2.3.4. | set security acl ip SERVER permit tcp host 1.2.3.4 any eq 68 |
Step 2 Deny DHCP responses from any other host. | set security acl ip SERVER deny tcp any any eq 68 |
Step 3 Permit other IP traffic. | set security acl ip SERVER permit any any |
Step 4 Commit the VACL. | commit security acl SERVER |
Step 5 Map the VACL to VLAN 10. | set security acl map SERVER 10 |
Figure 7-6 shows that only the target server returns a DHCP response from the DHCP request.
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 7-7):
To deny access to a server on another VLAN, perform this task in privileged mode:
| Task | Command |
|---|---|
Step 1 Deny traffic from hosts in subnet 10.1.2.0/8. | set security acl ip SERVER deny ip 10.1.2.0 0.0.0.255 host 10.1.1.100 |
Step 2 Deny traffic from host 10.1.1.4. | set security acl ip SERVER deny ip host 10.1.1.4 host 10.1.1.100 |
Step 3 Deny traffic from host 10.1.1.8. | set security acl ip SERVER deny ip host 10.1.1.8 host 10.1.1.100 |
Step 4 Permit other IP traffic. | set security acl ip SERVER permit ip any any |
Step 5 Commit the VACL. | commit security acl SERVER |
Step 6 Map the VACL to VLAN 10. | set security acl map SERVER 10 |
See the "Capturing Traffic Flows on Specified Ports" section for complete configuration details.
This section lists ACL-related features that are not supported or have limited support on the Catalyst 6000 family switches.
This section describes how to configure VACLs. Prior to performing any configuration tasks, see the "VACL Configuration Guidelines" section.
Follow these guidelines when configuring VACLs:
| Caution All changes to ACLs are stored temporarily in an edit buffer. You must use the commit command to commit all ACEs to NVRAM. Committed ACLs with no ACEs are deleted. We recommend that you enter ACEs in batches and issue the commit command to save all of them to NVRAM. |
To create a VACL and map it to a VLAN, perform these steps:
Step 1 Enter the set security acl ip command to create a VACL and add ACEs.
Step 2 Enter the commit command to commit the VACL and its associated ACEs to NVRAM.
Step 3 Enter the set security acl map command to map the VACL to a VLAN.
This section describes how to create and activate VACLs on the Catalyst 6000 family switches. These tasks are listed in the order that they should be performed.
This section describes the following tasks:
To create a new IP VACL and add ACEs, or to add ACEs to an existing IP VACL, perform these tasks in privileged mode:
| Task | Command |
|---|---|
| set security acl ip {acl_name} {permit | deny} {src_ip_spec} |
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)
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)
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 stored in NVRAM (use 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 host can be used as an abbreviation for a source and source-wildcard of 0.0.0.0. This ACE also specifies:
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)
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)
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.
To create a new IPX VACL and add ACEs, or to add ACEs to an existing IPX VACL, perform this task in privileged mode:
| Task | Command |
|---|---|
Create a new IPX VACL and add ACEs, | set security acl ipx {acl_name} {permit | deny | redirect mod_num/port_num} {protocol} {src_net} [dest_net.[dest_node] [[dest_net_mask.]dest_node_mask]] [capture] [before editbuffer_index modify editbuffer_index] |
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.4 3. redirect 4/1 any 3456Console> (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)
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 show 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 any1.A.3.4 4. redirect 4/1 any 3456 5. permit any any ACL 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)
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.
| Caution IP and IPX traffic is not access controlled by MAC VACLs. All other traffic types (AppleTalk, DecNet, and so on) are classified as MAC traffic and MAC VACLs are used to access control this traffic. |
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:
| Task | Command |
|---|---|
Create a new non-IP version 4/non-IPX VACL and add ACEs, or add ACEs to an existing non-IP version 4/non-IPX VACL. | set security acl mac {acl_name} {permit | deny} {src_mac_addr_spec} {dest_mac_addr_spec} [ether-type] [capture] [before editbuffer_index | modify editbuffer_index] |
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 any 2. deny any A-B-C-D-1-2 3. permit any anyConsole> (enable)
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)
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.
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:
| Task | Command |
|---|---|
Commit an ACL to NVRAM. | commit security acl acl_name | all |
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)
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:
| Task | Command |
|---|---|
Map a VACL to a VLAN. | set security acl map acl_name vlans |
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)
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:
| Task | Command |
|---|---|
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 any
This 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)
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:
| Task | Command |
|---|---|
Show VACL-to-VLAN mapping. | show security acl map {acl_name | vlan | all} |
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)
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:
| Task | Command |
|---|---|
Clear the ACL edit buffer. | rollback security acl {acl_name | all} |
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)
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:
| Task | Command |
|---|---|
Remove an ACE from a security ACL. | clear security acl all |
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)
You can remove VACL-to-VLAN mapping with the clear security acl map command.
To clear the security ACL map, perform this task in privileged mode:
| Task | Command |
|---|---|
Clear the security ACL map. | clear security acl map all |
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)
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:
| Task | Command |
|---|---|
Display VACL management information. | show security acl resource-usage |
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)
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, packets that match the specified flows are switched normally but are also captured 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.
Follow these guidelines when configuring capture ports:
To capture traffic flows, perform these steps:
Step 1 Enter the set security acl ip command to create a VACL and add ACEs; include the capture option.
Step 2 Enter the commit command to commit the VACL and its associated ACEs to NVRAM.
Step 3 Enter the set security acl map command to map the VACL to a VLAN.
Step 4 Enter the set security acl capture-ports mod/ports... command to specify capture ports.
This example shows how to create an ACE for my_cap and specify that the allowed traffic be captured:
Console> (enable) set security acl ip my_cap permit ip host 60.1.1.1 host 60.1.1.98 capture my_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_cap ACL 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 10 Mapping 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-2 Successfully set the following ports to capture ACL traffic: 1/1-2,2/1-2 Console> (enable)
This example shows how to display ports that have been specified as capture ports:
Console> (enable) show sec acl capture-ports ACL Capture Ports: 1/1-2,2/1-2 Console> (enable)
This example shows how to clear capture ports:
Console> (enable) clear sec acl capture-ports 1/1,2/1 Successfully cleared the following ports: 1/1,2/1 Console> (enable)
This example shows that ports 1/1 and 2/1 were cleared:
Console> (enable) show sec acl capture-ports ACL Capture Ports:1/2,2/2 Console> (enable)
This section describes how to configure and store 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.
This section describes the following tasks:
Moving the 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.cfg 1999 Sep 01 17:00:00 %SYS-1-CFG_ACL_DEALLOC:NVRAM full. Qos/Security ACL configuration deleted from NVRAM.
The 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.cfg 1999 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 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 "set config acl nvram" section). Alternatively, you might try to delete unneeded ACLs and save the ACL configuration to NVRAM using the set config acl nvram command.
If your ACL configuration requirements require more memory than the 512-KB NVRAM, you can manually move the ACL configuration to Flash memory as follows:
Step 1 Specify the ACL auto-config file to use to configure the switch at startup.
Console> (enable) set boot auto-config bootflash:switchapp.cfg CONFIG_FILE variable = bootflash:switchapp.cfg Console> (enable)
Step 2 Specify if the switch should retain (recurring keyword) or clear (non-recurring keyword) the contents of the CONFIG_FILE environment variable after a reset or power cycle.
Console> (enable) set boot config-register auto-config recurring Configuration register is 0x12F ignore-config: disabled auto-config: recurring, overwrite, sync disabled console baud: 9600 boot: image specified by the boot system commands Console> (enable)
Step 3 Specify if the auto-config file should be used to overwrite the NVRAM configuration or be appended to what is currently in NVRAM.
Console> (enable) set boot config-register auto-config append Configuration register is 0x12F ignore-config: disabled auto-config: recurring, append, sync disabled console baud: 9600 boot: image specified by the boot system commands Console> (enable)
Step 4 Specify if synchronization should be enabled or disabled. With synchronization enabled, the auto-config file(s) synchronize automatically to the standby supervisor engine.
Console> (enable) set boot config-register auto-config sync enable Configuration register is 0x12F ignore-config: disabled auto-config: recurring, append, sync enabled console baud: 9600 boot: image specified by the boot system commands Console> (enable)
Step 5 Save committed ACL configuration changes to the auto-config file.
Console> (enable) copy acl-config bootflash:switchapp.cfg Upload ACL configuration to bootflash:switchapp.cfg 2843644 bytes available on device bootflash, proceed (y/n) [n]? y ACL configuration has been copied successfully. Console> (enable)
Step 6 Delete the ACL configuration from NVRAM.
Console> (enable) clear config acl nvram ACL configuration has been deleted from NVRAM. Warning: Use the copy commands to save the ACL configuration to a file and the 'set boot config-register auto-config' commands to configure the auto-config feature.
At this point, the 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 ACL configuration and committing those changes, you must use 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 ACL configuration to Flash memory, it is removed from NVRAM. At this point, the ACL configuration exists in DRAM only. A system reset for any reason can cause the ACL configuration to revert to the default. If you cannot write the configuration to Flash memory, you must copy the configuration to a file, make additional room available in Flash memory, and then try to write the ACL configuration to Flash memory.
At system startup, if the 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.
Once you move the ACL configuration to Flash memory, 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:
This example shows how to move the ACL configuration back to NVRAM:
Console> (enable) set config acl nvram ACL configuration copied to NVRAM. Console> (enable) Console> (enable) clear boot auto-config CONFIG_FILE variable = Console> (enable)
The set boot commands contain an option to synchronize the auto-config file automatically.
When you enable the auto-config option, if the 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.
After a supervisor engine switchover, the ACL configuration on the standby supervisor engine is consistent with what was on the active supervisor engine, just as in the case where the 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.
This section describes these CLI commands for this feature:
This command allows you to specify if the auto-config file should be used to overwrite the NVRAM configuration or if the file configuration should be appended to what is currently in NVRAM. Overwriting means that the NVRAM configuration will be cleared before executing the auto-config file; appending means that the auto-config file will be executed without first clearing NVRAM. The default is overwrite.
Console> (enable) set boot config-register auto-config help
Usage: set boot config-register auto-config {recurring | non-recurring}
set boot config-register auto-config {overwrite | append}
set boot config-register auto-config {sync {enable | disable}}
Console> (enable)
Console> (enable) set boot config-register auto-config overwrite
Configuration register is 0x12F
ignore-config: disabled
auto-config: non-recurring, overwrite, sync disabled
console baud: 9600
boot: image specified by the boot system commands
Console> (enable)
Console> (enable) set boot config-register auto-config append
Configuration register is 0x12F
ignore-config: disabled
auto-config: non-recurring, append, sync disabled
console baud: 9600
boot: image specified by the boot system commands
Console> (enable)
This command allows you to enable synchronization to force the auto-config file(s) to synchronize automatically to the standby supervisor engine. The file(s) are kept consistent with what is on the active supervisor engine. The default is disabled. These events can trigger a synchronization check and a synchronization (if necessary):
The CONFIG_FILE variable from the active supervisor engine is made identical on the standby supervisor engine. Each auto-config file on the active supervisor engine is compared against each corresponding auto-config file on the standby supervisor engine. Two files are considered identical if their lengths and CRC are the same. If a file on the standby supervisor engine is not identical to the file on the active supervisor engine, a new file is generated on the standby supervisor engine with the name of the file on the active supervisor engine. If a file with that name already exists on the standby supervisor engine, it is overwritten.
Console> (enable) set boot config-register auto-config sync disable Configuration register is 0x12F ignore-config: disabled auto-config: non-recurring, append, sync disabled console baud: 9600 boot: image specified by the boot system commands Console> (enable) Console> (enable) set boot config-register auto-config sync enable Configuration register is 0x12F ignore-config: disabled auto-config: non-recurring, append, sync enabled console baud: 9600 boot: image specified by the boot system commands Console> (enable)
This command allows you to delete the ACL configuration from NVRAM:
Console> (enable) clear config acl nvram ACL configuration has been deleted from NVRAM. Warning: Use the copy commands to save the ACL configuration to a file and the 'set boot config-register auto-config' commands to configure the auto-config feature. Console> (enable)
Once the configuration has been deleted from NVRAM, you must set up the auto-config feature by one of these methods:
Enter this command to append the auto-config file to the current NVRAM configuration at system startup (assuming the ACL configuration has been saved to the auto-config file at: bootflash:switchapp.cfg):
set boot auto-config bootflash:switchapp.cfg set boot config-register auto-config append
After running the command, the ACL configuration is written to the bootflash:switchapp.cfg file. After committing QoS ACL and VACL changes to hardware, you should also save the configuration to the auto-config file using the copy acl-config command:
copy acl-config bootflash:switchapp.cfg
Enter these commands to save the entire switch configuration to the auto-config file at system reset:
copy config bootflash:switch.cfg set boot auto-config bootflash:switch.cfg set boot config-register auto-config overwrite
After running the commands, the entire switch configuration is written to the bootflash:switch.cfg file. After making any configuration changes, enter the copy command to save the entire switch configuration to the auto-config file as follows:
copy config bootflash:switch.cfg
This command copies the ACL configuration from DRAM back into NVRAM. If there is not enough space in NVRAM, the command fails. Note that this command copies the current committed configuration to NVRAM; this configuration might be different from the configuration in the auto-config file. Once this is done, you must turn off the auto-config options. Note that the auto-config feature can be turned off using the clear boot auto-config command.
Console> (enable) set config acl nvram ACL configuration copied to NVRAM. Console> (enable) set config acl nvram Failed to copy ACL configuration to NVRAM. Insufficient NVRAM space available. Console> (enable)
This command displays the location of the ACL configuration, as follows:
Console> show config acl location ACL configuration is being saved in NVRAM. Console> Console> show config acl location ACL configuration not being saved in NVRAM. Use the copy commands to save the ACL configuration to a file. Console>
This command writes the ACL configuration to the auto-config file:
Console> (enable) copy acl-config bootflash:switchapp.cfg Upload configuration to bootflash:switchapp.cfg 2843644 bytes available on device bootflash, proceed (y/n) [n]? y ACL configuration has been copied successfully. Console> (enable)
If the ACL configuration location is set to Flash memory, this warning displays after every commit operation for either QoS ACLs or VACLs:
Warning: Use the copy commands to save your ACL configuration to flash.
If you reset the system and if you had entered one or more commits and no copy commands to one of the files specified in the CONFIG_FILE variable, this warning displays:
Warning: System ACL configuration has been modified but not saved to flash.
Posted: Tue Aug 15 07:18:00 PDT 2000
Copyright 1989-2000©Cisco Systems Inc.