CCNP Routing and Switching TSHOOT 300-135 Official Cert Guide (2015)

Part III. Troubleshooting Router Features

Chapter 11. Troubleshooting IPv4 and IPv6 ACLs and Prefix Lists

This chapter covers the following topics:

Troubleshooting IPv4 ACLs: This section examines how you can read IPv4 ACLs so that you are more efficient at troubleshooting IPv4 ACL-related issues. You will also learn the commands and processes that you can use while troubleshooting IPv4 packet filtering with standard, extended, and time-based IPv4 ACLs.

IPv4 ACL Trouble Tickets: This section provides trouble tickets that demonstrate how you can use a structured troubleshooting process to solve a reported problem.

Troubleshooting IPv6 ACLs: This section examines how you can read IPv6 ACLs so that you are more efficient at troubleshooting IPv6 ACL-related issues. You will also discover the commands and processes that you can use while troubleshooting IPv6 packet filtering.

IPv6 ACL Trouble Tickets: This section provides trouble tickets that demonstrate how you can use a structured troubleshooting process to solve a reported problem.

Troubleshooting Prefix Lists: This section reviews how to efficiently examine a prefix list for troubleshooting purposes so that when you are dealing with an issue that has a prefix list associated with it, you can determine whether the prefix list is or is not the problem.

Prefix List Trouble Tickets: This section provides trouble tickets that demonstrate how you can use a structured troubleshooting process to solve a reported problem.

Access control lists (ACLs) and prefix lists are powerful tools that you need to be comfortable with as a troubleshooter. They enable you to classify traffic or routes, and then depending on how you apply them, take a specific action. One slight error in an ACL or prefix list will change the meaning of it and, as a result, how the service or feature that relies on it handles the route or traffic.

Therefore, you need to be able to read ACLs and prefix lists efficiently. You need a solid understanding of the way they are processed and how the devices using them make a decision based on the entries. Without this knowledge, you cannot successfully eliminate or prove that the ACL or prefix list is the problem.

This chapter covers the ins and outs of ACLs and prefix lists. You will learn the way they are processed, how they are read, and how you can identify issues related to them. In addition, this chapter explains how you can use ACLs for traffic filtering and how a prefix list can be used for route filtering.

“Do I Know This Already?” Quiz

The “Do I Know This Already?” quiz allows you to assess whether you should read this entire chapter thoroughly or jump to the “Exam Preparation Tasks” section. If you are in doubt about your answers to these questions or your own assessment of your knowledge of the topics, read the entire chapter. Table 11-1 lists the major headings in this chapter and their corresponding “Do I Know This Already?” quiz questions. You can find the answers in Appendix A, “Answers to the ‘Do I Know This Already?’ Quizzes.”

Table 11-1 “Do I Know This Already?” Section-to-Question Mapping

Caution

The goal of self-assessment is to gauge your mastery of the topics in this chapter. If you do not know the answer to a question or are only partially sure of the answer, you should mark that question as wrong for purposes of the self-assessment. Giving yourself credit for an answer that you correctly guess skews your self-assessment results and might provide you with a false sense of security.

1. What is the correct order of operations for an IPv4 ACL?

a. Top-down processing, execute upon the longest match, implicit deny all

b. Execute upon the longest match, top down processing, implicit deny all

c. Implicit deny all, immediate execution upon a match, top-down processing

d. Top-down processing, immediate execution upon a match, implicit deny all

2. What occurs to a packet when an ACL is applied to an interface but the packet does not match any of the entries in the ACL?

a. It is forwarded.

b. It is flooded.

c. It is dropped.

d. It is buffered.

3. What will the following ACL entry accomplish when applied to an interface: 20 permit tcp 10.1.1.0 0.0.0.63 host 192.0.2.1 eq 23?

a. Permit Telnet traffic from the device with an IP address of 192.0.2.1 going to any device with an IP address from 10.1.1.0 to 10.1.1.63

b. Permit Telnet traffic from any device with an IP address from 10.1.1.0 to 10.1.1.63 going to the device with an IP address of 192.0.2.1

c. Permit SSH traffic from any device with an IP address from 10.1.1.0 to 10.1.1.63 going to the device with an IP address of 192.0.2.1

d. Permit SSH traffic from the device with an IP address of 192.0.2.1 going to any device with an IP address from 10.1.1.0 to 10.1.1.63

4. Which command will successfully filter ingress traffic using ACL 100 on an interface?

a. access-group 100 in

b. access-class 100 in

c. ip access-group 100 in

d. ip traffic-filter 100 in

5. What is the correct order of operations for an IPv6 ACL?

a. Immediate execution upon a match, implicit permit icmp nd, implicit deny all, top-down processing

b. Top-down processing, immediate execution upon a match, implicit permit icmp nd, implicit deny all

c. Top-down processing, implicit permit icmp nd, immediate execution upon a match, implicit deny all

d. Implicit permit icmp nd, top-down processing, immediate execution upon a match, implicit deny all

6. What will happen if you add the following entry to the end of an IPv6 ACL: deny ipv6 any any log? (Choose two answers.)

a. All traffic will be denied and logged.

b. All traffic that does not match an entry in the ACL will be denied and logged.

c. ICMP Neighbor Discovery messages will still be implicitly permitted.

d. ICMP Neighbor Discovery messages will be denied.

7. Which command will successfully filter egress traffic using an IPv6 ACL named TSHOOT on an interface?

a. access-group TSHOOT out

b. access-class TSHOOT out

c. ipv6 access-group TSHOOT out

d. ipv6 traffic-filter TSHOOT out

8. Which IP prefix list will match only the default route?

a. ip prefix-list TSHOOT permit 0.0.0.0/0 le 32

b. ip prefix-list TSHOOT permit 0.0.0.0/0 ge 32

