What is an Access Control List (ACL)?

A commonly used tool at the Cisco command line is the access control list (ACL). At their simplest, access control lists are collections of IP addresses that are used by a router, switch, or a firewall to identify network traffic that must be handled in a special way. Cisco and other network vendors use ACLs for many different purposes.

This article focuses on IOS access control lists as used on Cisco routers, although much of this discussion applies to Cisco switches as well. Firewalls also use access control lists, but in a more specific way than the many purposes, we’ll describe here.

ACLs are used in a few general ways:

• Securing traffic flowing through a network device. Access control lists are one of the tools a router or firewall uses to decide whether or not to forward traffic. If the ACL permits the flow, the traffic is forwarded; if not, the traffic’s dropped.
• Securing traffic flowing to a network device. A network device can use ACLs to determine if a particular IP address should be allowed to log into the management interface.
• Filtering routing updates. Sometimes,  you want a router to only advertise a subset of routes outbound to its neighbor, or to filter the routes coming inbound to a neighbor. ACLs can be used to define which routes should be treated normally and which should be filtered.
• To identify interesting traffic. Several different processes running on network devices need to know what traffic is interesting to them. For example, network address translation (NAT) needs to know which traffic should be translated from one IP to another. Custom routing (aka policy-based routing) needs to know which traffic should be forwarded according to the policy, and which can be forwarded via the standard routing table. Quality of service (QoS) policies use ACLs, to determine which traffic is subject to which QoS treatment. VPN tunnels use ACLs to know which traffic should be encrypted or decrypted.

This list is not exhaustive but lays a foundation for understanding how access lists are used.

Access Control List Examples

Different ACLs are used for different purposes. Let’s take a look at a few of the access control list types that Cisco defines for IOS:

• Standard ACL creates a list of IP addresses or IP address ranges. Standard access control lists are the simplest type of ACL.
• Extended ACL has more capability than a standard ACL. An extended ACL lists source and destination IP address pairs, and can even include what sort of traffic is flowing between the pairs. For example, an extended ACL could have an access control entry (ACE) identifying source IP address 10.100.200.3 talking to destination IP address 8.8.8.8 on port UDP 53. Extended ACLs offer fine control for traffic matching. Even more detailed matches are possible, such as matching on TCP flags or type-of-service values.
• IPv6 access control lists are similar to extended ACLs but are used specifically for IPv6 addresses.
• MAC access control lists allow the filtering of traffic using the Ethernet MAC address of the traffic instead of the IP address. MAC ACLs are rarely used in production networks but illustrate the power and flexibility available to network administrators.
• Prefix lists are typically used instead of standard ACLs when the goal is to filter routing updates. The syntax for prefix lists is less complicated than that of access control lists, particularly where route filtering is concerned.

There are several other kinds of access lists in the IOS world, including reflexive, lock and key, and MPLS. We don’t need to go through them all here. It’s enough, for now, to recognize that there are many different kinds of ACLs for different purposes. That said, the majority of Cisco IOS processes will use standard or extended ACLs, as well as prefix lists, to identify traffic.

Tips for implementing access control lists

