|
|
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 consists of these sections:
The ACLs defined on the router VLAN interfaces to access control routed traffic between VLANs are IOS ACLs. The ACLs that can access control all packets are VLAN ACLs (VACLs).
Standard and extended IOS ACLs are used as a packet classification mechanism and classified packets can be subject to a number of features such as access control (security), encryption, policy-based routing, and so on. VACLs are configured to provide access control based on Layer 3 addresses for IP and IPX protocols. Unsupported protocols are access controlled through MAC addresses. Standard and extended IOS ACLs are only configured on router interfaces and applied on routed packets; 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.
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 ACL can be used with multiple features for a given interface and one feature can use multiple ACLs. In IOS, when a single ACL is used by multiple features, it is examined 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, ACLs associated with all inbound features configured on that interface are examined for the following:
After packets are routed and before they are forwarded out to the next hop, all ACLs associated with outbound features configured on the egress interface are examined as follows:
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 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 "Feature Support: 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 hardware but are bridged to the router so that it can generate the ICMP-unreachable message. To drop access-group denied packets in hardware, you must disable ICMP unreachables using the no ip unreachables interface configuration command. Note that the ip unreachables command is enabled by default. |
This section lists supported ACLs and indicates if the ACL is handled by hardware or software. ACL feature implementation (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 software without impacting non-log flow forwarding in hardware.
IP security ACLs are listed first followed by IPX security ACLs.
Up to 512 simultaneous reflexive sessions are supported in the hardware.
TCP-intercept required flows are handled in software without impacting non-TCP intercept flow forwarding in hardware.
Policy routing-required flows are handled in software without impacting non-policy routed flow forwarding 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 "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 hardware.
| Caution If you use the mls ip pbr command to enable policy routing, policy routing is applied in hardware for all interfaces regardless of which interface was configure for policy routing. |
HTTP requests subject to WCCP redirection are handled in software. HTTP replies from the server and the cache engine are handled in hardware.
NAT-required flows are handled in software without impacting non-NAT flow forwarding in hardware.
Unicast RPF check is supported by forwarding all incoming Layer 3 unicast traffic in software that is received on the RPF-configured interface.
IOS bridge-group ACLs are handled in 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:
These guidelines are for configurations where you need to have 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 then at the end of the list specify 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 only two different actions are specified: 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. The best merge results are obtained 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" and "Grouping Actions Together" sections and see Example 6.
If you need to specify the full-flow mode, but cannot follow the recommendations in the "Using the Implicit Deny Action" and "Grouping Actions Together" sections, follow this guideline: If the ACL has both IP ACEs and TCP/UDP/ICMP ACEs with Layer 4 information, put the Layer 4 ACEs at the end of the list; this gives priority to the filtering of traffic 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
The following 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.
These guidelines are 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 nine different operations on the same ACL. If this number is exceeded, 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 between the two is still 9 or less.
It is a good practice to 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.
In a wiring closet configuration, Catalyst 6000 family switches might not be equipped with MSFCs (routers). In this configuration, the switch can still support VACL and QoS ACL. Suppose Host X and Host Y are in different VLANs and 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.
For example, 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 preventing other ports from receiving the packet.
To redirect broadcast traffic to a specific server port, perform these steps (TCP port 5000 is the intended server application port):
Step 1 Redirect the broadcast packets:
Console>(enable) set security acl ip SERVER redirect 4/1 tcp any host 255.255.255.255 eq 5000
Step 2 Permit all other traffic:
Console>(enable) set security acl ip SERVER permit ip any any
Step 3 Commit the VACL:
Console>(enable) commit security acl SERVER
Step 4 Map the VACL to VLAN 10:
Console>(enable) set security acl map SERVER 10
You could apply the same concept to direct broadcast traffic to a multicast destination by redirecting the traffic to a group of ports (see Figure 7-5).
When DHCP requests are broadcast, they reach every DHCP server in the VLAN and multiple responses are sent back. With VACLs, you can restrict the response from a specific DHCP server and drop the other responses.
Step 1 Permit DHCP response from host 1.2.3.4:
Console>(enable) set security acl ip SERVER permit tcp host 1.2.3.4 any eq 68
Step 2 Deny DHCP responses from any other host:
Console>(enable) set security acl ip SERVER deny tcp any any eq 68
Step 3 Permit other IP traffic:
Console>(enable) set security acl ip SERVER permit any any
Step 4 Commit the VACL:
Console>(enable) commit security acl SERVER
Step 5 Map the VACL to VLAN 10:
Console>(enable) 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 achieve this, perform these steps:
Step 1 Deny traffic from hosts in subnet 10.1.2.0/8:
Console>(enable) 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:
Console>(enable) 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:
Console>(enable) set security acl ip SERVER deny ip host 10.1.1.8 host 10.1.1.100
Step 4 Permit other IP traffic:
Console>(enable) set security acl ip SERVER permit ip any any
Step 5 Commit the VACL:
Console>(enable) commit security acl SERVER
Step 6 Map the VACL to VLAN 10:
Console>(enable) set security acl map SERVER 10
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, read 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 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 any 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 171.3.8.2IPACL1 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 IPACL1 editbufferset security acl ip IPACL1-----------------------------------------------------------------1. permit 172.20.53.42. deny any any3. deny 171.3.8.2Console>(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 destination address "host." 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 show 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]] [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 show the contents of the edit buffer:
Console>(enable)show security acl info IPXACL1 editbufferset security acl ipx IPXACL1-----------------------------------------------------------------1. deny any 12342. deny any any3. 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 1.A.3.4 and insert this ACE before ACE number 2:
Console>(enable)set security acl ipx IPXACL1 permit any 1.A.3.4 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 1.A.3.43. deny any any4. redirect 3456 5. permit any anyConsole>(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] |
This example shows how to create an ACE for MACACL1 to block all traffic from 1-2-3-4-7-A:
Console>(enable)set security acl mac MACACL1 deny host 1-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 show the contents of the edit buffer:
Console>(enable)show security acl info MACACL1 editbufferset security acl mac MACACL1-----------------------------------------------------------------1. deny any 12342. permit any 1.A.3.43. deny any any4. redirect 3456 5. 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 ACEs or a specific ACE to NVRAM with the commit command. Any committed ACL with no ACEs will be deleted.
To commit an ACE to NVRAM, perform this task in privileged mode:
| Task | Command |
|---|---|
Commit an ACE to NVRAM. | commit security acl acl_name | all |
This example shows how to commit a specific security ACE 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 vlan |
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 show security acl info acl_name editbuffer |
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 B any3. deny c4. permit any 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 B any3. deny C4. deny D5. permit any 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 show security acl map vlan |
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 IPACL1IPACL1 editbuffer modifications cleared.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 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 allAll editbuffers modified. Use `commit' command to apply changes.Console>(enable)
This example shows how to clear the mapping for a specific VACL on a specific VLAN:
Console>(enable)clear security acl map IPACL1 50IPACL1 editbuffer modified. Use `commit' command to apply changes.Console>(enable)
You can display VACL management information with the show security acl resource-usage command.
To show VACL management information, perform this task in privileged mode:
| Task | Command |
|---|---|
Show VACL management information. | show security acl resource usage |
This example shows how to display VACL management information:
Console>(enable)show security acl resource-usageACL storage usage (mask/value) is: (40%/50%)Console (enable)
Posted: Tue Aug 15 07:17:29 PDT 2000
Copyright 1989-2000©Cisco Systems Inc.