c. ip prefix-list TSHOOT permit 0.0.0.0/0 ge 1

d. ip prefix-list TSHOOT permit 0.0.0.0/0

9. Which IP prefix list will match all routes?

a. ip prefix-list TSHOOT permit 0.0.0.0/0 le 32

b. ip prefix-list TSHOOT permit 0.0.0.0/0 ge 32

c. ip prefix-list TSHOOT permit 0.0.0.0/0 ge 1

d. ip prefix-list TSHOOT permit 0.0.0.0/0

10. What routes match the following prefix list: ip prefix-list TSHOOT seq 35 deny 192.168.0.0/20 ge 24 le 28?

a. Routes with an address from 192.168.0.0 to 192.168.15.255 with a subnet mask of 24 to 28

b. Routes within the 192.168.0.0/20 subnet with a subnet mask greater than 24 and less than 28

c. Routes with the subnet ID and mask of 192.168.0.0/20

d. Routes with an address from 192.168.0.0 to 192.168.15.255 with a subnet mask of 24 or 28

Foundation Topics

Troubleshooting IPv4 ACLs

The purpose of an access control list is to identify traffic based on different criteria such as source or destination IP address, source or destination port numbers, transport layer protocols, quality of service (QoS) markings, and so on. An ACL that has been created does nothing unless it is applied to a service, feature, or interface. For example, it can be used to identify the private IP addresses that will be translated to a public address with Network Address Translation (NAT) and Port Address Translation (PAT). It can also be used to control which routes will be redistributed, which packets will be policy-based routed, and which packets will be permitted or denied through the router. Therefore, as a troubleshooter, it is imperative that you can read an ACL to determine whether it was created correctly; otherwise, the services you are applying it to will fail to produce the results you want.

This section explains how to troubleshoot an IPv4 ACL to make sure that it is correctly created for the purpose it is intended for. The section also provides examples related to packet filtering. Other examples related to distribute lists, route maps, and policy-based routing (PBR) are covered in later chapters relating to those features.

Reading an IPv4 ACL

Being able to read an ACL and understand what it was created for is important for troubleshooting. However, understanding how an ACL functions is even more important as you troubleshoot because you need to identify why you are experiencing the issues that are occurring. Following is a list of steps that IPv4 ACLs use. You want to remember these steps because they will help you identify why an IPv4 ACL is behaving the way it is.

Step 1. Top down processing: An ACL is made up of various entries; these entries are processed from the top of the ACL to the bottom of the ACL in order.

Step 2. Immediate execution upon a match: The very first entry that matches the values in the packet that are being compared will be the entry that is used. This may be a permit entry or a deny entry and will dictate how the packet is treated based on the ACL implementation. If there is another entry later in the ACL that matches, it does not matter. Only the first entry that matches matters.

Step 3. Implicit deny any: If there is no matching entry for the packet, the packet is automatically denied based on the invisible implicit deny any entry at the end of an ACL.

Refer to Example 11-1, which displays a sample standard numbered ACL that uses only source IPv4 addresses. In this example, the ACL is numbered 1 and has four entries. The entries are listed from most specific to least specific. In earlier versions of the IOS, if you did not create the entries from most specific to least specific, you ended up with generic entries earlier in the ACL that would cause issues by dropping or permitting traffic that should not be. In newer versions of the IOS, if you attempt to create an ACL entry that is more specific than an entry that already exists, the router will prevent the entry from being created and give an error message.

Notice how traffic sourced from 10.1.1.5 is denied in sequence 5. Even though the very next sequence of 10 permits 10.1.1.5, 10.1.1.5 will be denied because of top-down processing and then immediate execution upon a match. Likewise, even though sequence 30 permits all addresses from 10.1.1.0 through 10.1.1.255, 10.1.1.5 is denied by sequence 5, and 10.1.1.64 through 10.1.1.127 are denied by sequence 20. What about all other source IP addresses that do not match an entry in the ACL? For example, the IP address 192.168.2.1. They are all denied because of the implicit deny entry (you cannot see it) at the end of the ACL.

Example 11-1 Sample Standard Numbered ACL

Router#show access-lists
Standard IP access list 1
5 deny 10.1.1.5
10 permit 10.1.1.0, wildcard bits 0.0.0.63 (1 match)
20 deny 10.1.1.64, wildcard bits 0.0.0.63
30 permit 10.1.1.0, wildcard bits 0.0.0.255

Extended ACLs are a little more complicated to read and troubleshoot because they contain more parameters. The previous example was a standard ACL that only allows a source address to be specified. The extended ACL can take source and destination addresses, source and destination port numbers, protocols, and other parameters that give you granular control over what you are trying to match. Also remember that standard and extended IPv4 ACLs can be named instead of numbered.

Example 11-2 provides a sample extended numbered ACL. In this example, it is numbered 100. It has four entries, listed from most specific to least specific. Notice in sequence 10 that 10.1.1.5 is denied from accessing TCP services using port 80 on 192.0.2.1. At the same time, under sequence 20, 10.1.1.5 would be permitted to telnet to 192.0.2.1, and in sequence 40, it would be permitted to any destination on any port using any protocol. Therefore, you have much more granular control over how the traffic will be matched in an extended ACL.

Example 11-2 Sample Extended Numbered ACL

R1#show access-lists 100
Extended IP access list 100
10 deny tcp host 10.1.1.5 host 192.0.2.1 eq www
20 permit tcp 10.1.1.0 0.0.0.63 host 192.0.2.1 eq telnet
30 deny ip 10.1.1.64 0.0.0.63 host 192.0.2.1
40 permit ip 10.1.1.0 0.0.0.255 any

Using an IPv4 ACL for Filtering

