Overview

While the ACL fundamentals article covered the very basics of ACL's and the Cisco standard ACL, this article will focus on the extended IP access list, how it differs from the standard ACL and how both the standard and extended ACL's can be used to not only filter traffic but to also be used in a number of other Cisco IOS features.

Cisco Extended IP Access Lists

The previous article reviewed the standard ACL which provided the ability to filter traffic based solely on the source IP address. While this is generally useful, it is also very restrictive. The extended ACL provides the ability to match the source and destination IP address along with source and destination ports and different IP protocols. With all of these different options available, the available filtering/matching options are greatly increased.

The syntax of the extended ACL is shown below:

router(config)#access-list access-list-number {permit | deny} protocol {any | host host-source-ip-address | source-ip-address source-wildcard-mask} {any | host host-destination-ip-address | destination-ip-address destination-wildcard-mask} [eq port-number | gt port-number | lt port-number]

For extended ACLs, the access-list-number is set to a range from 100-199 or 2000-2699. There are a number of different protocols that can be configured including ip, tcp, and udp. With both tcp and udp a specific source and destination port number can be configured to make the matching possibilities even more specific. Along with all these possibilities also comes additional complexity. Keeping track of exactly which network is the source and which one is the destination can be confusing to those new into networking, and on top of this, the inverse mask is now required for both the source and destination.

Sometimes it is best to take these concepts off of the page and make an example out of it to make the concept really stick. Following this idea an example will be given. As shown in Figure 1, there are two groups of hosts on the left side of the diagram that need to be filtered. The first group includes a bank of lab computers that are used by the public at a retail location. The second group includes a bank of computers which are used by the retail employees which include their point-of-sale computers. On the right are a bank of servers which are intended to be used by only the retail employees and not the lab computers. Between these different locations is a single router and on this router an ACL must be configured which applies the rules laid. Figure 1 shows the graphical representation of this example.

Figure 1

For the purposes of this example, the ACL will be applied on the F0/0 interface, outbound.

Using this information, an ACL can be configured to match each of these different source and destination networks. These are shown here:

router(config)#access-list 100 permit ip 192.168.1.0 0.0.0.255 10.10.10.0 0.0.0.255

router(config)#access-list 100 deny ip 172.16.1.0 0.0.0.255 10.10.10.0 0.0.0.255

Now it is time to get into the interpretation of the ACL a little closer: As an ACL is being configured it is entered into a list in the order that it is configured. When traffic is being matched it is matched against the first entry. If there is no match then it is matched against the second entry, and so on. As soon as the traffic is matched to an action (permit/deny), the action is taken and the ACL is not referenced again. All ACL's (standard and extended) end with an implicit deny. What this means is that if traffic is not permitted within an ACL statement it will be automatically denied. If the statements shown above are entered there would be three total lines for the ACL, the two shown above and a third implicit deny. What this means effectively is that the second ACL entry really does not have to be entered as the implicit deny would cover it. In some cases this is the best solution and sometimes it is not; this all greatly depends on the specific situation. To apply this ACL the commands shown here would be used:

router(config)#interface f0/0

router(config-if)#ip access-group 100 out

Other ACL Uses

While the ACL was originally developed as a form of traffic filtering it has evolved over the past several years to be used in a number of different IOS features. These features typically have one thing in common: they each require traffic to be matched. For example, Network Address Translation (NAT) configuration uses an ACL to match the traffic that will be translated and Quality of Service (QoS) configuration can use an ACL to match the traffic that will be marked with a specific QoS marking. Along with these, there are several other features that take advantage of the matching capabilities of ACL's. The point of this is that even though ACLs for traffic filtering may not be implemented as much on production networks, the ACL itself is still a very relevant skill for any level of network engineer and because of this should be a skill that is well reviewed and researched.

Summary

The ACL has certainly evolved over the years and does extend beyond the boundaries of IP; there are ACL capabilities with Ethernet, Virtual LANs (VLAN), and IPv6 among others. As simple as they may be, they will probably be around for some time in one capacity or another.

If you're interested in learning more about Cisco, check out TrainSignal's Cisco Training Videos.