Access Control Lists (ACLs) – Part 5

Having discussed general ACL rules and syntax, let’s now turn to the differences between standard and extended ACLs. As you might recall, numbered ACLs fall into several ranges:

• 1 – 99: Standard IP


• 100 – 199: Extended IP


• 1300 - 1999: Standard IP (expanded range)


• 2000 - 2699: Extended IP (expanded range)


• Other ranges for other protocols

Originally, the ranges for standard and extended IP ACLs were 1-99 and 100-199, respectively, but now that ACLs are used for so many things, a hundred or so of each might not be enough. For this reason, the expanded ranges were introduced. There are now a total of 699 standard, and 700 extended numbered IP ACLs available.

So, aside from the different numerical ranges involved, what are the differences between a standard and an extended ACL? In addition to filtering by source address (which is all that a standard IP ACL can do), an extended IP ACL allows us to filter based on:

• Destination address


• Transport layer protocols


• Port numbers


• Other options

To see what this means, let’s look at an example of an extended IP ACL:

• access-list 101 permit tcp host 1.2.3.4 host 5.6.7.8 eq telnet

ACL 101 permits only Telnet traffic (TCP port 23) originating from source 1.2.3.4 and targeting host 5.6.7.8, and denies all other traffic (the implicit “deny any” also applies to extended ACLs). Note that the source address is given first (along with either the keyword “host” or a wildcard mask), followed by the destination address (also with either the keyword “host” or a WCM). You could also write ACL 101 using wildcard masks, like this:

• access-list 101 permit tcp 1.2.3.4 0.0.0.0 5.6.7.8 0.0.0.0 eq telnet

The two choices are functionally equivalent, but for most humans the WCM format is harder to read than that using keyword “host”, so I personally avoid the “0.0.0.0” WCM. Note that, unlike a standard ACL, when specifying an address in an extended ACL, either the keyword “host” or a wildcard mask must be used. Attempting to write ACL 101 like this would result in a syntax error:

• access-list 101 permit tcp 1.2.3.4 5.6.7.8 eq telnet

Here’s another example of a syntactically-correct extended IP ACL:

• access-list 102 deny udp 172.16.0.0 0.0.255.255 192.168.1.0 0.0.0.255 eq tftp


• access-list 102 permit ip any any

ACL 102 denies TFTP traffic (and only TFTP traffic) from any host on the 172.16.0.0 network going to any host on the 192.168.1.0 network, and permits everything else. Note that a “permit any” in an extended ACL must specify the protocol (“ip”, meaning anything in the IP suite), and both the source and destination addresses (“any any”).

By the way, in our extended ACLs we’ve been using keywords for the common port numbers (Telnet = 23, TFTP = 69, etc), but you can also use the port numbers, which means that ACL 102 could also be written like this:

• access-list 102 deny udp 172.16.0.0 0.0.255.255 192.168.1.0 0.0.0.255 eq 69


• access-list 102 permit ip any any

To get a list of the keywords for commonly-used ports, you can use the question mark, like this (note the space in between the WCM and the “?”):

• access-list 102 deny udp 172.16.0.0 0.0.255.255 192.168.1.0 0.0.0.255 eq ?

Also, in addition to “eq” (“equal-to”), you can also specify “gt” (“greater-than”), “lt” (“less-than”), and other options. You can also use the question mark to view these.

Let’s say that we want to permit traffic only to hosts on network 10.0.0.0, while denying everything else. Here’s a possible solution:

• access-list 103 permit ip any 10.0.0.0 0.255.255.255

ACL 103 applies to any protocol in the IP suite (due to the “ip” keyword), from any source (keyword “any”), going to any destination on the 10.0.0.0 network (note the WCM). Since no port or other option information was specified, the ACL applies to all ports and options.

Speaking of options, let’s look at a few of those. ICMP has many different options, one of them being “echo”, used by the “ping” application. Here’s an ACL that will specifically deny pings, while permitting all other traffic:

• access-list 104 remark This ACL stops pings


• access-list 104 deny icmp any any echo


• access-list 104 permit ip any any

If you really wanted to nail things down, you could deny not only pings (ICMP echoes), but also their replies (ICMP echo replies), like this:

• access-list 105 remark This ACL stops pings and replies


• access-list 105 deny icmp any any echo


• access-list 105 deny icmp any any echo-reply


• access-list 105 permit ip any any

As with standard IP ACLs, you can create named extended IP ACLs. For example, you could create a named ACL equivalent to ACL 105 like this:

• Router#conf t


• Router(config)#ip access-list ext stop_ping


• Router(config-ext-nacl)#This ACL stops pings and replies


• Router(config-ext-nacl)#deny icmp any any echo


• Router(config-ext-nacl)#deny icmp any any echo-reply


• Router(config-ext-nacl)#permit ip any any

Finally, you put an extended IP ACL in service the same way you do a standard IP ACL. For example, to put ACL 105 in effect outbound on the GigEthernet2/1 interface, you would do:

• Router#conf t


• Router(config)#int g2/1


• Router(config-if)#ip access-group 105 out

Likewise, to place ACL “stop_ping” in force inbound on the Serial 1/2 interface:

• Router#conf t


• Router(config)#int s1/2


• Router(config-if)#ip access-group stop_ping in

Remember, ACL names are case-sensitive, and the underscore is not the same as the dash (hyphen). You need to place an ACL in service using exactly the same name as that used to create it.

Author: Al Friebe