Using an ACL for packet filtering requires you to apply the ACL to an interface. You can accomplish this with the ip access-group {acl_number|name} {in|out} command in interface configuration mode, as shown in Example 11-3. The direction you apply the ACL on an interface is significant. You need to consider this while you are creating the ACL. If you apply it to the wrong interface or in the wrong direction, you will not get the desired result. You can verify the ACLs that are applied to an interface using the show ip interface interface_type interface_numbercommand. Example 11-3 shows how access list 1 is applied inbound on Gig0/0 and access list 100 is applied outbound on Gig0/0.

Example 11-3 Verifying Access Lists Applied to Interfaces

R1(config)#interface gigabitEthernet 0/0
R1(config-if)#ip access-group 100 out
R1(config-if)#ip access-group 1 in
R1(config-if)#end
R1#show ip interface gigabitEthernet 0/0
GigabitEthernet0/0 is up, line protocol is up
Internet address is 10.1.1.1/24
Broadcast address is 255.255.255.255
Address determined by non-volatile memory
MTU is 1500 bytes
Helper address is 172.16.1.10
Directed broadcast forwarding is disabled
Multicast reserved groups joined: 224.0.0.5 224.0.0.6
Outgoing access list is 100
Inbound access list is 1
Proxy ARP is enabled
Local Proxy ARP is disabled

Using a Time-Based IPv4 ACL

By default, an ACL you apply is active the entire time it is applied. However, that might not be your goal. For example, perhaps you want to prevent traffic from going to the Internet after hours but allow it during hours. Or give a certain service or user the ability to back up files to a server from 9 p.m. to 1 a.m. Monday to Friday and prevent them from doing it any other time.

To accomplish these goals, you need to use time-based ACLs. Review Example 11-4, which provides a sample time-based ACL. Notice that the ACL entry with a sequence number of 10 has the time-range option added. The time range is based on values configured in the AFTERHOURS time range. It also states that it is active, meaning that the current entry will be denying WWW traffic from host 10.1.1.5 to 192.0.2.1. Because the ACL entry is attached to a time range, when troubleshooting time-based ACLs you will also have to review the configuration of the time range itself. Example 11-5 displays the AFTERHOURS time range with the show time-range AFTERHOURS command. It has two weekdays entries, one from 5 p.m. to midnight and the other from midnight to 9 a.m. It also has a weekend entry that covers all day and all night. It also states that it is active and used in an ACL. When the access control entry is outside of the time range, it will display inactive.

Example 11-4 Sample Time-Based ACL

R1#show access-lists 100
Extended IP access list 100
10 deny tcp host 10.1.1.5 host 192.0.2.1 eq www time-range AFTERHOURS (active)
20 permit tcp 10.1.1.0 0.0.0.63 host 192.0.2.1 eq telnet
30 deny ip 10.1.1.64 0.0.0.63 host 192.0.2.1
40 permit ip 10.1.1.0 0.0.0.255 any

Example 11-5 Sample Time Range Configured on R1

R1#show time-range AFTERHOURS
time-range entry: AFTERHOURS (active)
periodic weekdays 17:00 to 23:59
periodic weekdays 0:00 to 8:59
periodic weekend 0:00 to 23:59
used in: IP ACL entry

So far, you have seen that you have to troubleshoot the ACL, and the time range when dealing with issues related to time-based ACLs. However, there is one more item of troubleshooting: time!

Time-based ACLs are based on the router clock. If the router clock is not correct, the time-based ACL may be active or inactive at the wrong time. Example 11-6 shows how you can verify the current time on a router with the show clock command. Notice how it is Sunday May 25, 2014, at 10:53 a.m. Therefore, the time-based ACL entry should be active because it is AFTERHOURS. We only want to permit WWW traffic Monday to Friday 9 a.m. to 5 p.m. All other times, it is denied.

Example 11-6 Viewing the Time on a Cisco Router

R1#show clock
*10:53:50.067 UTC Sun May 25 2014

But wait, are we sure it is the right time? Are we using manually set clocks, have they changed? Or are we using a Network Time Protocol (NTP) server? You will want to verify with another time source that this is in fact the right time. In addition, if you are using NTP (which you should be), you need to check your NTP settings to make sure that the clocks are synchronized and that the time is right, and do not forget to consider daylight savings time.

IPv4 ACL Trouble Tickets

This section presents various trouble tickets relating to the topics discussed earlier in the chapter. The purpose of these trouble tickets is to give a process that you can follow when troubleshooting in the real world or in an exam environment. All trouble tickets in this section are based on the topology depicted in Figure 11-1.

Figure 11-1 IPv4 ACL Trouble Ticket Topology

Trouble Ticket 11-1

Problem: A user at PC1 has indicated that he cannot telnet to 192.0.2.1 and he needs to. However, he can ping 192.0.2.1 and access web-enabled resources.

You start by verifying the problem. On PC1, you attempt to telnet to 192.0.2.1, but it fails, as shown in Example 11-7. You then ping 192.0.2.1, and it is successful, as also shown in Example 11-7.

Example 11-7 Failed Telnet and Successful Ping from PC1 to 192.0.2.1

C:\PC1>telnet 192.0.2.1
Connecting To 192.0.2.1...Could not open connection to the host, on port 23: Connect failed

C:\PC1>ping 192.0.2.1
Reply from 192.0.2.1: bytes=32 time 1ms TTL=128
Reply from 192.0.2.1: bytes=32 time 1ms TTL=128
Reply from 192.0.2.1: bytes=32 time 1ms TTL=128
Reply from 192.0.2.1: bytes=32 time 1ms TTL=128

Ping statistics for 192.0.2.1:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 0ms, Average = 0ms

At this point, you should be thinking that the issue is related to either the Telnet service being disabled on 192.0.2.1 or an ACL. Why an ACL? This is because certain types of traffic are allowed through but others are not, which is accomplished with filtering.

