What does ACL stand for in networking?

A commonly used tool at the Cisco command line is the access list (ACL). At their simplest, access lists are collections of IP addresses that are used by a router, switch or 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 will focus on IOS access lists as used on Cisco routers, although much of this discussion applies to Cisco switches as well. Firewalls also use access 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 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 is dropped.
  • Securing traffic flowing to a network device. A network device can use access lists 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 List Examples

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

  • Standard. A standard ACL creates a list of IP addresses or IP address ranges. Standard access lists are the simplest type of ACL.
  • Extended. As the name implies, an 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 talking to destination IP address 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 lists are similar to extended ACLs, but are used specifically for IPv6 addresses.
  • MAC access 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 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 lists

  • Name your access 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.
  • Remember that by itself, an access list accomplishes nothing. 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 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 ACEs. 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 “” means “anything in the 192.168.100.x network” using a normal subnet mask, this would be expressed as “” in an ACE using a wildcard mask instead.
  • Access lists 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 access lists must consider directionality. Depending on the application, access 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 access control entry of any access list 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 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.
  • Access lists 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 access 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 list processing is just one of many things the router does.

What are some examples of ACLs in action?

  1. Standard ACL used to control access to the router.</ br>
    This standard access 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
    ROUTER1#show run | section line vty
    line vty 0 4
     access-class MANAGEMENT-STATIONS in
     transport input all
    line vty 5 15
     access-class MANAGEMENT-STATIONS in
     transport input all
  2. Extended ACL used to filter traffic flowing through the router.</ br>
    This extended access 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 to remote host 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 any eq www
     permit tcp any eq ftp ftp-data
     permit tcp any eq 22
     deny ip any any log
    ROUTER1#show run | section interface FastEthernet1/0
    interface FastEthernet1/0
     ip address
     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 -> (8/0), 1 packet
    *May 18 14:39:41.703: %SEC-6-IPACCESSLOGP: list MATCH-THIS-TRAFFIC denied tcp ->, 1 packet