• Name your access control list using all capital letters. Device configurations can be long and crowded with information. One way to make a custom ACL stand out is by naming it in all capital letters. This is a policy I follow for any custom item I create at the command line interface (CLI). At a glance, I can tell that a capitalized configuration object is something a human created, and not something included by default. This can be helpful when troubleshooting.
• An access list accomplishes nothing on its own. In other words, creating an ACL does not impact traffic in any way. An access list must be applied to something before it’s effective. I’ve seen some administrators scared to create an access control list, thinking it might impact traffic. I’ve seen others create the access list and think the job was done, even though it was never applied to any part of the router configuration. We’ll illustrate this situation in an example at the end of this blog post.
• Unused access lists should be cleaned up. There’s nothing more confusing when reviewing a router configuration than looking through an ACL, only to discover that it’s not used in the configuration. ACLs that are unused and won’t be used in the future should be deleted from the device configuration.
• Cisco uses wildcard masks in ACLs. Those familiar with IP addresses and subnet masks need to know that Cisco ACLs use wildcard masks, which are the bitwise inversion of a traditional subnet mask. For example, if “192.168.100.0 255.255.255.0” means “anything in the 192.168.100.x network” using a normal subnet mask, this would be expressed as “192.168.100.0 0.0.0.255” in an ACL using a wildcard mask instead.
• ALCs are processed in order, so order appropriately. Depending on your network hardware, this point is perhaps not a huge concern. Even so, knowing that access lists are processed in order from the top down is an important design consideration. Well-designed access lists will have the most frequently matched ACEs at the top, and lesser used ACEs towards the bottom.
• Some ACLs must consider directionality. Depending on the application, access control lists are applied in a specific direction. For example, an access list filtering traffic flowing through an interface will be applied either into or out of that interface. It’s easy to write the ACEs backwards if you aren’t paying attention to directionality.
• The last entry in any ACL denies all traffic, and might be invisible. All ACLs have an ACE at the very bottom that denies all traffic. You don’t have to write the ACE that does this; the access control list implicitly does it for you. This is critical to understand when implementing an access list. If the ACL you wrote does not explicitly permit traffic in the higher ACEs, then the implicit “deny everything” ACE at the bottom of the ACL will surely drop the traffic. This can be easy to forget, as the “deny any” is implied, and therefore won’t show up in the configuration.
• Logging can be useful. Cisco offers the ability to log an entry when a packet matches a specific ACE. This can be helpful when troubleshooting. This can also be helpful if you would like to know when traffic fell all the way through to the bottom of the ACL, and was consequently denied. To help log entries stand out or be more readily identified, Cisco allows ACEs to be tagged or have a hash value attached.
• ACLs can only get so big. ACLs reside in a very fast and expensive part of memory known as TCAM. The amount of TCAM available on any network device is limited. Therefore, if you’ll be writing several ACLs of several thousand lines each, it’s important to know whether or not the network device can handle it. Network device manufacturers include in their data sheets the number of access control entries the device supports. For example, the Cisco Catalyst C6880-X-LE supports 64K ACEs, while the C6880-X supports 256K.
• Router order of operations. An interesting side note about lists is that a Cisco router has a list of things it does when a packet arrives at an interface known as the order of operations. Access control list processing is just one of many things the router does.

What are some examples of ACLs in action?

Standard ACL used to control access to the router

This standard list allows a few specific hosts, plus the entire 192.168.100.x range to access the virtual terminal (VTY) lines on an IOS device. VTYs are used by Secure Shell (SSH), Telnet and some other remote means of administrating a router. The effect of this configuration is that only those IP addresses in the “MANAGEMENT-STATIONS” access list will be able to manage the device.

ROUTER1#show run | section access-list ip access-list standard MANAGEMENT-STATIONS  permit 10.100.201.56  permit 10.100.200.3  permit 10.100.200.9  permit 192.168.100.0 0.0.0.255 ROUTER1#show run | section line vty line vty 0 4  access-class MANAGEMENT-STATIONS in  login  transport input all line vty 5 15  access-class MANAGEMENT-STATIONS in  login  transport input all ROUTER1#

Extended ACL used to filter traffic flowing through the router

This extended access control list will match traffic sourced from the network 10.100.200.x going to any remote networks on ports 80 (www), 20 and 21 (ftp and ftp-data), and 22 (SSH/SCP). All other traffic will be denied and logged. To illustrate how the logging works, I’ll attempt to connect from host 10.100.200.100 to remote host 50.50.50.50 using both ping and Telnet. These will both be denied, and a log entry created.

ROUTER1#show run | section access-list extended ip access-list extended MATCH-THIS-TRAFFIC  permit tcp 10.100.200.0 0.0.0.255 any eq www  permit tcp 10.100.200.0 0.0.0.255 any eq ftp ftp-data  permit tcp 10.100.200.0 0.0.0.255 any eq 22  deny ip any any log ROUTER1#show run | section interface FastEthernet1/0 interface FastEthernet1/0  ip address 10.100.200.1 255.255.255.0  ip access-group MATCH-THIS-TRAFFIC in  duplex auto  speed auto ROUTER1#show logging | i IPACCESS *May 18 14:38:36.563: %SEC-6-IPACCESSLOGDP: list MATCH-THIS-TRAFFIC denied icmp 10.100.200.100 -> 50.50.50.50 (8/0), 1 packet *May 18 14:39:41.703: %SEC-6-IPACCESSLOGP: list MATCH-THIS-TRAFFIC denied tcp 10.100.200.100(49542) -> 50.50.50.50(23), 1 packet ROUTER1#