First, let’s verify whether there are any ACLs configured on R1 that may filter Telnet-related traffic. In Example 11-8, the show ip access-lists command is used to verify whether any ACLs are configured on R1. In this example, there is one extended IPv4 ACL identified as number 100. You can see that there are two entries related to Telnet. One is a permit entry with a sequence number of 10, and the other is a deny entry with a sequence number of 20. Notice how the deny entry has 9 matches and the permit entry has no matches. Read sequence 10 out loud:

Sequence 10 will permit tcp traffic related to telnet from 192.0.2.1 to 10.1.1.10.

Read it again and think about how the traffic is flowing based on this entry:

FROM 192.0.2.1 TO 10.1.1.10

PC1 is trying to establish a Telnet session to 192.02.1 (not the other way around). Therefore, sequence 10 does not match the Telnet traffic from PC1 to 192.0.2.1. It matches Telnet traffic from 192.0.2.1 to PC1.

Sequence 20 states that TCP traffic related to Telnet from the 10.1.1.0/26 network to any destination will be denied. Therefore, using the top-down processing and immediate execution upon a match flow, sequence 20 matches the Telnet traffic from PC1 to 192.0.2.1, and as a result, the traffic is denied.

Example 11-8 Verifying ACLs Configured on R1

R1#show ip access-lists
Extended IP access list 100
10 permit tcp host 192.0.2.1 host 10.1.1.10 eq telnet
20 deny tcp 10.1.1.0 0.0.0.63 any eq telnet (9 matches)
30 deny tcp 10.1.1.0 0.0.0.63 any eq ftp
40 permit tcp 10.1.1.0 0.0.0.63 any eq 22
50 deny tcp 10.1.1.0 0.0.0.63 any eq smtp
60 permit ip any any (2 matches)

The best way to fix this is to remove sequence 10 and replace it with the correct entry. We can use named ACL configuration mode to accomplish this. Example 11-9 displays how you can use named ACL configuration mode to edit a numbered ACL and the output of show ip access-lists, which verifies that the changes were made.

Example 11-9 Using Named ACL Configuration Mode to Modify Numbered ACL

R1#config t
Enter configuration commands, one per line. End with CNTL/Z.
R1(config)#ip access-list extended 100
R1(config-ext-nacl)#no 10
R1(config-ext-nacl)#10 permit tcp host 10.1.1.10 host 192.0.2.1 eq 23
R1(config-ext-nacl)#end
R1#
R1#show access-lists
Extended IP access list 100
10 permit tcp host 10.1.1.10 host 192.0.2.1 eq telnet
20 deny tcp 10.1.1.0 0.0.0.63 any eq telnet (9 matches)
30 deny tcp 10.1.1.0 0.0.0.63 any eq ftp
40 permit tcp 10.1.1.0 0.0.0.63 any eq 22
50 deny tcp 10.1.1.0 0.0.0.63 any eq smtp
60 permit ip any any (4 matches)

As shown in Example 11-10, you issue the telnet 192.0.2.1 command from PC1, and the connection is successful.

Example 11-10 Successful Telnet Connection from PC1 to 192.0.2.1

C:\PC1>telnet 192.0.2.1
User Access Verification
Password:

Reviewing the output of show ip access-lists on R1, as shown in Example 11-11, reveals the matches associated with sequence 10 now.

Example 11-11 Verifying Packet Matches For an ACL Entry

R1#show ip access-lists
Extended IP access list 100
10 permit tcp host 10.1.1.10 host 192.0.2.1 eq telnet (25 matches)
20 deny tcp 10.1.1.0 0.0.0.63 any eq telnet (9 matches)
30 deny tcp 10.1.1.0 0.0.0.63 any eq ftp
40 permit tcp 10.1.1.0 0.0.0.63 any eq 22
50 deny tcp 10.1.1.0 0.0.0.63 any eq smtp
60 permit ip any any (5 matches)

Troubleshooting IPv6 ACLs

IPv6 ACLs play an important role in our IPv6 networks. They allow us to classify traffic for many different reasons. For example, we might need to classify traffic that will be policy-based routed, or we may need to classify the traffic that will be filtered as it passes through the router.

IPv6 traffic filtering can be done on an interface-by-interface basis with IPv6 access lists. This section explains how to read an IPv6 access list so that you can troubleshoot them efficiently and identify whether they have been applied correctly to an interface for filtering purposes.

Reading an IPv6 ACL

Being able to read an IPv6 ACL and understand what it was created for is important for troubleshooting. However, understanding how an IPv6 ACL functions is even more important as you troubleshoot because you need to identify why you are experiencing the issues that are occurring. Following is a list of steps that IPv6 ACLs use; these are the same as IPv4 ACLs. You want to remember these steps because they will help you identify why an IPv6 ACL is behaving the way it is:

Step 1. Top-down processing: An ACL is made up of various entries; these entries are processed from the top of the ACL to the bottom of the ACL in order.

Step 3. Implicit permit icmp nd: If the packet is an NA or NS message, permit it.

Step 4. Implicit deny any: If there is no matching entry for the packet, the packet is automatically denied based on the invisible implicit deny any entry at the end of an ACL.

Pause here for a moment. Did you notice the steps differ a little from IPv4? There is an added step before the implicit deny any. Recall that IPv6 relies on the Neighbor Discovery Protocol (NDP) NA and NS messages to determine the MAC address associated with an IPv6 address. Therefore, the implicit permit icmp nd entries for NA and NS messages as follows have been added before the implicit deny any, so they are not denied:

permit icmp any any nd-na
permit icmp any any nd-ns

However, because these are implicit permit statements, all statically entered commands come before them. Therefore, if you issue the deny ipv6 any any log command at the end of your IPv6 ACL like you might be accustomed to doing in IPv4, you will break the NDP process because NAand NS messages will be denied now. Therefore, when troubleshooting NDP, an ACL might be the reason why it is not working.

With IPv4 ACLs, a clear separation existed between standard and extended IPv4 ACLs. However, with IPv6, you have just one type, which would be similar to an IPv4 extended ACL. Therefore, within an IPv6 ACL entry, you provide as little or as much information as you need to accomplish your goal.

Refer to Example 11-12, which provides a sample IPv6 ACL that was created on R1. The IPv6 access list is named TSHOOT, and you read it exactly like you read an IPv4 ACL. For example, sequence 20 states that TCP traffic related to Telnet will be denied from any device going to 2001:DB8:A:B::7/128. Sequence 30 states that TCP traffic related to WWW from 2001:DB8:A:A::20/128 to 2001:DB8:D::1/128 will be permitted.

Example 11-12 Sample IPv6 ACL

R1#show ipv6 access-list
IPv6 access list TSHOOT
permit tcp host 2001:DB8:A:A::20 host 2001:DB8:A:B::7 eq telnet sequence 10
deny tcp any host 2001:DB8:A:B::7 eq telnet sequence 20
permit tcp host 2001:DB8:A:A::20 host 2001:DB8:D::1 eq www sequence 30
deny ipv6 2001:DB8:A:A::/80 any sequence 40
permit ipv6 2001:DB8:A:A::/64 any sequence 50

Notice how there are no wildcard masks with IPv6. Instead, you specify a prefix, as shown in sequence 40 and 50 of Example 11-12, which accomplishes the same goal as the wildcard mask (defining a range of addresses). For example, a prefix of /128 is like having the all 0s wildcard mask, which would mean this exact address or host (match all bits in the address). A /0 prefix is like having the all 255s wildcard mask (do not match any bits in the address). A /64 prefix would indicate that the first 64 bits must match and that the last 64 bits do not have to match. As a result, this would include all interface IDs within a /64 network. What if the prefix is /80? This means the first 80 bits must match and the last 48 bits do not have to match. As a result, the prefix is defining which bits of the IPv6 address must match.

Using an IPv6 ACL for Filtering

Using an IPv6 ACL for packet filtering requires you to apply the IPv6 ACL to an interface. You can accomplish this with the ipv6 traffic-filter acl_name {in|out} command in interface configuration mode, as shown in Example 11-13. The direction you apply the IPv6 ACL on an interface is significant. It needs to be considered while you are creating the ACL. If you apply it to the wrong interface or in the wrong direction, you will not get the desired result. You can verify the IPv6 ACLs that are applied to an interface using the show ipv6 interface interface_type interface_number command. Example 11-13 shows how the IPv6 access-list TSHOOT is applied inbound on interface Gig0/0.

Example 11-13 Verifying IPv6 Access Lists Applied to Interfaces

R1(config)#interface gigabitEthernet 0/0
R1(config-if)#ipv6 traffic-filter TSHOOT in
R1(config-if)#end
R1#show ipv6 interface gigabitEthernet 0/0
GigabitEthernet0/0 is up, line protocol is up
IPv6 is enabled, link-local address is FE80::C808:3FF:FE78:8
No Virtual link-local address(es):
Global unicast address(es):
2001:DB8:A:A::1, subnet is 2001:DB8:A:A::/64
Joined group address(es):
FF02::1
FF02::2
FF02::1:2
FF02::1:FF00:1
FF02::1:FF78:8
MTU is 1500 bytes
ICMP error messages limited to one every 100 milliseconds
ICMP redirects are enabled
ICMP unreachables are sent
Input features: Access List
Inbound access list TSHOOT
ND DAD is enabled, number of DAD attempts: 1
ND reachable time is 30000 milliseconds (using 30000)
ND advertised reachable time is 0 (unspecified)
ND advertised retransmit interval is 0 (unspecified)
ND router advertisements are sent every 200 seconds
ND router advertisements live for 1800 seconds
ND advertised default router preference is Medium
Hosts use stateless autoconfig for addresses.
Hosts use DHCP to obtain other configuration.

IPv6 ACL Trouble Tickets

Figure 11-2 IPv6 ACL Trouble Ticket Topology

Trouble Ticket 11-2

Problem: A user at PC2 has indicated that she is not able to telnet to 2001:db8:a:b::7 and she needs to. However, she can ping 2001:db8:a:b::7 and receive DHCP-related information from the DHCP server.

You start by verifying the problem. On PC2, you attempt to telnet to 2001:db8:a:b::7, but it fails, as shown in Example 11-14. You then ping 2001:db8:a:b::7, and it is successful, as also show in Example 11-14.

Example 11-14 Failed Telnet and Successful Ping from PC2 to 2001:db8:a:b::7

C:\PC2>telnet 2001:db8:a:b::7
Connecting To 2001:db8:a:B::7...Could not open connection to the host, on port 23: Connect failed

C:\PC2>ping 2001:db8:a:b::7

Pinging 2001:db8:a:b::7 with 32 bytes of data:
Reply from 2001:db8:a:b::7: time=46ms
Reply from 2001:db8:a:b::7: time=40ms
Reply from 2001:db8:a:b::7: time=40ms
Reply from 2001:db8:a:b::7: time=40ms

Ping statistics for 2001:db8:a:b::7:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 40ms, Maximum = 46ms, Average = 41ms

What could allow pings yet deny Telnet? At this point in time, you should be thinking the issue is related to either the Telnet service being disabled on 2001:db8:a:b::7 or an IPv6 ACL filtering traffic in or out of an interface. This is because certain traffic is allowed while others are denied. Most times, this is because of traffic filtering.

First, you verify whether the Telnet service is running by using Telnet from R1 to 2001:db8:a:b::7. As shown in Example 11-15, it is successful. If it was not successful, you could then access the server or contact the users responsible for the server to see whether Telnet is enabled.

Example 11-15 Successful Telnet from R1 to 2001:db8:a:b::7

