Overview of Security Access Control Lists

An ACL consists of a series of statements called ACL entries that define the network traffic profile. Each entry permits or denies network traffic (inbound and outbound) from and to the parts of your network specified in the entry. Each entry also contains a filter element that is based on criteria such as the source address, the destination address, the protocol, and protocol-specific parameters such as ports and so on.

An implicit deny-all entry exists at the end of each ACL, so you must configure an ACL on each interface that you want to permit connections. Otherwise, the ACE denies all traffic on the interface.

ACLs allow you to control network connection setups rather than processing each packet. Such ACLs are commonly referred to as security ACLs.
You can configure ACLs as parts of other features (for example, security, Network Address Translation (NAT), server load balancing (SLB), and so on). The ACE merges these individual ACLs into one large ACL called a merged ACL. The ACL compiler then parses the merged ACL and generates the ACL lookup mechanisms. A match on this merged ACL can result in multiple actions.

Note:

You can apply only one extended ACL to each direction (inbound or outbound) of an interface. You can also apply the same ACL on multiple interfaces. You can apply EtherType ACLs only in the inbound direction and only on Layer 2 interfaces.

The ACE does not explicitly support standard ACLs. To configure a standard ACL, specify the destination address as any and do not specify ports in an extended ACL. For details about configuring an extended ACL, see the “Configuring an Extended ACL” section.

ACL Configuration Guidelines

This section describes the guidelines to observe when you configure and use ACLs in your network. It contains the following topics:

ACL Entry Order

ACL Implicit Deny

Maximum Number of ACL Entries

ACL Entry Order

An ACL consists of one or more entries. Depending on the ACL type, you can specify the source and destination addresses, the protocol, the ports (for TCP or UDP), the ICMP type, the ICMP code, or the EtherType as the match criteria. By default, the ACE appends each ACL entry at the end of the ACL. You can also indicate the location of each entry within an ACL by specifying a line number.

The order of the entries is important. When the ACE decides whether to accept or refuse a connection, the ACE tests the packet against each ACL entry in the order in which the entries are listed. After it finds a match, the ACE does not check any more entries. For example, if you create an entry at the beginning of an ACL that explicitly permits all traffic, the ACE does not check any other statements in the ACL.

Note:

If there is a deny statement for packets coming to the Control Plane (CP), then the ACE skips to the next ACL entry.

ACL Implicit Deny

All ACLs have an implicit deny entry at the end of the ACL, so, unless you explicitly permit it, traffic cannot pass. For example, if you want to allow all users to access a network through the ACE except for those users with particular IP addresses, then you must deny the particular IP addresses in one entry and permit all other IP addresses in another entry.

Maximum Number of ACL Entries

The ACE supports a maximum of 256,000 ACL entries. Some ACLs use more memory than others, such as an ACL that uses large port number ranges or overlapping networks (for example, one entry specifies 10.0.0.0/8 and another entry specifies 10.1.1.0/24). Depending on the type of ACL, the actual limit that the ACE can support may be less than 256,000 entries.

If you use object groups in ACL entries, you enter fewer actual ACL entries, but the same number of expanded ACL entries as you did when you entered entries without object groups. Expanded ACL entries count toward the system limit. To view the number of expanded ACL entries in an ACL, use the show access-list name command.

If you exceed the memory limitations of the ACE, it generates a syslog message and increments the Download Failures counter in the output of the show interface vlannumber command. The configuration remains in the running-config file and the interface stays enabled. The ACL entries stay the same as they were before the failing configuration was attempted.

For example, if you add a new ACL with ten entries, but the addition of the sixth entry fails because the ACE runs out of memory, the ACE removes the five entries that you successfully entered.

Note:

You must allocate sufficient ACL memory resources for each virtual context in the ACE. The ACE does not generate a syslog if you exceed the maximum number of ACL entries.

Configuring ACLs

You can configure ACLs in one of two ways:

Using the access-list command in configuration mode

Using the match access-list command in a Layer 3 and Layer 4 class map

You can permit or deny network connections based on the IP protocol, source and destination IP addresses, and TCP or UDP ports. To configure a non-ICMP extended ACL, enter the following command:

You can configure an ACL that controls traffic based on its EtherType. An EtherType is a subprotocol identifier. EtherType ACLs support Ethernet V2 frames; they do not do not support 802.3-formatted frames. To configure an Ethertype ACL, enter the following command:

access-listnameethertype {deny | permit} {any | bpdu | ipv6 | mpls}

Note:

You can configure an EtherType ACL on a Layer 2 interface in the inbound direction only. If you are operating the ACE in bridge mode, be sure to configure an ACL on all interfaces that permit BPDUs. Otherwise, a bridge loop may result.

For example, to configure an extended ACL to permit all IP traffic from any source IP address and that is destined to any IP address on interface VLAN 200, enter the following commands:

To minimize syslog message generation, the ACE uses the flow cache as follows:

For the first packet hit on an ACL entry, the ACE generates a syslog and caches the flow (5-tuple) in the connection table.

For subsequent hits on the same ACL entry, the ACE checks the cache. If it finds the flow in the cache, the ACE increments a hit counter for this entry in the cache and does not generate a syslog.

After some time (the default is 300 seconds, which is configurable in the ACL entry definition in the CLI as the interval_secs option), the ACE generates a syslog and sets the hit count to 0.

However, if at the expiry of the above time, the hit count is 0, the ACE deletes the cache entry silently. So by default, a cache entry is aged out 600 seconds after the last hit.

Troubleshooting ACLs

Many ACL issues manifest themselves by all traffic or only certain traffic being denied or permitted access to the ACE or out of the ACE. Remember that, initially, all traffic to the ACE is denied until you permit traffic using an ACL. Every ACL contains an implicit deny at the end of it, so only traffic that you explicitly permit will have access to the ACE. To troubleshoot ACLs, follow these steps:

1. Verify that your ACL configuration is correct for your network application. Make any required changes to the running-config file, and then test the configuration. If it is satisfactory, save it to the startup-config file using the copy runnning-config startup-config command.

For example, to display the ACLs that you have configured in your ACE, enter the following command:

3. Display the details of an individual ACL by using the show access-listacl_namedetail command. This command displays every entry in the specified ACL, the hit counts for each entry, and a 32-bit hexadecimal MD5-hash value that the ACE computes from the access-list command immediately when you configure an ACL. The ACE includes this hash value in deny syslog messages (106023) to help you identify the ACL entry that caused the deny syslog. For example to display the details of the ACL1 access control list, enter the following command:

%ACE-4-106023: Deny protocol number | name src incoming-interface:src-ip dst outgoing-interface:dst-ip by access-group "acl-name"
An IP packet was denied by the ACL.

Explanation: This message displays even if you do not have the log option enabled for an ACL. If a packet hits an input ACL, the outgoing interface will not be known. In this case, the ACE prints the outgoing interface as undetermined. The source IP and destination IP addresses are the unmapped and mapped addresses for the input and output ACLs, respectively, when used with NAT.

Recommended Action: If messages persist from the same source address, messages may indicate a foot-printing or port-scanning attempt. Contact the remote host administrators.

An ACL merged list is a large ACL that the CP compiles from multiple security ACL entries and policies. When the ACE executes an ACL merged list, it performs multiple actions on a flow that matches the merged list.

4. Display the actions that the ACE will perform on a flow by entering the show acl-merge merged-list command. For example, to display the merged list for VLAN 100, enter the following command: