Chapter 17. Advanced IPv4 Access Control Lists
This chapter covers the following exam topics:
4.0 Infrastructure Services
4.4 Configure, verify, and troubleshoot IPv4 and IPv6 access list for traffic filtering
4.1.a Standard
4.1.b Extended
4.1.c Named
IPv4 ACLs are either standard or extended ACLs, with standard ACLs matching only the source IP address, and extended matching a variety of packet header fields. At the same time, IP ACLs are either numbered or named. Figure 17-1 shows the categories, and the main features of each, as introduced in the previous chapter.
This chapter discusses the other three categories of ACLs beyond standard numbered IP ACLs, and ends with a few miscellaneous features to secure Cisco routers and switches. Note that this chapter’s technical content is identical to the ICND1 100-105 Cert Guide’s Chapter 26; use that fact to speed your reading now if you have already read that chapter.
“Do I Know This Already?” Quiz
Take the quiz (either here, or use the PCPT software) if you want to use the score to help you decide how much time to spend on this chapter. The answers are at the bottom of the page following the quiz, and the explanations are in DVD Appendix C and in the PCPT software.
1. Which of the following fields cannot be compared based on an extended IP ACL? (Choose two answers.)
a. Protocol
b. Source IP address
c. Destination IP address
d. TOS byte
e. URL
f. Filename for FTP transfers
2. Which of the following access-list commands permit packets going from host 10.1.1.1 to all web servers whose IP addresses begin with 172.16.5? (Choose two answers.)
a. access-list 101 permit tcp host 10.1.1.1 172.16.5.0 0.0.0.255 eq www
b. access-list 1951 permit ip host 10.1.1.1 172.16.5.0 0.0.0.255 eq www
c. access-list 2523 permit ip host 10.1.1.1 eq www 172.16.5.0 0.0.0.255
d. access-list 2523 permit tcp host 10.1.1.1 eq www 172.16.5.0 0.0.0.255
e. access-list 2523 permit tcp host 10.1.1.1 172.16.5.0 0.0.0.255 eq www
3. Which of the following access-list commands permits packets going to any web client from all web servers whose IP addresses begin with 172.16.5?
a. access-list 101 permit tcp host 10.1.1.1 172.16.5.0 0.0.0.255 eq www
b. access-list 1951 permit ip host 10.1.1.1 172.16.5.0 0.0.0.255 eq www
c. access-list 2523 permit tcp any eq www 172.16.5.0 0.0.0.255
d. access-list 2523 permit tcp 172.16.5.0 0.0.0.255 eq www 172.16.5.0 0.0.0.255
e. access-list 2523 permit tcp 172.16.5.0 0.0.0.255 eq www any
4. In a router running a recent IOS version (at least version 15.0), an engineer needs to delete the second line in ACL 101, which currently has four commands configured. Which of the following options could be used? (Choose two answers.)
a. Delete the entire ACL and reconfigure the three ACL statements that should remain in the ACL.
b. Delete one line from the ACL using the no access-list... global command.
c. Delete one line from the ACL by entering ACL configuration mode for the ACL and then deleting only the second line based on its sequence number.
d. Delete the last three lines from the ACL from global configuration mode, and then add the last two statements back into the ACL.
5. An engineer is considering configuring an ACL on Router R1. The engineer could use ACL A, which would be enabled with the ip access-group A out command on interface G0/1, or ACL B, which would be enabled with the ip access-group B in command on that same interface. R1’s G0/1 interface uses IPv4 address 1.1.1.1. Which of the answers are true when comparing these options? (Choose two answers.)
a. ACL A creates more risk of filtering important overhead traffic than ACL B.
b. ACL B creates more risk of filtering important overhead traffic than ACL A.
c. A ping 1.1.1.1 command on R1 would bypass ACL A even if enabled.
d. A ping 1.1.1.1 command on R1 would bypass ACL B even if enabled.
6. An engineer configures an ACL but forgets to save the configuration. At that point, which of the following commands display the configuration of an IPv4 ACL, including line numbers? (Choose two answers.)
a. show running-config
b. show startup-config
c. show ip access-lists
d. show access-lists
Answers to the “Do I Know This Already?” quiz:
1 E, F 2 A, E 3 E 4 A, C 5 B, C 6 C, D
Foundation Topics
Extended Numbered IP Access Control Lists
Extended IP access lists have many similarities compared to the standard numbered IP ACLs discussed in the previous chapter. Just like standard IP ACLs, you enable extended access lists on interfaces for packets either entering or exiting the interface. IOS searches the list sequentially. Extended ACLs also use first-match logic, because the router stops the search through the list as soon as the first statement is matched, taking the action defined in the first-matched statement. All these features are also true of standard numbered access lists (and named ACLs).
Extended ACLs differ from standard ACLs mostly because of the larger variety of packet header fields that can be used to match a packet. One extended ACL statement can examine multiple parts of the packet headers, requiring that all the parameters be matched correctly to match that one ACL statement. That powerful matching logic makes extended access lists both more useful and more complex than standard IP ACLs.
Matching the Protocol, Source IP, and Destination IP
Like standard numbered IP ACLs, extended numbered IP ACLs also use the access-list global command. The syntax is identical, at least up through the permit or deny keyword. At that point, the command lists matching parameters, and those differ, of course. In particular, the extended ACL access-list command requires three matching parameters: the IP protocol type, the source IP address, and the destination IP address.
The IP header’s Protocol field identifies the header that follows the IP header. Figure 17-2 shows the location of the IP Protocol field, the concept of it pointing to the type of header that follows, along with some details of the IP header for reference.
IOS requires that you configure parameters for the three highlighted parts of Figure 17-2. For the protocol type, you simply use a keyword, such as tcp, udp, or icmp, matching IP packets that happen to have a TCP, UDP, or ICMP header, respectively, following the IP header. Or you can use the keyword ip, which means “all IPv4 packets.” You also must configure some values for the source and destination IP address fields that follow; these fields use the same syntax and options for matching the IP addresses as discussed in Chapter 16, “Basic IPv4 Access Control Lists.” Figure 17-3 shows the syntax.
Note
When matching IP addresses in the source and destination fields, there is one difference with standard ACLs: When matching a specific IP address, the extended ACL requires the use of the host keyword. You cannot simply list the IP address alone.
Table 17-2 lists several sample access-list commands that use only the required matching parameters. Feel free to cover the right side and use the table for an exercise, or just review the explanations to get an idea for the logic in some sample commands.
The last entry in Table 17-2 helps make an important point about how IOS processes extended ACLs:
In an extended ACL access-list command, all the matching parameters must match the packet for the packet to match the command.
For example, in that last example from Table 17-2, the command checks for UDP, a source IP address from subnet 1.1.1.0/24, and any destination IP address. If a packet with source IP address 1.1.1.1 were examined, it would match the source IP address check, but if it had a TCP header instead of UDP, it would not match this access-list command. All parameters must match.
Matching TCP and UDP Port Numbers
Extended ACLs can also examine parts of the TCP and UDP headers, particularly the source and destination port number fields. The port numbers identify the application that sends or receives the data.
The most useful ports to check are the well-known ports used by servers. For example, web servers use well-known port 80 by default. Figure 17-4 shows the location of the port numbers in the TCP header, following the IP header.
When an extended ACL command includes either the tcp or udp keyword, that command can optionally reference the source and/or destination port. To make these comparisons, the syntax uses keywords for equal, not equal, less than, greater than, and for a range of port numbers. In addition, the command can use either the literal decimal port numbers, or more convenient keywords for some well-known application ports. Figure 17-5 shows the positions of the source and destination port fields in the access-list command and these port number keywords.
For example, consider the simple network shown in Figure 17-6. The FTP server sits on the right, with the client on the left. The figure shows the syntax of an ACL that matches the following:
Packets that include a TCP header
Packets sent from the client subnet
Packets sent to the server subnet
Packets with TCP destination port 21 (FTP server control port)
To fully appreciate the matching of the destination port with the eq 21 parameters, consider packets moving from left to right, from PC1 to the server. Assuming the server uses well-known port 21 (FTP control port), the packet’s TCP header has a destination port value of 21. The ACL syntax includes the eq 21 parameters after the destination IP address. The position after the destination address parameters is important: That position identifies the fact that the eq 21 parameters should be compared to the packet’s destination port. As a result, the ACL statement shown in Figure 17-6 would match this packet, and the destination port of 21, if used in any of the four locations implied by the four dashed arrowed lines in the figure.
Conversely, Figure 17-7 shows the reverse flow, with a packet sent by the server back toward PC1. In this case, the packet’s TCP header has a source port of 21, so the ACL must check the source port value of 21, and the ACL must be located on different interfaces. In this case, the eq 21 parameters follow the source address field, but come before the destination address field.
When examining ACLs that match port numbers, first consider the location and direction in which the ACL will be applied. That direction determines whether the packet is being sent to the server, or from the server. At that point, you can decide whether you need to check the source or destination port in the packet. For reference, Table 17-3 lists many of the popular port numbers and their transport layer protocols and applications. Note that the syntax of the access-list commands accepts both the port numbers and a shorthand version of the application name.
Table 17-4 lists several example access-list commands that match based on port numbers. Cover the right side of the table, and try to characterize the packets matched by each command. Then, check the right side of the table to see if you agree with the assessment.
Extended IP ACL Configuration
Because extended ACLs can match so many different fields in the various headers in an IP packet, the command syntax cannot be easily summarized in a single generic command. However, the two commands in Table 17-5 summarize the syntax options as covered in this book.
The configuration process for extended ACLs mostly matches the same process used for standard ACLs. You must choose the location and direction in which to enable the ACL, particularly the direction, so that you can characterize whether certain addresses and ports will be either the source or destination. Configure the ACL using access-list commands, and when complete, then enable the ACL using the same ip access-group command used with standard ACLs. All these steps mirror what you do with standard ACLs; however, when configuring, keep the following differences in mind:
Place extended ACLs as close as possible to the source of the packets that will be filtered. Filtering close to the source of the packets saves some bandwidth.
Remember that all fields in one access-list command must match a packet for the packet to be considered to match that access-list statement.
Use numbers of 100–199 and 2000–2699 on the access-list commands; no one number is inherently better than another.
Extended IP Access Lists: Example 1
This example focuses on understanding basic syntax. In this case, the ACL denies Bob access to all FTP servers on R1’s Ethernet, and it denies Larry access to server1’s web server. Figure 17-8 shows the network topology; Example 17-1 shows the configuration on R1.
Example 17-1 R1’s Extended Access List: Example 1
interface Serial0
ip address 172.16.12.1 255.255.255.0
ip access-group 101 in
!
interface Serial1
ip address 172.16.13.1 255.255.255.0
ip access-group 101 in
!
access-list 101 remark Stop Bob to FTP servers, and Larry to Server1 web
access-list 101 deny tcp host 172.16.3.10 172.16.1.0 0.0.0.255 eq ftp
access-list 101 deny tcp host 172.16.2.10 host 172.16.1.100 eq www
access-list 101 permit ip any any
The first ACL statement prevents Bob’s access to FTP servers in subnet 172.16.1.0. The second statement prevents Larry’s access to web services on Server1. The final statement permits all other traffic.
Focusing on the syntax for a moment, there are several new items to review. First, the access-list number for extended access lists falls in the range of 100 to 199 or 2000 to 2699. Following the permit or deny action, the protocol parameter defines whether you want to check for all IP packets or specific headers, such as TCP or UDP headers. When you check for TCP or UDP port numbers, you must specify the TCP or UDP protocol. Both FTP and the web use TCP.
This example uses the eq parameter, meaning “equals,” to check the destination port numbers for FTP control (keyword ftp) and HTTP traffic (keyword www). You can use the numeric values—or, for the more popular options, a more obvious text version is valid. (If you were to type eq 80, the config would show eq www.)
This example enables the ACL in two places on R1: inbound on each serial interface. These locations achieve the goal of the ACL. However, that initial placement was made to make the point that Cisco suggests that you locate them as close as possible to the source of the packet. Therefore, Example 17-2 achieves the same goal as Example 17-1 of stopping Bob’s access to FTP servers at the main site, and it does so with an ACL on R3.
Example 17-2 R3’s Extended Access List Stopping Bob from Reaching FTP Servers Near R1
interface Ethernet0
ip address 172.16.3.1 255.255.255.0
ip access-group 103 in
access-list 103 remark deny Bob to FTP servers in subnet 172.16.1.0/24
access-list 103 deny tcp host 172.16.3.10 172.16.1.0 0.0.0.255 eq ftp
access-list 103 permit ip any any
The new configuration on R3 meets the goals to filter Bob’s traffic, while also meeting the overarching design goal of keeping the ACL close to the source of the packets. ACL 103 on R3 looks a lot like ACL 101 on R1 from Example 17-1, but this time, the ACL does not bother to check for the criteria to match Larry’s traffic, because Larry’s traffic will never enter R3’s Ethernet 0 interface. ACL 103 filters Bob’s FTP traffic to destinations in subnet 172.16.1.0/24, with all other traffic entering R3’s E0 interface making it into the network.
Extended IP Access Lists: Example 2
Example 17-3, based on the network shown in Figure 17-9, shows another example of how to use extended IP access lists. This example uses the following criteria:
Sam is not allowed access to the subnet of Bugs or Daffy.
Hosts on the Seville Ethernet are not allowed access to hosts on the Yosemite Ethernet.
All other combinations are allowed.
Example 17-3 Yosemite Configuration for Extended Access List Example
interface ethernet 0
ip access-group 110 in
!
access-list 110 deny ip host 10.1.2.1 10.1.1.0 0.0.0.255
access-list 110 deny ip 10.1.2.0 0.0.0.255 10.1.3.0 0.0.0.255
access-list 110 permit ip any any
This configuration solves the problem with few statements while keeping to the Cisco design guideline of placing extended ACLs as close as possible to the source of the traffic. The ACL filters packets that enter Yosemite’s E0 interface, which is the first router interface that packets sent by Sam enter. If the route between Yosemite and the other subnets changes over time, the ACL still applies. Also, the filtering mandated by the second requirement (to disallow Seville’s LAN hosts from accessing Yosemite’s) is met by the second access-list statement. Stopping packet flow from Yosemite’s LAN subnet to Seville’s LAN subnet stops effective communication between the two subnets. Alternatively, the opposite logic could have been configured at Seville.
Practice Building access-list Commands
Table 17-6 supplies a practice exercise to help you get comfortable with the syntax of the extended access-list command, particularly with choosing the correct matching logic. Your job: create a one-line extended ACL that matches the packets. The answers are in the section “Answers to Earlier Practice Problems,” later in this chapter. Note that if the criteria mentions a particular application protocol, for example, “web client,” that means to specifically match for that application protocol.
Named ACLs and ACL Editing
Now that you have a good understanding of the core concepts in IOS IP ACLs, this section examines a few enhancements to IOS support for ACLs: named ACLs and ACL editing with sequence numbers. Although both features are useful and important, neither adds any function as to what a router can and cannot filter. Instead, named ACLs and ACL sequence numbers make it easier to remember ACL names and edit existing ACLs when an ACL needs to change.
Named IP Access Lists
Named IP ACLs have many similarities with numbered IP ACLs. They can be used for filtering packets, plus for many other purposes. They can match the same fields as well: Standard numbered ACLs can match the same fields as a standard named ACL, and extended numbered ACLs can match the same fields as an extended named ACL.
Of course, there are differences between named and numbered ACLs. Named ACLs originally had three big differences compared to numbered ACLs:
Using names instead of numbers to identify the ACL, making it easier to remember the reason for the ACL
Using ACL subcommands, not global commands, to define the action and matching parameters
Using ACL editing features that allow the CLI user to delete individual lines from the ACL and insert new lines
You can easily learn named ACL configuration by just converting numbered ACLs to use the equivalent named ACL configuration. Figure 17-10 shows just such a conversion, using a simple three-line standard ACL number 1. To create the three permit subcommands for the named ACL, you literally copy parts of the three numbered ACL commands, beginning with the permit keyword.
The only truly new part of the named ACL configuration is the ip access-list global configuration command. This command defines whether an ACL is a standard or extended ACL, and defines the name. It also moves the user to ACL configuration mode, as shown in upcoming Example 17-4. Once in ACL configuration mode, you configure permit, deny, and remark commands that mirror the syntax of numbered ACL access-list commands. If you’re configuring a standard named ACL, these commands match the syntax of standard numbered ACLs; if you’re configuring extended named ACLs, they match the syntax of extended numbered ACLs.
Example 17-4 shows the configuration of a named extended ACL. Pay particular attention to the configuration mode prompts, which show ACL configuration mode.
Example 17-4 Named Access List Configuration
Router# configure terminal
Enter configuration commands, one per line. End with Ctrl-Z.
Router(config)# ip access-list extended barney
Router(config-ext-nacl)# permit tcp host 10.1.1.2 eq www any
Router(config-ext-nacl)# deny udp host 10.1.1.1 10.1.2.0 0.0.0.255
Router(config-ext-nacl)# deny ip 10.1.3.0 0.0.0.255 10.1.2.0 0.0.0.255
Router(config-ext-nacl)# deny ip 10.1.2.0 0.0.0.255 10.2.3.0 0.0.0.255
Router(config-ext-nacl)# permit ip any any
Router(config-ext-nacl)# interface serial1
Router(config-if)# ip access-group barney out
Router(config-if)# ^Z
Router# show running-config
Building configuration...
Current configuration:
! lines omitted for brevity
interface serial 1
ip access-group barney out
!
ip access-list extended barney
permit tcp host 10.1.1.2 eq www any
deny udp host 10.1.1.1 10.1.2.0 0.0.0.255
deny ip 10.1.3.0 0.0.0.255 10.1.2.0 0.0.0.255
deny ip 10.1.2.0 0.0.0.255 10.2.3.0 0.0.0.255
permit ip any any
Example 17-4 begins with the creation of an ACL named barney. The ip access-list extended barney command creates the ACL, naming it barney and placing the user in ACL configuration mode. This command also tells the IOS that barney is an extended ACL. Next, five different permit and deny statements define the matching logic and action to be taken upon a match. The show running-config command output lists the named ACL configuration before the single entry is deleted.
Named ACLs allow the user to delete and add new lines to the ACL from within ACL configuration mode. Example 17-5 shows how, with the no deny ip . . . command deleting a single entry from the ACL. Notice that the output of the show access-list command at the end of the example still lists the ACL, with four permit and deny commands instead of five.
Example 17-5 Removing One Command from a Named ACL
Router# configure terminal
Enter configuration commands, one per line. End with Ctrl-Z.
Router(config)# ip access-list extended barney
Router(config-ext-nacl)# no deny ip 10.1.2.0 0.0.0.255 10.2.3.0 0.0.0.255
Router(config-ext-nacl)# ^Z
Router# show access-list
Extended IP access list barney
10 permit tcp host 10.1.1.2 eq www any
20 deny udp host 10.1.1.1 10.1.2.0 0.0.0.255
30 deny ip 10.1.3.0 0.0.0.255 10.1.2.0 0.0.0.255
50 permit ip any any
Editing ACLs Using Sequence Numbers
Numbered ACLs have existed in IOS since the early days of Cisco routers and IOS; however, for many years, through many IOS versions, the ability to edit a numbered IP ACL was poor. For example, to simply delete a line from the ACL, the user had to delete the entire ACL and then reconfigure it.
The ACL editing feature uses an ACL sequence number that is added to each ACL permit or deny statement, with the numbers representing the sequence of statements in the ACL. ACL sequence numbers provide the following features for both numbered and named ACLs:
New configuration style for numbered: Numbered ACLs use a configuration style like named ACLs, as well as the traditional style, for the same ACL; the new style is required to perform advanced ACL editing.
Deleting single lines: An individual ACL permit or deny statement can be deleted with a no sequence-number subcommand.
Inserting new lines: Newly added permit and deny commands can be configured with a sequence number before the deny or permit command, dictating the location of the statement within the ACL.
Automatic sequence numbering: IOS adds sequence numbers to commands as you configure them, even if you do not include the sequence numbers.
To take advantage of the ability to delete and insert lines in an ACL, both numbered and named ACLs must use the same overall configuration style and commands used for named ACLs. The only difference in syntax is whether a name or number is used. Example 17-6 shows the configuration of a standard numbered IP ACL, using this alternative configuration style. The example shows the power of the ACL sequence number for editing. In this example, the following occurs:
Step 1. Numbered ACL 24 is configured using this new-style configuration, with three permit commands.
Step 2. The show ip access-lists command shows the three permit commands with sequence numbers 10, 20, and 30.
Step 3. The engineer deletes only the second permit command using the no 20 ACL subcommand, which simply refers to sequence number 20.
Step 4. The show ip access-lists command confirms that the ACL now has only two lines (sequence numbers 10 and 30).
Step 5. The engineer adds a new deny command to the beginning of the ACL, using the 5 deny 10.1.1.1 ACL subcommand.
Step 6. The show ip access-lists command again confirms the changes, this time listing three commands, sequence numbers 5, 10, and 30.
Note
For this example, note that the user does not leave configuration mode, instead using the do command to tell IOS to issue the show ip access-lists EXEC command from configuration mode.
Example 17-6 Editing ACLs Using Sequence Numbers
! Step 1: The 3-line Standard Numbered IP ACL is configured.
R1# configure terminal
Enter configuration commands, one per line. End with Ctrl-Z.
R1(config)# ip access-list standard 24
R1(config-std-nacl)# permit 10.1.1.0 0.0.0.255
R1(config-std-nacl)# permit 10.1.2.0 0.0.0.255
R1(config-std-nacl)# permit 10.1.3.0 0.0.0.255
! Step 2: Displaying the ACL's contents, without leaving configuration mode.
R1(config-std-nacl)# do show ip access-lists 24
Standard IP access list 24
10 permit 10.1.1.0, wildcard bits 0.0.0.255
20 permit 10.1.2.0, wildcard bits 0.0.0.255
30 permit 10.1.3.0, wildcard bits 0.0.0.255
! Step 3: Still in ACL 24 configuration mode, the line with sequence number 20 is
deleted.
R1(config-std-nacl)# no 20
! Step 4: Displaying the ACL's contents again, without leaving configuration mode.
! Note that line number 20 is no longer listed.
R1(config-std-nacl)#do show ip access-lists 24
Standard IP access list 24
10 permit 10.1.1.0, wildcard bits 0.0.0.255
30 permit 10.1.3.0, wildcard bits 0.0.0.255
! Step 5: Inserting a new first line in the ACL.
R1(config-std-nacl)# 5 deny 10.1.1.1
! Step 6: Displaying the ACL's contents one last time, with the new statement
!(sequence number 5) listed first.
R1(config-std-nacl)# do show ip access-lists 24
Standard IP access list 24
5 deny 10.1.1.1
10 permit 10.1.1.0, wildcard bits 0.0.0.255
30 permit 10.1.3.0, wildcard bits 0.0.0.255
Note that although Example 17-6 uses a numbered ACL, named ACLs use the same process to edit (add and remove) entries.
Numbered ACL Configuration Versus Named ACL Configuration
As a brief aside about numbered ACLs, note that IOS actually allows two ways to configure numbered ACLs in the more recent versions of IOS. First, IOS supports the traditional method, using the access-list global commands shown earlier in Examples 17-1, 17-2, and 17-3. IOS also supports the numbered ACL configuration with commands just like named ACLs, as shown in Example 17-6.
Oddly, IOS always stores numbered ACLs with the original style of configuration, as global access-list commands, no matter which method is used to configure the ACL. Example 17-7 demonstrates these facts, picking up where Example 17-6 ended, with the following additional steps:
Step 7. The engineer lists the configuration (show running-config), which lists the old-style configuration commands—even though the ACL was created with the new-style commands.
Step 8. The engineer adds a new statement to the end of the ACL using the old-style access-list 24 permit 10.1.4.0 0.0.0.255 global configuration command.
Step 9. The show ip access-lists command confirms that the old-style access-list command from the previous step followed the rule of being added only to the end of the ACL.
Step 10. The engineer displays the configuration to confirm that the parts of ACL 24 configured with both new-style commands and old-style commands are all listed in the same old-style ACL (show running-config).
Example 17-7 Adding to and Displaying a Numbered ACL Configuration
! Step 7: A configuration snippet for ACL 24.
R1# show running-config
! The only lines shown are the lines from ACL 24
access-list 24 deny 10.1.1.1
access-list 24 permit 10.1.1.0 0.0.0.255
access-list 24 permit 10.1.3.0 0.0.0.255
! Step 8: Adding a new access-list 24 global command
R1# configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
R1(config)# access-list 24 permit 10.1.4.0 0.0.0.255
R1(config)# ^Z
! Step 9: Displaying the ACL's contents again, with sequence numbers. Note that even
! the new statement has been automatically assigned a sequence number.
R1# show ip access-lists 24
Standard IP access list 24
5 deny 10.1.1.1
10 permit 10.1.1.0, wildcard bits 0.0.0.255
30 permit 10.1.3.0, wildcard bits 0.0.0.255
40 permit 10.1.4.0, wildcard bits 0.0.0.255
! Step 10: The numbered ACL configuration remains in old-style configuration commands.
R1# show running-config
! The only lines shown are the lines from ACL 24
access-list 24 deny 10.1.1.1
access-list 24 permit 10.1.1.0 0.0.0.255
access-list 24 permit 10.1.3.0 0.0.0.255
access-list 24 permit 10.1.4.0 0.0.0.255
ACL Implementation Considerations
ACLs can be a great tool to enhance the security of a network, but engineers should think about some broader issues before simply configuring an ACL to fix a problem. To help, Cisco makes the following general recommendations in the courses on which the CCNA R&S exams are based:
Place extended ACLs as close as possible to the source of the packet. This strategy allows ACLs to discard the packets early.
Place standard ACLs as close as possible to the destination of the packet. This strategy avoids the mistake with standard ACLs (which match the source IPv4 address only) of unintentionally discarding packets that did not need to be discarded.
Place more specific statements early in the ACL.
Disable an ACL from its interface (using the no ip access-group interface subcommand) before making changes to the ACL.
The first point deals with the concept of where to locate your ACLs. If you intend to filter a packet, filtering closer to the packet’s source means that the packet takes up less bandwidth in the network, which seems to be more efficient—and it is. Therefore, Cisco suggests locating extended ACLs as close to the source as possible.
However, the second point seems to contradict the first point, at least for standard ACLs, to locate them close to the destination. Why? Well, because standard ACLs look only at the source IP address, they tend to filter more than you want filtered when placed close to the source. For example, imagine that Fred and Barney are separated by four routers. If you filter Barney’s traffic sent to Fred on the first router, Barney can’t reach any hosts near the other three routers. So, the Cisco courses make a blanket recommendation to locate standard ACLs closer to the destination to avoid filtering traffic you do not mean to filter.
For the third item in the list, by placing more specific matching parameters early in each list, you are less likely to make mistakes in the ACL. For example, imagine that the ACL first listed a command that permitted traffic going to 10.1.1.0/24, and the second command denied traffic going to host 10.1.1.1. Packets sent to host 10.1.1.1 would match the first command, and never match the more specific second command. Note that later IOS versions prevent this mistake during configuration in some cases, as shown later in this chapter in Example 17-11.
Finally, Cisco recommends that you disable the ACLs on the interfaces before you change the statements in the list. By doing so, you avoid issues with the ACL during an interim state. First, if you delete an entire ACL, and leave the IP ACL enabled on an interface with the ip access-group command, IOS does not filter any packets (that was not always the case in far earlier IOS versions)! As soon as you add one ACL command to that enabled ACL, however, IOS starts filtering packets based on that ACL. Those interim ACL configurations could cause problems.
For example, suppose you have ACL 101 enabled on S0/0/0 for output packets. You delete list 101 so that all packets are allowed through. Then, you enter a single access-list 101 command. As soon as you press Enter, the list exists, and the router filters all packets exiting S0/0/0 based on the one-line list. If you want to enter a long ACL, you might temporarily filter packets you don’t want to filter! Therefore, the better way is to disable the list from the interface, make the changes to the list, and then reenable it on the interface.
Troubleshooting with IPv4 ACLs
The use of IPv4 ACLs makes troubleshooting IPv4 routing more difficult. Any data plane troubleshooting process can include a catchall phrase to include checking for ACLs. A network can have all hosts working, DHCP settings correct, all LANs working, all router interfaces working, and all routers having learned all routes to all subnets—and ACLs can still filter packets. Although ACLs provide that important service of filtering some packets, ACLs can make the troubleshooting process that much more difficult.
This third of the three major sections of this chapter focuses on troubleshooting in the presence of IPv4 ACLs. It breaks the discussion into two parts. The first part gives advice about common problems you might see on the exam, and how to find those with show commands and some analysis. The second part then looks at how ACLs impact the ping command.
Analyzing ACL Behavior in a Network
ACLs cause some of the biggest challenges when troubleshooting problems in real networking jobs. The packets created by commands like ping and traceroute do not exactly match the fields in packets created by end users. The ACLs sometimes filter the ping and traceroute traffic, making the network engineer think some other kind of problems exists when no problems exist at all. Or, the problem with the end-user traffic really is caused by the ACL, but the ping and traceroute traffic works fine, because the ACL matches the end-user traffic with a deny action but matches the ping and traceroute traffic with a permit action.
As a result, much of ACL troubleshooting requires thinking about ACL configuration versus the packets that flow in a network, rather than using a couple of IOS commands that identify the root cause of the problem. The show commands that help are those that give you the configuration of the ACL, and on what interfaces the ACL is enabled. You can also see statistics about which ACL statements have been matched. And using pings and traceroutes can help—as long as you remember that ACLs may apply different actions to those packets versus the end-user traffic.
The following phrases the ACL troubleshooting steps into a list for easier study. The list also expands on the idea of analyzing each ACL in Step 3. None of the ideas in the list are new compared to this chapter and the previous chapter, but it acts more as a summary of the common issues:
Step 1. Determine on which interfaces ACLs are enabled, and in which direction (show running-config, show ip interfaces).
Step 2. Find the configuration of each ACL (show access-lists, show ip access-lists, show running-config).
Step 3. Analyze the ACLs to predict which packets should match the ACL, focusing on the following points:
A. Misordered ACLs: Look for misordered ACL statements. IOS uses first-match logic when searching an ACL.
B. Reversed source/destination addresses: Analyze the router interface, the direction in which the ACL is enabled, compared to the location of the IP address ranges matched by the ACL statements. Make sure the source IP address field could match packets with that source IP address, rather than the destination, and vice versa for the destination IP address field.
C. Reversed source/destination ports: For extended ACLs that reference UDP or TCP port numbers, continue to analyze the location and direction of the ACL versus the hosts, focusing on which host acts as the server using a well-known port. Ensure that the ACL statement matches the correct source or destination port depending on whether the server sent or will receive the packet.
D. Syntax: Remember that extended ACL commands must use the tcp and udp keywords if the command needs to check the port numbers.
E. Syntax: Note that ICMP packets do not use UDP or TCP; ICMP is considered to be another protocol matchable with the icmp keyword (instead of tcp or udp).
F. Explicit deny any: Instead of using the implicit deny any at the end of each ACL, use an explicit configuration command to deny all traffic at the end of the ACL so that the show command counters increment when that action is taken.
G. Dangerous inbound ACLs: Watch for inbound ACLs, especially those with deny all logic at the end of the ACL. These ACLs may discard incoming overhead protocols, like routing protocol messages.
H. Standard ACL location: Standard ACLs enabled close to the source of matched addresses can discard the packets as intended, but also discard packets that should be allowed through. Always pay close attention to the requirements of the ACL in these cases.
This chapter (and the previous) have already discussed the details of Step 3. The first two steps are important for Simlet questions in case you are not allowed to look at the configuration; you can use other show commands to determine all the relevant ACL configuration. The next few pages show some of the related commands and how they can uncover some of the issues described in the just-completed ACL troubleshooting checklist.
ACL Troubleshooting Commands
If you suspect ACLs are causing a problem, the first problem-isolation step is to find the location and direction of the ACLs. The fastest way to do this is to look at the output of the show running-config command and to look for ip access-group commands under each interface. However, in some cases, enable mode access may not be allowed, and show commands are required. Instead, use the show ip interfaces command to find which ACLs are enabled on which interfaces, as shown in Example 17-8.
Example 17-8 Sample show ip interface Command
R1> show ip interface s0/0/1
Serial0/0/1 is up, line protocol is up
Internet address is 10.1.2.1/24
Broadcast address is 255.255.255.255
Address determined by setup command
MTU is 1500 bytes
Helper address is not set
Directed broadcast forwarding is disabled
Multicast reserved groups joined: 224.0.0.9
Outgoing access list is not set
Inbound access list is 102
! roughly 26 more lines omitted for brevity
Note that the command output lists whether an ACL is enabled, in both directions, and which ACL it is. The example shows an abbreviated version of the show ip interface S0/0/1 command, which lists messages for just this one interface. The show ip interface command would list the same messages for every interface in the router.
Step 2 of the ACL troubleshooting checklist then says that the contents of the ACL must be found. Again, the quickest way to look at the ACL is to use the show running-config command. If it’s not available, the show access-lists and show ip access-lists commands list the same details shown in the configuration. These commands also list a useful counter that lists the number of packets that have matched each line in the ACL. Example 17-9 shows an example.
Example 17-9 show ip access-lists Command Example
R1# show ip access-lists
Extended IP access list 102
10 permit ip 10.1.2.0 0.0.0.255 10.1.4.0 0.0.1.255 (15 matches)
The counter can be very useful for troubleshooting. If you can generate traffic that you think should match a particular line in an ACL, then you should see the matches increment on that counter. If you keep generating traffic that should match, but that line’s counter never goes up, then those packets do not match that line in that ACL. Those packets could be matching an earlier line in the same ACL, or might not even be reaching that router (for any reason).
After the locations, directions, and configuration details of the various ACLs have been discovered in Steps 1 and 2, the hard part begins—analyzing what the ACL really does. For example, one of the most common tasks you will do is to look at the address fields and decide the range of addresses matched by that field. Remember, for an ACL that sits in a router configuration, you can easily find the address range. The low end of the range is the address (the first number), and the high end of the range is the sum of the address and wildcard mask. For instance, with ACL 102 in Example 17-9, which is obviously configured in some router, the ranges are as follows:
Source 10.1.2.0, wildcard 0.0.0.255: Matches from 10.1.2.0 through 10.1.2.255
Destination 10.1.4.0, wildcard 0.0.1.255: Matches from 10.1.4.0 through 10.1.5.255
The next few pages work through some analysis of a few of the items from Step 3 in the troubleshooting checklist.
Example Issue: Reversed Source/Destination IP Addresses
IOS cannot recognize a case in which you attempt to match the wrong addresses in the source or destination address field. So, be ready to analyze the enabled ACLs and their direction versus the location of different subnets in the network. Then ask yourself about the packets that drive that ACL: what could the source and destination addresses of those packets be? And does the ACL match the correct address ranges, or not?
For example, consider Figure 17-11, a figure that will be used in several troubleshooting examples in this chapter. The requirements for the next ACL follow the figure.
For this next ACL, the requirements ask that you allow and prevent various flows, as follows:
Allow hosts in subnet 10.3.3.0/25 and subnet 10.1.1.0/24 to communicate
Prevent hosts in subnet 10.4.4.0/23 and subnet 10.1.1.0/24 from communicating
Allow all other communications between hosts in network 10.0.0.0
Prevent all other communications
Example 17-10 shows the ACL used in this case on R2. At first glance, it meets all those requirements straight down the list.
Example 17-10 Troubleshooting Example 2 per Step 3B: Source and Destination Mismatch
R2# show ip access-lists
Standard IP access list Step3B
10 permit 10.3.3.0 0.0.0.127
20 deny 10.4.4.0 0.0.1.255
30 permit 10.0.0.0 0.255.255.255 (12 matches)
R2#
R2# show ip interface G0/2 | include Inbound
Inbound access list is Step3B
The problem in this case is that the ACL has been enabled on R2’s G0/2 interface, inbound. Per the figure, packets coming from a source address in subnets 10.3.3.0/25 and 10.4.4.0/23 should be forwarded out R2’s G0/2 interface, rather than coming in that interface. So, do not let the matching logic in the ACL that perfectly mirrors the requirements fool you; make sure and check the location of the ACL, direction, and the location of the IP addresses.
Note that Step 3C suggests a similar issue regarding matching well-known ports with TCP and UDP. The earlier section in this chapter titled “Matching TCP and UDP Port Numbers” has already discussed those ideas in plenty of detail. Just make sure to check where the server sits versus the location and direction of the ACL.
Steps 3D and 3E: Common Syntax Mistakes
Steps 3D and 3E describe a couple of common syntax mistakes. First, to match a TCP port in an ACL statement, you must use a tcp protocol keyword instead of ip or any other value. Otherwise, IOS rejects the command as having incorrect syntax. Same issue with trying to match UDP ports: a udp protocol keyword is required.
To match ICMP, IOS includes an icmp protocol keyword to use instead of tcp or udp. In fact, the main conceptual mistake is to think of ICMP as an application protocol that uses either UDP or TCP; it uses neither. To match all ICMP messages, for instance, use the permit icmp any any command in an extended named ACL.
Example Issue: Inbound ACL Filters Routing Protocol Packets
A router bypasses outbound ACL logic for packets the router itself generates. That might sound like common sense, but it is important to stop and think about that fact in context. A router can have an outgoing ACL, and that ACL can and will discard packets that the router receives in one interface and then tries to forward out some other interface. But if the router creates the packet, for instance, for a routing protocol message, the router bypasses the outbound ACL logic for that packet.
However, a router does not bypass inbound ACL logic. If an ACL has an inbound ACL enabled, and a packet arrives in that interface, the router checks the ACL. Any and all IPv4 packets are considered by the ACL—including important overhead packets like routing protocol updates.
For example, consider a seemingly good ACL on a router, like the Step3G ACL in Example 17-11. That ACL lists a couple of permit commands, and has an implicit deny any at the end of the list. At first, it looks like any other reasonable ACL.
Example 17-11 Troubleshooting Example 2 per Step 3G: Filtering RIP by Accident
R1# show ip access-lists
Standard IP access list Step3G
10 permit host 10.4.4.1
20 permit 10.3.3.0 0.0.0.127 (12 matches)
! using the implicit deny to match everything else
R1#
! On router R1:
R1# show ip interface G0/2 | include Inbound
Inbound access list is Step3G
Now look at the location and direction (inbound on R1, on R1’s G0/2) and consider that location versus the topology Figure 17-11 for a moment. None of those permit statements match the RIP updates sent by R2, sent out R2’s G0/1 interface toward R1. RIP messages use UDP (well-known port 520), and R2’s G0/1 interface is 10.2.2.2 per the figure. R1 would match incoming RIP messages with the implicit deny all at the end of the list. The symptoms in this case, assuming only that one ACL exists, would be that R1 would not learn routes from R2, but R2 could still learn RIP routes from R1.
Of the three routing protocols discussed in the ICND1 and ICND2 books, RIPv2 uses UDP as a transport, while OSPF and EIGRP do not even use a transport protocol. As a result, to match RIPv2 packets with an ACL, you need the udp keyword and you need to match well-known port 520. OSPF and EIGRP can be matched with special keywords as noted in Table 17-7. The table also list the addresses used by each protocol.
Example 17-12 shows a sample ACL with three lines, one to match each routing protocol, just to show the syntax. Note that in this case, the ACL matches the address fields with the any keyword. You could include lines like these in any inbound ACL to ensure that routing protocol packets would be permitted.
Example 17-12 Example ACL that Matches all RIPv2, OSPF, and EIGRP with a Permit
R1# show ip access-lists
ip access-list extended RoutingProtocolExample
10 permit udp any any eq 520
20 permit ospf any any
30 permit eigrp any any
remark a complete ACL would also need more statements here
R1#
ACL Interactions with Router-Generated Packets
Routers bypass outbound ACL logic for packets generated by that same router. This logic helps avoid cases in which a router discards its own overhead traffic. This logic applies to packets that a router creates for overhead processes like routing protocols, as well as for commands, like ping and traceroute. This section adds a few perspectives about how ACLs impact troubleshooting, and how this exception to outbound ACL logic applies, particularly commands used from the router CLI.
Local ACLs and a Ping from a Router
For the first scenario, think about a ping command issued by a router. The command generates packets, and the router sends those packets (holding the ICMP echo request messages) out one of the router interfaces, and typically some ICMP echo reply messages are received back. As it turns out, not all ACLs will attempt to filter those packets.
As a backdrop to discuss what happens, Figure 17-12 illustrates a simple network topology with two routers connected to a serial link. Note that in this figure four IP ACLs exist, named A, B, C, and D, as noted by the thick arrows in the drawing. That is, ACL A is an outbound ACL on R1’s S0/0/0, ACL B is an inbound ACL on R2’s S0/0/1, and so on.
As an example, consider a ping command issued from R1’s CLI (after a user connects to R1’s CLI using SSH). The ping command pings server S1’s IP address. The IPv4 packets with the ICMP messages flow from R1 to S1 and back again. Which of those four ACLs could possibly filter the ICMP Echo Request toward S1, and the ICMP Echo Reply back toward R1?
Routers bypass their own outbound ACLs for packets generated by the router, as shown in Figure 17-13. Even though ACL A exists as an outgoing ACL on Router R1, R1 bypasses its own outgoing ACL logic of ACL A for the ICMP Echo Requests generated by R1.
Router Self-Ping of a Serial Interface IPv4 Address
The previous example uses a router’s ping command when pinging a host. However, network engineers often need to ping router IP addresses, including using a self-ping. The term self-ping refers to a ping of a device’s own IPv4 address. And for point-to-point serial links, a self-ping actually sends packets over the serial link, which causes some interesting effects with ACLs.
When a user issues a self-ping for that local router’s serial IP address, the router actually sends the ICMP echo request out the link to the other router. The neighboring router then receives the packet and routes the packet with the ICMP echo request back to the original router. Figure 17-14 shows an example of a self-ping (ping 172.16.4.1) of Router R1’s own IP address on a point-to-point serial link, with the ICMP echo request out the link to Router R2. At Step 2, R2 treats it like any other packet not destined for one of R2’s own IPv4 addresses: R2 routes the packet. Where? Right back to Router R1, as shown in the figure.
Now think about those four ACLs in the earlier figures compared to Figure 17-14. R1 generates the ICMP echo request, so R1 bypasses outbound ACL A. ACLs B, C, and D could filter the packet. Note that the packet sent by R2 back to R1 is not generated by R2 in this case; R2 is just routing R1’s original packet back to R1.
A self-ping of a serial interface actually tests many parts of a point-to-point serial link, as follows:
The link must work at Layers 1, 2, and 3. Specifically, both routers must have a working (up/up) serial interface, with correct IPv4 addresses configured.
ACLs B, C, and D must permit the ICMP echo request and reply packets.
So, when troubleshooting, if you choose to use self-pings and they fail, but the serial interfaces are in an up/up state, do not forget to check to see whether the ACLs have filtered the Internet Control Management Protocol (ICMP) traffic.
Router Self-Ping of an Ethernet Interface IPv4 Address
A self-ping of a router’s own Ethernet interface IP address works a little like a self-ping of a router’s serial IP address, but with a couple of twists:
Like with serial interface, the local router interface must be working (in an up/up state); otherwise, the ping fails.
Unlike serial interfaces, the router does not forward the ICMP messages physically out the interface, so security features on neighboring switches (like port security) or routers (like ACLs) cannot possibly filter the messages used by the ping command.
Like serial interfaces, an incoming IP ACL on the local router does process the router self-ping of an Ethernet-based IP address.
Figure 17-15 walks through an example. In this case, R2 issues a ping 172.16.2.2 command to ping its own G0/2 IP address. Just like with a self-ping on serial links, R2 creates the ICMP echo request. However, R2 basically processes the ping down its own TCP/IP stack and back up again, with the ICMP echo never leaving the router’s Ethernet interface. R2 does check the Ethernet interface status, showing a failure if the interface is not up/up. R2 does not apply outbound ACL logic to the packet, because R2 created the packet, but R2 will apply inbound ACL logic to the packet, as if the packet had been physically received on the interface.
Chapter Review
One key to doing well on the exams is to perform repetitive spaced review sessions. Review this chapter’s material using either the tools in the book, DVD, or interactive tools for the same material found on the book’s companion website. Refer to the “Your Study Plan” element for more details. Table 17-8 outlines the key review elements and where you can find them. To better track your study progress, record when you completed these activities in the second column.
Review All the Key Topics
Command References
Tables 17-10 and 17-11 list configuration and verification commands used in this chapter. As an easy review exercise, cover the left column in a table, read the right column, and try to recall the command without looking. Then repeat the exercise, covering the right column, and try to recall what the command does.
Table 17-10 Chapter 17 ACL Configuration Command Reference
Table 17-11 Chapter 17 EXEC Command Reference
Answers to Earlier Practice Problems
Table 17-12 lists the answers to the practice problems listed in Table 17-6. Note that for any question that references a client, you might have chosen to match port numbers greater than 1023. The answers in this table mostly ignore that option, but just to show one sample, the answer to the first problem lists one with a reference to client ports greater than 1023 and one without. The remaining answers simply omit this part of the logic.