R1#telnet 2001:db8:a:b::7
Trying 2001:DB8:A:B::7 ... Open

User Access Verification

Password:

Next you check whether there are any ACLs associated with interface Gi2/0 on R1 using the command show ipv6 interface gigabitethernet2/0. As shown in Example 11-16, there are no IPv6 ACLs.

Example 11-16 Verifying ACLs on Gig2/0 of R1

R1#show ipv6 interface gigabitEthernet 2/0
GigabitEthernet2/0 is up, line protocol is up
IPv6 is enabled, link-local address is FE80::C808:3FF:FE78:38
No Virtual link-local address(es):
Global unicast address(es):
2001:DB8:A:B::1, subnet is 2001:DB8:A:B::/64
Joined group address(es):
FF02::1
FF02::2
FF02::1:FF00:1
FF02::1:FF78:38
MTU is 1500 bytes
ICMP error messages limited to one every 100 milliseconds
ICMP redirects are enabled
ICMP unreachables are sent
ND DAD is enabled, number of DAD attempts: 1
ND reachable time is 30000 milliseconds (using 30000)
ND advertised reachable time is 0 (unspecified)
ND advertised retransmit interval is 0 (unspecified)
ND router advertisements are sent every 200 seconds
ND router advertisements live for 1800 seconds
ND advertised default router preference is Medium
Hosts use stateless autoconfig for addresses.

Next you check whether there are any ACLs associated with interface Gi0/0 on R1 by using the command show ipv6 interface gigabitethernet0/0. As shown in Example 11-17, there is an inbound IPv6 ACL named TSHOOT attached to the interface.

Example 11-17 Verifying ACLs on Gig0/0 of R1

R1#show ipv6 interface gigabitEthernet 0/0
GigabitEthernet0/0 is up, line protocol is up
IPv6 is enabled, link-local address is FE80::C808:3FF:FE78:8
No Virtual link-local address(es):
Global unicast address(es):
2001:DB8:A:A::1, subnet is 2001:DB8:A:A::/64
Joined group address(es):
FF02::1
FF02::2
FF02::1:2
FF02::1:FF00:1
FF02::1:FF78:8
MTU is 1500 bytes
ICMP error messages limited to one every 100 milliseconds
ICMP redirects are enabled
ICMP unreachables are sent
Input features: Access List
Inbound access list TSHOOT
ND DAD is enabled, number of DAD attempts: 1
ND reachable time is 30000 milliseconds (using 30000)
ND RAs are suppressed (all)
Hosts use stateless autoconfig for addresses.
Hosts use DHCP to obtain other configuration.

Now you need to verify the IPv6 ACL named TSHOOT using the show ipv6 access-list TSHOOT command. Example 11-18 displays this output. Notice sequence 20. It is a permit statement allowing PC2 to telnet to 2001:db8:a:b::7. However, notice sequence 10. It is a deny statement preventing all devices from using Telnet to 2001:db8:a:b::7. Remember that IPv6 ACLs are processed from top down, and then once a match is found, it is immediately executed on. That is what is happening here. Sequence 10 matches PC2’s Telnet and denies it.

(Notice for IPv6 that the router allowed a more specific entry to be placed after a more general entry, this differs from the behavior witnessed with IPv4 ACLs earlier.)

Example 11-18 TSHOOT IPv6 ACL on R1

R1#show ipv6 access-list TSHOOT
IPv6 access list TSHOOT
deny tcp any host 2001:DB8:A:B::7 eq telnet (6 matches) sequence 10
permit tcp host 2001:DB8:A:A::20 host 2001:DB8:A:B::7 eq telnet sequence 20
permit tcp host 2001:DB8:A:A::20 host 2001:DB8:D::1 eq www sequence 30
permit ipv6 2001:DB8:A:A::/64 any (67 matches) sequence 40

To solve this issue, you connect to R1, enter IPv6 ACL configuration mode for the ACL named TSHOOT, and then you remove sequence 20 and add the same entry with a sequence number of 5 so that it is before sequence 10, as shown in Example 11-19. In addition, you verify the changes with the show ipv6 access-list TSHOOT command.

Example 11-19 Modifying TSHOOT IPv6 ACL on R1

R1#config t
Enter configuration commands, one per line. End with CNTL/Z.
R1(config)#ipv6 access-list TSHOOT
R1(config-ipv6-acl)#no sequence 20
R1(config-ipv6-acl)#seq 5 permit tcp host 2001:DB8:A:A::20 host 2001:DB8:A:B::7 eq telnet

R1#show ipv6 access-list TSHOOT
IPv6 access list TSHOOT
permit tcp host 2001:DB8:A:A::20 host 2001:DB8:A:B::7 eq telnet sequence 5
deny tcp any host 2001:DB8:A:B::7 eq telnet (6 matches) sequence 10
permit tcp host 2001:DB8:A:A::20 host 2001:DB8:D::1 eq www sequence 30
permit ipv6 2001:DB8:A:A::/64 any (67 matches) sequence 40

Now you go back to PC2 and attempt to telnet to 2001:db8:a:b::7. In Example 11-20, it is successful.

Example 11-20 Successful Telnet from PC2 to 2001:db8:a:b::7

C:\PC2>telnet 2001:db8:a:b::7

User Access Verification

Password:

Troubleshooting Prefix Lists

Although an ACL can give you extreme granular control of the traffic you want to match, it lacks the ability to identify routes based on a subnet mask. Therefore, ACLs do not give you granular control when matching routes for route filtering. This is why prefix lists exist. They allow you to define the route and prefix that you want to match. This section explains how to read a prefix list so that when you are troubleshooting features that call upon a prefix list you will have the ability to eliminate the prefix list as the cause of the issue or prove that the prefix list is the cause of the issue.

Note that this discussion applies to both IPv4 prefix lists and IPv6 prefix lists. The only difference is that in an IPv4 prefix list you will have IPv4 addresses and masks and in an IPv6 prefix list you will have IPv6 addresses and masks. However, the same principles and concepts apply. As a result, all the examples in this section are based on IPv4.

Reading a Prefix List

Let’s begin with an example. Example 11-21 displays the commands used to create a sample prefix list called TSHOOT and the output of show ip prefix-list, which you can use to verify the IPv4 prefix lists configured on a router. To verify IPv6 prefix lists you use the command show ipv6 prefix-list.

Example 11-21 Sample IPv4 Prefix List

R1#config t
Enter configuration commands, one per line. End with CNTL/Z.
R1(config)#ip prefix-list TSHOOT seq 10 deny 10.1.1.0/26
R1(config)#ip prefix-list TSHOOT seq 20 permit 10.1.1.0/24 le 32
R1(config)#ip prefix-list TSHOOT seq 30 permit 0.0.0.0/0
R1(config)#ip prefix-list TSHOOT seq 35 deny 192.168.0.0/20 ge 24 le 28
R1(config)#end
R1#show ip prefix-list
ip prefix-list TSHOOT: 3 entries
seq 10 deny 10.1.1.0/26
seq 20 permit 10.1.1.0/24 le 32
seq 30 permit 0.0.0.0/0
seq 35 deny 192.168.0.0/20 ge 24 le 28

There are two different ways to read a prefix list entry. The way you read a prefix list entry is based on whether there is a le (less than or equal to) or ge (greater than or equal to) at the end of the prefix list entry or not.

No ge or le: If the entry does not contain a ge or le, the prefix is treated as an address and a subnet mask. Refer to the entry with a sequence number of 10 in Example 11-21. There is no ge or le; therefore, the network 10.1.1.0/26 is matched exactly. For example, if you are using the prefix list to filter routing updates, the 10.1.1.0/26 network will be denied (meaning that it will be filtered and not used).

There is a ge or le: If the entry does contain a ge or le, the prefix is treated as an address and a wildcard mask. Refer to the entry with a sequence number of 20 in Example 11-21. Because there is a ge or le, the entry is defining a range of values. 10.1.1.0/24 really means 10.1.1.0 0.0.0.255 (where 0.0.0.255 is the inverse of the subnet mask), which indicates a range of addresses from 10.1.1.0 through 10.1.1.255 (just like an ACL). The le at the end means less than or equal to, and the 32 is referring to a subnet mask. Therefore, this entry is permitting any address from 10.1.1.0 through 10.1.1.255 with a subnet mask less than or equal to 32 (0 to 32). For example, if you are using the prefix list to filter routing updates, the 10.1.1.0/24, 10.1.1.64/26, and 10.1.1.128/30 networks would all be permitted because they fall within the prefix range and subnet mask range.

Refer to sequence 30 in Example 11-21. Because there is no ge or le, it will be an exact match to the address and mask listed. In this case, the address and mask are 0.0.0.0/0, which is the default route. Therefore, if this prefix list is being used to filter routing updates, the filter would permit the default route.

Refer to sequence 35 in Example 11-21. Because there is a ge or le, the address and mask are treated as an address and wildcard mask to define a range. Therefore, 192.168.0.0/20 is 192.168.0.0 0.0.15.255, which defines a range of 192.168.0.0 through 192.168.15.255. The ge 24 le 28 values specify a subnet mask range from 24 to 28. Therefore, if this prefix entry was used to filter routes, all routes with an address from 192.168.0.0 to 192.168.15.255 with a subnet mask of 24 to 28 will be denied.

Now it is your turn. Which routes will match the following prefix list:

ip prefix-list EXAMPLE permit 10.1.1.0/24 ge 26

Before you read any further, try to determine it on your own.

Because there is a ge, the /24 is treated as a wildcard mask of 0.0.0.255. Therefore, the range of routes are from 10.1.1.0 to 10.1.1.255. (The first 24 bits must match.) However, the ge 26 indicates that the routes also must have a subnet mask from 26 to 32. So, to sum up the prefix list, any route from 10.1.1.0 to 10.1.1.255 with a subnet mask from 26 to 32 will match this prefix list.

Prefix List Processing

Following is a list of steps that prefix lists use. You want to remember these steps as they will help you identify why a prefix list is behaving the way it is.

Step 1. Top -down processing: A prefix list is made up of various entries; these entries are processed from the top of the prefix list to the bottom of the prefix list in order of sequence number. In Example 11-21, sequence 10 is processed first, then 20, 30, 40.

Step 2. Immediate execution upon a match: The very first entry that matches will be the entry that is used. This may be a permit entry or a deny entry and will dictate how the information is treated. If there is another entry later in the prefix list that matches, it does not matter. Only the first entry that matches matters. For example, even though in Example 11-21 the 10.1.1.0/26 network falls within the range defined in sequence 20, which would permit it, it is denied in sequence 10, which is processed first. Therefore, 10.1.1.0/26 is denied.

Step 3. Implicit deny any: If there is no matching entry, the information is automatically denied based on the invisible implicit deny any entry at the end of a prefix list. For example, if the prefix list in Example 11-21 is used to filter routing updates, and an update is received for 172.16.32.0/29, it is denied because it does not match sequence 10, 20, 30, or 40.

Because there is an implicit deny any at the end of a prefix list, you need at least one permit statement in a prefix list or everything will be denied. For example, if you are creating a prefix list to deny a specific route or two (for example, 10.1.1.0/24 and 10.1.2.0/24) you would create the following entries:

ip prefix-list NAME seq 10 deny 10.1.1.0/24
ip prefix-list NAME seq 20 deny 10.1.2.0/24

Although this denies both prefixes, it also denies every other prefix because of the implicit deny any at the end. Therefore, to permit everything else, you need to include an entry that does so. The following entry would do just that:

ip prefix-list NAME seq 30 permit 0.0.0.0/0 le 32

Do not confuse this with the default route entry (seq 30) from Example 11-21. That did not have an le or ge. This example does. Let’s review it. Because there is an le, it means address and wildcard mask. So, 0.0.0.0/0 is really 0.0.0.0 255.255.255.255. Therefore, the range is all/any addresses. The subnet mask will be le 32, which is 0 to 32. Therefore, we are permitting all routes in this entry. For IPv6, the equivalent permit all is as follows:

ipv6 prefix-list NAME seq 30 permit ::/0 le 128

Prefix List Trouble Tickets

Figure 11-3 IPv4 Prefix List Trouble Ticket Topology

Trouble Ticket 11-3

Problem: Your junior admin has contacted you indicating that R1 is not learning any routes via Enhanced Interior Gateway Routing Protocol (EIGRP), as shown in Example 11-22. They have confirmed that neighbor relationships are being formed, interfaces are participating in the routing process, and that other routers are learning about the routes. They have come to you for help. With your extensive knowledge, you ask your junior admin if he checked for any route filters. He says no.

Example 11-22 Verifying Routes in R1’s Routing Table

R1#show ip route
...output omitted...
Gateway of last resort is not set

10.0.0.0/8 is variably subnetted, 4 subnets, 2 masks
C 10.1.1.0/24 is directly connected, GigabitEthernet0/0
L 10.1.1.1/32 is directly connected, GigabitEthernet0/0
C 10.1.12.0/24 is directly connected, GigabitEthernet1/0
L 10.1.12.1/32 is directly connected, GigabitEthernet1/0

You execute the show ip protocols command on R1, as shown in Example 11-23. The output indicates that there is an inbound route filter using a prefix list called FILTER_10.1.3.0.

Example 11-23 Verifying Whether There Are Any Route Filters on R1

R1#show ip protocols
*** IP Routing is NSF aware ***

Routing Protocol is "eigrp 100"
Outgoing update filter list for all interfaces is not set
Incoming update filter list for all interfaces is (prefix-list) FILTER_10.1.3.0
Default networks flagged in outgoing updates
Default networks accepted from incoming updates
...output omitted...

Next you issue the show ip prefix-list command on R1 to review the prefix list called FILTER_10.1.3.0, as shown in Example 11-24. In this output, you can see that the 10.1.3.0/24 prefix is being denied. Your junior admin states that this is not the problem, because 10.1.3.0/24 is supposed to be denied based on the documentation while all others are permitted. You respond by saying that you are very sure that it is the problem. You remind your junior admin about how prefix lists are processed: 1) top down, 2) immediate execution upon a match, 3) implicit deny any at the end. Therefore, this prefix list denies all prefixes not just 10.1.3.0/24.

Example 11-24 Reviewing the Prefix List on R1

R1#show ip prefix-list
ip prefix-list FILTER_10.1.3.0: 1 entries
seq 5 deny 10.1.3.0/24

To fix this problem you create another entry for the FILTER_10.1.3.0 prefix list that permits all other routes as follows:

ip prefix-list FILTER_10.1.3.0 seq 10 permit 0.0.0.0/0 le 32

Example 11-25 displays the updated prefix list on R1, and Example 11-26 shows the updated routing table, which has all the routes except for 10.1.3.0/24, which is denied.

Example 11-25 Reviewing the Updated Prefix List on R1

R1#show ip prefix-list
ip prefix-list FILTER_10.1.3.0: 2 entries
seq 5 deny 10.1.3.0/24
seq 10 permit 0.0.0.0/0 le 32

Example 11-26 Verifying Updated Routes in R1’s Routing Table

R1#show ip route
...output omitted...
Gateway of last resort is not set

10.0.0.0/8 is variably subnetted, 8 subnets, 2 masks
C 10.1.1.0/24 is directly connected, GigabitEthernet0/0
L 10.1.1.1/32 is directly connected, GigabitEthernet0/0
D 10.1.2.0/24 [90/130816] via 10.1.12.2, 00:01:32, GigabitEthernet1/0
C 10.1.12.0/24 is directly connected, GigabitEthernet1/0
L 10.1.12.1/32 is directly connected, GigabitEthernet1/0
D 10.1.22.0/24 [90/130816] via 10.1.12.2, 00:01:32, GigabitEthernet1/0
D 10.1.23.0/24 [90/3072] via 10.1.12.2, 00:01:32, GigabitEthernet1/0
D 10.1.33.0/24 [90/131072] via 10.1.12.2, 00:01:32, GigabitEthernet1/0

Exam Preparation Tasks

As mentioned in the section “How to Use This Book” in the Introduction, you have a couple of choices for exam preparation: the exercises here; Chapter 22, “Final Preparation;” and the exam simulation questions on the CD-ROM.

Review All Key Topics

Review the most important topics in this chapter, noted with the Key Topic icon in the outer margin of the page. Table 11-2 lists a reference of these key topics and the page numbers on which each is found.

Table 11-2 Key Topics for Chapter 11

Define Key Terms

Define the following key terms from this chapter and check your answers in the glossary:

standard ACL

extended ACL

named ACL

time-based ACL

IPv6 ACL

implicit deny

implicit permit

prefix list

Command Reference to Check Your Memory

This section includes the most important show commands covered in this chapter. It might not be necessary to memorize the complete syntax of every command, but you should be able to remember the basic keywords that are needed.

To test your memory of the commands, cover the right side of Table 11-3 with a piece of paper, read the description on the left side, and then see how much of the command you can remember.

Table 11-3 show Commands

The 300-135 TSHOOT exam focuses on practical, hands-on skills that are used by a networking professional. Therefore, you should be able to identify the show commands needed to verify and troubleshoot topics presented in this chapter.