Identify Common IPv6 Routing Issues
This section presents the most commonly found issues in IPv6 networks. This discussion includes issues that affect multiple areas of IPv6 deployments, such as neighbor discovery, routing protocols, and tunneling implementations. The section ends with an IPv6 troubleshooting example.
IPv6 Routing
In IPv6 troubleshooting, you must also identify the problem symptoms and resolve them using a structured troubleshooting approach. IPv6 has many similarities with IPv4, and that makes information gathering and analysis processes similar, too. Network practitioners already have knowledge of IPv4, and comparing the symptoms of malfunctioning IPv6 components and protocols against previous knowledge of similar components and protocols in IPv4 is an intuitive and straightforward task. The similarities between, for example, OSPFv3 or RIPng (RIP Next Generation), with their counterparts in IPv4, make it easier to compare observed behavior against expected behavior. This makes the process of eliminating possible causes also a more direct task. Something as important as choosing the appropriate commands to gather information and document the symptoms becomes an intuitive task: Commands that contain the word IP maintain most of their syntax in terms of structure, as you shift from IPv4 to IPv6.
It is important to point out, however, that while IPv6 and IPv4 similarities represent a benefit, their differences might affect the troubleshooting process. This typically results in something being overlooked, or it might simply cause a conceptual misunderstanding of the issues. You need to know your basics; for example, there are no broadcasts in IPv6. Neighbors are discovered through ICMPv6 multicasts and the neighbor discovery (ND) process. The addressing structure is still hierarchical, and classless interdomain routing (CIDR) rules and nomenclature still apply. The subnet mask is still there, it is only potentially longer. You will see /96, or even /128, where before you saw /32 at the most. However, the meaning and semantics are the same, and you can use this knowledge to troubleshoot summarization errors or connectivity problems, such as suboptimal routing, caused by incorrect or poor summarization. OSPFv3 is still a link state protocol, and it behaves as such. You will see some of the major differences that can result in interesting troubleshooting scenarios; however, neighbor sessions, link state advertisements (LSAs), hierarchical areas, and so on, still exist.
The command structure for IPv6 is similar to IPv4, with a few additions and omissions in IPv6. For almost every IPv4 command, you will find an IPv6 counterpart. For example, the show ip route command becomes show ipv6 route, the show ip interface command becomes show ipv6 interface, and so on. The testing commands, ping and trace, the backbone of many troubleshooting tests, are still there and maintain syntax and outcome consistency with their IPv4 counterparts. Although the similarities between IPv4 and IPv6 will definitely help you in your troubleshooting efforts, the differences between the protocols represent a clear departure from conventional IP thinking. IPv6 is much more than a simple expansion in the address space. It does away with broadcasts, which affects protocols such as DHCP, and the Address Resolution Protocol (ARP) does not exist. Layer 2 addresses are gathered by hosts using the ICMPv6-based neighbor discovery process, which serves other purposes, as well, including duplicate address detection (DAD), stateless autoconfiguration, and other processes. Table 6-5 shows some important differences between IPv4 and IPv6.
Table 6-5: Some of the Differences Between IPv4 and IPv6 | | IPv4 | IPv6 |
| Address Resolution Protocol | Used to find Layer 2 address mappings | Does not exist. ICMPv6 neighbor discovery is used instead. |
| Secondary IP addresses | Available, but the main IP address is used as packet source | Do not exist. Interfaces can have multiple concurrent IPv6 addresses of different types. |
| Routing Protocols | Use interface IP address to exchange routing information | Use the link-local address to create neighbor sessions and to assign as the next hop. |
| Address Assignment | Static or dynamic (dynamic using DHCP) | Static or dynamic (dynamic using DHCP or stateless autoconfiguration). |
In IPv6, a standard host or router interface can have multiple IP addresses without using the concept of a secondary address. In fact, interfaces are “expected” to have multiple addresses, and different components of the protocol stack might eventually use the different identifiers for different purposes. One example for that is how routing protocols use the link-local address as a next hop and for protocol adjacencies. This can result in interesting troubleshooting scenarios and even more interesting protocol behaviors, such as the fact that OSPF routers could establish a routing protocol adjacency even when they do not belong to the same IP subnet. Many other subtle differences make IPv6 a bit of a challenge for IPv4 practitioners. The last row of Table 6-5 mentions IPv6 stateless autoconfiguration, where routers become DHCP-type providers of IP subnets and default gateways to the local hosts; this is another source of potential issues affecting hosts when misconfigured.
Troubleshooting IPv6 Issues
It is difficult to identify all the possible issues in a full protocol stack such as IPv6. Administrators of IPv6 networks usually have some familiarity with the issues discussed here, especially in specific areas such as stateless autoconfiguration or routing protocols such as OSPF. Examining IPv6 issues reveals that there are many common configuration mistakes. An example for this is a misconfigured autoconfiguration router that is not advertising network information to hosts. Until a problem like this is recognized and corrected, IPv6 hosts cannot establish full connectivity as they lack global unicast addresses.
Other typical problem areas are related to IPv6 routing protocols. There are many similarities between IPv6 routing problems and their IPv4 counterparts. Examples of IPv6 routing problems include suboptimal routing due to improper summarization and parameter mismatches on protocols such as OSPF that negotiate parameters.
For tunnel scenarios, because of the great variety of methods, you might find several instances in which other components such as routing protocols need to change when the specific migration or tunneling method changes. For example, when using 6to4 tunnels, not all interior gateway protocols (IGPs) will function properly, because when multicast addresses are used to establish adjacencies, those addresses are not properly mapped to a tunnel destination.
Identifying the IPv6 issues and failure conditions is not always an easy task, given the complexity of the protocol and especially considering the lack of experienced network practitioners who have used it. The good news is that several Cisco IOS tools and commands can help, including the following:
-
debug ipv6 routing: Use this command to display debugging messages for IPv6 routing table updates and route cache updates. This command displays messages whenever the routing table changes.
-
debug ipv6 nd: Use this command to display debugging messages for IPv6 Internet Control Message Protocol (ICMP) ND transactions. During troubleshooting, this command can help determine whether the router is sending or receiving IPv6 ICMP ND messages.
-
debug ipv6 packet: Use this command to display debugging messages for IPv6 packets. The debugging information includes packets received, generated, and forwarded. Note that fast-switched packets do not generate messages.
-
show ipv6 interface: Use this command to display the usability status of interfaces configured for IPv6 or to validate the IPv6 status of an interface and its configured addresses. If the interface’s hardware is usable, the interface is marked as up. If the interface can provide two-way communication for IPv6, the line protocol is marked as up.
-
show ipv6 routers: This is an IPv6-specific command (does not have an IPv4 counterpart) you can use to display IPv6 router advertisement (RA) information received from onlink routers.
-
show ipv6 route: This command displays the contents of the IPv6 routing table.
-
show ipv6 protocols: This command displays the parameters and current state of the active IPv6 routing protocol processes. The information displayed by this command proves useful in troubleshooting routing operations.
In addition to the commands, an effective troubleshooting method provides a comprehensive end-to-end approach to identifying symptoms and isolating problems. For example, consider the output of the debug ipv6 nd command, and how helpful it can be in identifying neighbor discovery, duplicate addresses, autoconfiguration, and other conditions. The output of this command is critical not only in understanding the ND process and the role of ICMPv6, but also for identifying and isolating IPv6 failure conditions.
IPv6 Troubleshooting Example: Stateless Autoconfiguration Issue
This example is based on the network diagram shown in Figure 6-10. You are informed that recent changes in the network have rendered router R3 isolated and with no connectivity outside the Fast Ethernet segment connected to R1. You verify this by performing a ping from R3 to a remote destination (24::24:2), and it does not succeed. When you inspect the change log you notice that the changes were aimed at providing automatic IP address assignment and configuration to certain devices. After the change, R3 lost connectivity to the rest of the network. You will apply a troubleshooting method to resolve this problem. This particular scenario follows a bottom-up approach, starting at R3.
In following the bottom-up approach, the first order of business is to determine the status of the interface on R3, and start gathering information. The choice of commands is important because some commands will give you information on multiple layers, an important feature for the more experienced troubleshooter. In this example, you will use the show ipv6 interface command and refer to the Fast Ethernet 0/0 interface. Example 6-23 shows the results. You’ll notice that the interface is up at both Layers 1 and 2. So, you can start eliminating hypotheses here; there seems to be physical connectivity at this point. You also notice that the interface has a global unicast address configured, on network 13::/64, and a link-local address.
Example 6-23: show ipv6 interface fa0/0 Command Output on Router R3
R3# show ipv6 interface f0/0
FastEthernet0/0 is up, line protocol is up
IPv6 is enabled, link-local address is FE80::219:55FF:FEF0:B7D0
Global unicast address(es):
13::13:3, subnet is 13::/64
Joined group address(es):
FF02::1
FF02::2
FF02::1:FF13:3
FF02::1:FFF0:B7D0
MTU is 1500 bytes
ICMP error messages limited to one every 100 milliseconds
ICMP redirects are enabled
ND DAD is enabled, number of DAD attempts: 1
ND reachable time is 30000 milliseconds
ND advertised reachable time is 0 milliseconds
ND advertised retransmit interval is 0 milliseconds
ND router advertisements are sent every 200 seconds
ND router advertisements live for 1800 seconds
Hosts use stateless autoconfig for addresses.
R3#
Addressing does not seem to be a problem, but because you notice the last line specifying Hosts use stateless autoconfig for addresses, it is good to check the configuration of the fa0/0 interface using the show run interface fa 0/0 command. The result is shown in Example 6-24. The interface fa0/0 is configured to automatically obtain prefix and other information.
Example 6-24: The Interface fa0/0 Section of R3’s Running-Config
R3# show run int f0/0
Building configuration...
Current configuration : 111 bytes
!
Interface FastEthernet0/0
no ip address
duplex auto
speed auto
ipv6 address autoconfig
ipv6 enable
end
R3#
Now, looking at R3’s routing table using the show ipv6 route command as demonstrated in the output in Example 6-25, only the connected/local networks are listed.
Example 6-25: IPv6 Routing Table Is Displayed Using the show ipv6 route Command
R3# show ipv6 route
IPv6 Routing Table - 6 entries
Codes: C - Connected, L - Local, S - Static, R - RIP, B - BGP
U - Per-user Static Route
I1 - ISIS L1, I2 - ISIS L2, IA - ISIS interarea, IS - ISIS summary
O - OSPF intra, OI - OSPF inter, OE1 - OSPF ext 1, OE2 - OSPF ext 2
ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2
C 13::/64 [0/0]
via ::, Fast Ethernet0/0
L 13:219:55FF;FEF0:B7D0/128 [0/0]
via ::, FastEthernet0/0
C 103::/64 [0/0]
via ::, Loopback0
L 103::3/128 [0/0]
via ::, Loopback0
L FE80::/10 [0/0]
via ::, Null0
L FF00::/8 [0/0]
via ::, Null0
R3#
At this point, your line of thinking is that R3 has an IP address, but no default route. The router is configured for stateless autoconfiguration on that interface, so it should be obtaining a default router through autoconfiguration. You know that the autoconfiguration process is ruled by ICMPv6 as part of the ND set of features. The best tool to understand this process is the debug ipv6 nd command. Shut down the interface and enable it again to see neighbor discovery. The results are shown in Example 6-26, where you can see that the router solicitation messages go out, but you do not see any replies! It looks as if the autoconfiguration router, which is R1 in the network topology, is misconfigured or unreachable.
Example 6-26: The debug ipv6 nd Results on R3 Show No Respond for Its Solicitation
R3# debug ipv6 nd
ICMP Neighbor Dicovery events debugging is on
R3#
R3#
R3# conf t
Enter configuration commands, one per line. End with CNTL/Z.
R3(config)# int f0/0
R3(config-if)# sh
R3(config-if)# no shu
R3(config-if)#
*Aug 23 21:44:18.491: ICMPv6-ND: Sending Final RA on FastEthernet0/0
*Aug 23 21:44:18.491: ICMPv6-ND: Address FE80::219:55FF:FEF0:B7D0/10 is down on
FastEthernet0/0
*Aug 23 21:44:20.491: %LINK-3-UPDOWN: Interface FastEthernet0/0, changed state to
up
*Aug 23 21:44:20.971: ICMPv6-ND: Sending NS for FE80::219:55FF:FEF0:B7D0 on
FastEthernet0/0
*Aug 23 21:44:21.971: ICMPv6-ND: DAD: FE80::219:55FF:FEF0:B7D0 is unique
*Aug 23 21:44:21.971: ICMPv6-ND: Sending NA for FE80::219:55FF:FEF0:B7D0 on
FastEthernet0/0
*Aug 23 21:44:21.971: ICMPv6-ND: Address FE80::219:55FF:FEF0:B7D0 is up on
FastEthernet0/0
*Aug 23 21:44:23.971: ICMPv6-ND: Sending RS on FastEthernet0/0
*Aug 23 21:44:27.971: ICMPv6-ND: Sending RS on FastEthernet0/0
*Aug 23 21:44:31.971: ICMPv6-ND: Sending RS on FastEthernet0/0
At this point, you would shift your troubleshooting effort to R1 and look at the interface connecting to R3 first. Interfaces must be active and have a valid IPv6 address to advertise prefix and autoconfiguration information using ICMPv6. So, you type show running-config int fa0/0 and verify that the interface is properly configured with theIPv6 address 13::13:1/64. Looking at the status of the interface, using the show ipv6 interface fa0/0 command, you would notice that it is up at both physical and data link layers. Example 6-27 shows the results.
Example 6-27: Checking the Configuration and Status of the fa0/0 Interface on R1
R1#
R1# show running-config interface f0/0
Building configuration...
Current configuration : 112 bytes
!
interface FastEthernet0/0
no ip address
duplex auto
speed auto
ipv6 address 13::13:1/64
ipv6 enable
end
R1#
R1#
R1# show ipv6 interface f0/0
FastEthernet0/0 is up, line protocol is up
IPv6 is enabled, link-local address is FE80::219:56FF:FE2C:9856
Global unicast address(es):
13::13:1, subnet is 13::/64
Joined group address(es):
FF02::1
FF02::2
FF02::1:FF13:1
FF02::1:FF2C:9856
MTU is 1500 bytes
ICMP error messages limited to one every 100 milliseconds
ICMP redirects are enabled
ND DAD is enabled, number of DAD attempts: 1
ND reachable time is 30000 milliseconds
Default router is FE80::219:55F:FEF0:B7D0 on FastEthernet0/0
R1#
You must answer the following questions:
-
What else does R1 need to become a proper autoconfiguration router?
-
How can it be that R3 has a working IPv6 address if the autoconfiguration process is not working?
-
Why is it that R3 cannot access the rest of the network, even with a working IPv6 address and no noticeable physical issues?
On R1, you must verify one of the requirements for autoconfiguration, which is having IPv6 unicast routing explicitly enabled, using the show run | include unicast-routing command. From the resulting output, you learn that you do not have IPv6 unicast-routing enabled on this router. You enable ipv6 unicast-routing on R1, and enter the debug ipv6 nd command to observe the results. See the output shown in Example 6-28. The router advertisements go out and it looks as if the autoconfiguration router is back on track.
Example 6-28: Checking If IPv6 Unicast-Routing Is Enabled on R1
R1# show run | inc unicast-routing
R1#
R1#
R1#
R1#
R1# debug ipv6 nd
ICMP Neighbor Discovery events debugging is on
R1#
R1#
R1# conf t
Enter configuration commands, one per line. End with CNTL/A.
R1(config)# ipv6 unicast-routing
R1(config)# end
R1#
*Aug 23 22:01:45.175: ICMPv6-ND: Sending RA to FF02::1 on FastEthernet0/0
*Aug 23 22:01:45.175: ICMPv6-ND: MTU = 1500
*Aug 23 22:01:45.175: ICMPv6-ND: prefix = 13::/64 onlink autoconfig
*Aug 23 22:01:45.175: ICMPv6-ND: 2592000/604800 (valid/preferred)
R1#
Now you can go back to R3 and see the result of enabling ipv6 unicast-routing on R1. On R3, you turn on ND debug using the debug ipv6 nd command, and shutdown and no shut on the fa0/0 interface. You see messages going out and responses coming in. Example 6-29 shows the results. The debug results illustrate that R3 is receiving the route advertisements and that the address has been configured on fa0/0.
Example 6-29: The debug ipv6 nd Output on R3 Upon Enabling IPv6 Routing on R1
R3# debug ipv6 nd
ICMP Neighbor Dicovery events debugging is on
R3#
R3#
R3# conf t
Enter configuration commands, one per line. End with CNTL/Z.
R3(config)# int f0/0
R3(config-if)# sh
R3(config-if)# no shu
R3(config-if)#
R3(config-if)# end
*Aug 23 21:57:47.547: ICMPv6-ND: Sending Final RA on FastEthernet0/0
*Aug 23 21:57:47.547: ICMPv6-ND: Address 13::219:55FF:FEF0:B7D0/64 is down on
FastEthernet0/0
*Aug 23 21:57:47.547: ICMPv6-ND: Address FE80::219:55FF:FEF0:B7D0/10 is down on
FastEthernet0/0
R3#
*Aug 23 21:57:48.003: %SYS-5-CONFIG_I: Configured from console by console
*Aug 23 21:57:53.279: ICMPv6-ND: Sending NS for FE80::219:55FF:FEF0:B7D0 on
FastEthernet0/0
*Aug 23 21:57:54.279: ICMPv6-ND: DAD: FE80::219:55FF:FEF0:B7D0 is unique
*Aug 23 21:57:54.279: ICMPv6-ND: Sending NA for FE80::219:55FF:FEF0:B7D0 on
FastEthernet0/0
*Aug 23 21:57:56.279: ICMPv6-ND: Sending RS on FastEthernet0/0
*Aug 23 21:57:56.279: ICMPv6-ND: Received RA from FE80::219:56FF:FE2C:9856 on
FastEthernet0/0
*Aug 23 21:57:56.279: ICMPv6-ND: Sending NS for 13::219:55FF:FEF0:B7D0 on
FastEthernet0/0
*Aug 23 21:57:56.279: ICMPv6-ND: Autoconfiguring 13::219:55FF:FEF0:B7D0 on
FastEthernet0/0
*Aug 23 21:57:57.279: ICMPv6-ND: DAD: 13::219:55FF:FEF0:B7D0 is unique
*Aug 23 21:57:57.279: ICMPv6-ND: Sending NA for 13::219:55FF:FEF0:B7D0 on
FastEthernet0/0
*Aug 23 21:57:57.279: ICMPv6-ND: Address 13::219:55FF:FEF0:B7D0 is up on
FastEthernet0/0
Now you can re-examine R3’s IPv6 address on fa0/0 and see what changed as demonstrated in Example 6-30. Notice that R3’s fa0/0 interface previously had a valid IPv6 address (see Example 6-23), but no valid lifetime for the IPv6 address. Now you notice that the valid lifetime and preferred lifetime parameters are present (see Example 6-30).
Example 6-30: show ip ipv6 int fa0/0 Command Output on R3, Upon Enabling IPv6 Routing on R1
R1# sh ipv6 int f0/0
FastEthernet0/0 is up, line protocol is up
IPv6 is enabled, link-local address is FE80::219:55FF:FEF0:B7D0
Global unicast address(es):
13::219:55FF:FEF0:B7D0, subnet is 13::/64 [PRE]
Valid lifetime 2591941 preferred lifetime 604741
Joined group address(es):
FF02::1
FF02::2
FF02::1:FFF0:B7D0
MTU is 1500 bytes
ICMP error messages limited to one every 100 milliseconds
ICMP redirects are enabled
ND DAD is enabled, number of DAD attempts: 1
ND reachable time is 0 milliseconds
ND advertised reachable time is 0 milliseconds
ND advertised retransmit interval is 0 milliseconds
ND router advertisements are sent every 200 seconds
ND router advertisements live for 1800 seconds
Hosts use stateless autoconfig for addresses
R1#
You can conclude why R3 had a valid address: At some point R3 was receiving network information from R1 through ICMPv6, so it obtained the IPv6 address. You need to remember that autoconfiguration addresses remains in effect for a specific valid lifetime, even if the device does not hear from the autoconfiguration router during that span. To ensure R3’s IPv6 connectivity, you ping remote destinations, and as shown in Example 6-31, the ping succeeds.
Example 6-31: Ping Result on R3 After Enabling IPv6 Routing on R1
R3# ping 24::24:2
Type escape sequence to abort
Sending 5, 100-byte ICMP Echos to 24::24:2, timeout is 2 seconds:
!!!!!
Success reate is 100 percent (5/5), round-trip min/avg/max = 0/0/0 ms
R3#
IPv6 Troubleshooting Example: Redistribution Issue
The second troubleshooting example is based on the topology shown in Figure 6-11. R1 and R2 have two connections: one through the 6to4 tunnel, and a main link over a Frame Relay network. There are two RIPng processes running: one between R3 and R1 and then across the tunnel, and the second process running between R4 and R2 and across the Frame Relay virtual circuit. A recent change ticket performed two-way redistribution between the two RIP processes on R2. However, R4 has lost reachability to R3, specifically the loopback interface on R3.
Based on the network topology, one of the methods to provide connectivity between R3 and R4 is to perform redistribution between the two RIPng routing processes. You have been told that redistribution has been configured on R2, but R1 and R2 do not have connectivity. There seem to be a routing problem, so you begin our troubleshooting halfway through the OSI model, at the network layer. You start by looking at the routing table on R4 using the show ipv6 route rip command as demonstrated in Example 6-32. Network 103::/64, which is the loopback of R3, is present in R4’s routing table, but a ping from R4 to R3’s loopback fails.
Example 6-32: show ipv6 route Command Output Displays R3’s Loopback Present in R4’s Routing Table
R4# show ipv6 route
IPv6 Routing Table - 6 entries
Codes: C - Connected, L - Local, S - Static, R - RIP, B - BGP
U - Per-user Static Route
I1 - ISIS L1, I2 - ISIS L2, IA - ISIS interarea, IS - ISIS summary
O - OSPF intra, OI - OSPF inter, OE1 - OSPF ext 1, OE2 - OSPF ext 2
ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2
R 12::/64 [120/2]
via FE80::219:55FF:FE92:A442, Fast Ethernet0/0
R 103:::/64 [120/7]
via FE80::219:55FF:FE92:A442, Fast Ethernet0/0
R4#ping 103::3
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 103::3, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
R4#
The next logical step is to move to the downstream router R2 and check how redistribution was configured there by using the show ipv6 protocols command as demonstrated in Example 6-33.
Example 6-33: Gathering Information About IPv6 Protocol Redistribution on R2
R2# show ipv6 protocols
IPv6 Routing Protocol is "connected"
IPv6 Routing Protocol is "static"
IPv6 Routing Protocol is "rip RIPoFR"
Interfaces:
FastEthernet0/0
Serial0/0/0
Redistribution:
Redistributing protocol rip RIPoTU with metric 5
IPv6 Routing Protocol is "rip RIPoTU"
Interfaces:
Loopback101
Tunnel0
Redistribution:
Redistributing protocol rip RIPoFR with metric 15
R2#
Notice that redistribution on R2 is bidirectional, from RIPoTU to RIPoFR, and vice versa. Technically, R2 should be redistributing RIPoTU into RIPoFR so that it can advertise R3’s Ethernet and loopback network addresses, learned through RIPoTU, to R4 through RIPoFR. Performing redistribution of RIPoFR to RIPoTU is better on R1 so that R3 learns about R4’s Ethernet and loopback network addresses. Regardless, someone decided to do both redistributions on R2. However, different metrics were used in the two redistributions, perhaps to manipulate path selection or to prevent routing loops. When redistributing into RIPoTU, the networks are being injected with the metric of 15 (the maximum metric value in RIPng). Now, using the show ipv6 route command on R1 (see Example 6-34), look at R1’s routing table to see whether R4 networks, specifically the 24::/64 network, are present. As the output reveals, the 24::/64 network is not present in R1’s IPv6 routing table.
Example 6-34: R1’s IPv6 Routing Table Is Missing Networks (For Example, 24::/64)
R1# show ipv6 route
IPv6 Routing Table - 6 entries
Codes: C - Connected, L - Local, S - Static, R - RIP, B - BGP
U - Per-user Static Route
I1 - ISIS L1, I2 - ISIS L2, IA - ISIS interarea, IS - ISIS summary
O - OSPF intra, OI - OSPF inter, OE1 - OSPF ext 1, OE2 - OSPF ext 2
ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2
S ::/0 [1/0]
via ::, Tunnel0
C 12::/64 [0/0]
via ::, Serial0/0/0
L 12::12:1/128 [0/0]
via ::, Serial0/0/0
C 13::/64 [0/0]
via ::, FastEthernet0/0
L 13::13:1/128 [0/0]
via ::, FastEthernet0/0
R 103::/64 {120/2]
via FE80::219:55FF:FEF0:B7D0, FastEthernet0/0
LC 2002:AC10:6501::1/128 [0/0]
Via ::, Tunnel0
L FE80::/10 [0/0]
via ::, Null0
L FF00::/8 [0/0]
via ::, Null0
R1#
Assuming that redistribution on R2 is causing the problem, you fix the redistribution metric on R2 and modify the redistribute command to still have a high metric, such as 10, but not 15, as shown in Example 6-35.
Example 6-35: Correcting the Redistribution Metric in R2 from 15 to 10
R2# conf t
Enter configuration commands, one per line. End with CNTL/Z.
R2(config)# ipv6 router rip RIPoTU
R2(config-rtr)# redistribute rip RIPoFR metric 10
R2(config-rtr)#
R2(config-rtr)# end
R2#
Now, go back to R1, and check its IPv6 routing table again. Strangely, you don’t see the Frame Relay network. R1 is not receiving any routes through the Frame Relay network (the serial interface). You should verify that IPv6 RIP is properly configured in router R1. One of the most useful commands to obtain a complete snapshot of IPv6 RIP in a Cisco router, including the interfaces where the protocol is enabled, is the show ipv6 rip command. You use this command on R1 and see the results shown in Example 6-36.
Example 6-36: The result of the show ipv6 rip Command on R1
R1# show ipv6 rip
RIP process "RIPoTU", port 521, multicast-grop FF02::9, pid 178
Administrative distance is 120. Maximum paths is 16
Updates every 30 seconds, expire after 180
Holddown lasts 0 seconds, garbage collection after 120
Split horizon is on; poison reverse is off
Default routes are not generated
Periodic updates 201, trigger updates 13
Interfaces:
Tunnel0
FastEthernet0/0
Redistribution:
None
RIP process "RIPoFR", port 521, multicast-grop FF02::9, pid 179
Administrative distance is 120. Maximum paths is 16
Updates every 30 seconds, expire after 180
Holddown lasts 0 seconds, garbage collection after 120
Split horizon is on; poison reverse is off
Default routes are not generated
Periodic updates 197, trigger updates 6
Interfaces:
None
Redistribution:
Redistributing protocol rip RIPoTU with metric 5
R1#
The RIPoFR process has no interfaces enabled and that is one reason R1 is not receiving routes through the Frame Relay link. On R1, you enable the RIPoFR process on the serial interface, and observe the results (shown in Example 6-37) using the debug ipv6 routing command.
Example 6-37: The debug ipv6 routing Results on R1 After Enabling RIPoFR on S0/0/0
R1#
R1# debug ipv6 routing
IPv6 routing table events debugging is on
R1#
R1#
R1#
R1#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R1(config)# int s0/0/0
R1(config-if)# ipv6 rip RIPoFR enable
R1(config-if)#
R1(config-if)# end
R1#
R1#
*Aug 24 00:42:47.250: IPv6RTO: Event: 11::/64, Mod, owner connected, previous None
*Aug 24 00:42:47.250: IPv6RTO: Event: 12::/64, Mod, owner connected, previous None
*Aug 24 00:42:47.538: %SYS-5-CONFIG_I: Configured from console by console
*Aug 24 00:42:49.206: IPv6RTO: rip RIPoFR, Route add 24::/64 [new]
*Aug 24 00:42:49.206: IPv6RTO: rip RIPoFR, Add 24::/64 to table
*Aug 24 00:42:49.206: IPv6RTO: rip RIPoFR, Adding next-hop
FE80::219::55FF:FE92:A442 over Serial 0/0/0 for 24::/64, [120/2]
*Aug 24 00:42:49.206: IPv6RTO: rip RIPoFR, Added backup for 12::/64, distance 120
*Aug 24 00:42:49.206: IPv6RTO: rip RIPoFR, Added backup for 11::/64, distance 120
*Aug 24 00:42:49.206: IPv6RTO: Event: 24::/64, Add, owner rip, previous None
The debug output shows the missing routes being added to the routing table. You now use the show ipv6 route command on R1 and see that the routes through the Frame Relay network are present. R1’s new routing table is shown in Example 6-38. Note that the paths through Frame Relay are preferred because of the lower metric.
Example 6-38: R1’ IPv6 Routing Table, After Enabling RIPoFR on Its Serial Interface
R4# show ipv6 route
IPv6 Routing Table - 17 entries
Codes: C - Connected, L - Local, S - Static, R - RIP, B - BGP
U - Per-user Static Route
I1 - ISIS L1, I2 - ISIS L2, IA - ISIS interarea, IS - ISIS summary
O - OSPF intra, OI - OSPF inter, OE1 - OSPF ext 1, OE2 - OSPF ext 2
ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2
S ::/0 [1/0]
via ::, Tunnel0
C 11::/64 [0/0]
via ::, Serial0/0/0
L 11::11:1/128 [0/0]
via ::, Serial0/0/0
C 12::/64 [0/0]
via ::, Serial0/0/0
L 12::12:1/128 [0/0]
via ::, Serial0/0/0
C 13::/64 [0/0]
via ::, FastEthernet0/0
L 13::13:1/128 [0/0]
via ::, FastEthernet0/0
R 24::/64 [120/2]
via FE80::219:55FF:FE92:A442, Serial0/0/0
R 103::/64 [120/2]
via FE80::219:55FF:FEF0:B7D0, FastEthernet0/0
C 2001:AC10:6501::/64 [0/0]
via ::, Tunnel0
L 2001:AC10:6501::1/128 [0/0]
via ::, Tunnel0
R 2001:AC10:6601::/64 [120/2]
via FE80::219:55FF:FE92:A442, Serial0/0/0
S 2002::/16 [1/0]
via Tunnel0
LC 2002:AC10:6501::1/128 [0/0]
via ::, Tunnel0
R 2002:AC10:6601::2/128 [120/2]
via FE80::219:55FF:FE92:A442, Serial0/0/0
L FE80::/10 [0/0]
via ::, Null0
L FF00::/8 [0/0]
via ::, Null0
R1#
Now it is best to go to R3 and see whether it is receiving R4’s Ethernet network address (24::/64) from R1. You could use the show ipv6 route command, but you can use this opportunity to use the helpful debug ipv6 packet command. This command is dangerous, however, because it can cause the router to crash due to the amount of output that it generates and displays on the console. So, you should filter the output with an access list called FILTER, which will display only packets with the destination address matching 24::/64. Example 6-39 shows the FILTER access list as entered with the show ipv6 access-list command. Now, use the debug ipv6 packet access-list FILTER command on R3 and try to ping R2. The debug output shown in Example 6-39, among other messages, displays Route not found for the packet destined to 24::24:2 (R2’s fa0/0 address). This means that R3 still doesn’t have a valid path to R2 (indeed, to the Fast Ethernet link between R2 and R4).
Example 6-39: debug IPv6 packet Command Output on R3
R3# sh ipv6 access-list
IPv6 access list FILTER
Permit ipv6 any 24::/64 (5 matches) sequence 10
R3#
R3# debug ipv6 packet access-list FILTER
IPv6 packet debuggin in on for access list FILTER
R3#
*Aug 24 11:25:11.748 IPv6: Sending on Loopback103
*Aug 24 11:25:11.748 IPv6: Sending on FastEthernet0/0
*Aug 24 11:25:39.812: IPv6: Sending on Loopback103
*Aug 24 11:25:39.812: IPv6: Sending on FastEthernet0/0
R3# ping 24::24:2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 24::24:2, timeout is 2 seconds
*Aug 24 11:25:51.332: IPv6: SAS picked source 13::13:3 for 24::24:2
*Aug 24 11:25:51.332: IPv6: source 13::13:3 (local)
*Aug 24 11:25:51.332: dest 24::24:2
*Aug 24 11:25:51.332: traffic class 0, flow 0x0, len 100+0, prot 58, hops
64, Route not found
You know that R1 had a route to R4’s Ethernet address (24::/64). You also know that R2 is redistributing the Frame Relay routes into RIPoTU and sending them to R1. R1 receives R4’s Ethernet address (24::/64) through RIPoFR and RIPoTU, but it ignores the latter because of its large metric. You need to make sure R1 advertises R4’s Ethernet address to R3, so you need to return to R1 and fix that. One way to fix this problem is to redistribute RIPoFR into RIPoTU on R1 so that R1 advertises R4’s Ethernet to R3. First you should check what redistributions, if any, are done on R1, using the show ipv6 protocols command, as demonstrated in Example 6-40.
Example 6-40: Checking Redistribution on R1 Using the show ipv6 protocols Command
R1# show ipv6 prot
IPv6 Routing Protocol is "connected"
IPv6 Routing Protocol is "static"
IPv6 Routing Protocol is "rip RIPoTU"
Interfaces:
Tunnel0
FastEthernet0/0
Redistribution:
None
IPv6 Routing Protocol is "rip RIPoFR"
Interfaces:
Serial0/0/0
Redistribution:
Redistributing protocol rip RIPoTU with metric 5
R1#
As you can see in the output of Example 6-40, R1 is redistributing RIPoTU into RIPoFR, which is not really necessary here. On the other hand, R1 is not redistributing RIPoFR into RIPoTU, which is necessary, because you want R4’s Ethernet address to be advertised to R3. Fixing this is easy. On R1, you go into the RIPoTU process using the ipv6 router rip RIPoTU command and perform redistribution using the redistribute rip RIPoFR include-connected command, as shown in Example 6-41. Next, to see the outcome, you would go to R3 and ping R4. The ping result is 100 percent success, as you can see in Example 6-41. Next, check to make sure that R4 can now ping R3, too, and that is also successful.
Example 6-41: After Redistributing RIPoFR into RIPoTU, R3 Has an IPv6 Path to R4
R1# conf t
Enter configuration commands, one per line. End with CNTL/Z.
R1(config)#
R1(config)# ipv6 router rip RIPoTU
R1(config-rtr)# redistribute rip RIPoFR include-connected metric 5
R1(config-rtr)#
R1(config)#
R3# ping 24::24:4
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 24::24:2, timeout is 2 seconds
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 0/0/4 ms
The problem is solved, and it required a lot of effort. There were two main causes:
-
On R1, IPv6 RIP was not active on its Frame Relay interface.
-
On R1, the RIPoFR process was not redistributed into the RIPoTU process.
IPv6 Troubleshooting Example: OSPFv3 Configuration Errors
The third IPv6 troubleshooting example is based on the network diagram shown in Figure 6-12. In this case, you have OSPFv3 running throughout the network, with the backbone area 0 (including routers R1 and R2), running over the Frame Relay network, and stub area 1 (including R1 and R3) and stub area 2 (including R2 and R4) over Fast Ethernet networks on the far ends of the diagram. It has been reported that a recent power outage might have caused some of the routers to restart. The network administrators are not completely certain that configurations were properly saved before the incident. End-to-end connectivity has been lost in this network ever since.
The best way to start is to perform some testing. You should try to verify that the symptoms were well documented and true. Also, you should try to identify the scope of the problem. Loss of end-to-end connectivity could have several meanings in different contexts. So you start with a ping in the stub routers of each area, to verify interarea connectivity. From R4, you ping the loopback on R3, and the ping fails; then you try it from R2, and the ping fails again. These results are shown in Example 6-42. Next, you ping from R1 and it fails again! Good troubleshooting practices call for pinging more than one address (or interface), in case one is down but the others are not. Therefore, you ping from R1 to R3’s fa0/0 interface, which is directly connected to R1, and this one fortunately succeeds, but the same test from R2 does not.
Example 6-42: Initial Ping Tests from R4 and R2 to R3’s Loopback Interface Fail
R4# ping 103::3
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 103::3, timeout is 2 seconds:
..
R2# ping 103::3
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 103::3, timeout is 2 seconds:
..
R1# ping 103::3
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 103::3, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
R1# ping 13::13:3
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 13::13:3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 0/0/0 ms
R1#
R2# ping 103::3
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 103::3, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
R2# ping 13::13:3
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 13::13:3, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
R2#
You can fix the problems by starting on R1 and moving your way to the right. This is sometimes a good approach because it helps to isolate problems in specific sections of the network and helps to incrementally build connectivity. As you move to the right fixing problems, devices on those sections of the network can function normally and users can do their work. Starting at R1, you can actually use a bottom-up approach in that specific router. It is helpful to use a command that shows us multiple layers, so that you can see the status of physical, data link, and network layers. The show ipv6 ospf interface command shows the status of Layers 1 and 2, and also OSPF information, as demonstrated in Example 6-43. Notice how in R1 you can see that the Frame Relay interface (serial 0/0/0) is a nonbroadcast interface. You can also verify the proper area configuration on each interface, backbone for the Frame Relay interface, and area 1 for the LAN interface. On both interfaces of R1, the OSPF neighbor count is 0. This is also verified using the show ipv6 ospf neighbor command (see the bottom of Example 6-43).
Example 6-43: show ipv6 ospf interface Is a Valuable Information-Gathering Command
R1# show ipv6 ospf interface
Serial0/0/0 is up, line protocol is up
Link Local Address FE80::219:56FF:FE2C:9856, Interface ID 5
Area 0, Process ID 1, Instance ID 0, Router ID 172.16.101.1
Network Type POINT_TO_POINT, Cost: 64
Transmit Delay is 1 sec, State POINT_TO_POINT
Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
Hello due in 00:00:01
Index 1/1/2, flood queue length 0
Next 0x0(0)/0x0(0)/0x0(0)
Last flood scan length is 1, maximum is 2
Last flood scan time is 0 msec, maximum is 0 msec
Neighbor Count is 0, Adjacent neighbor count is 0
Suppress hello for 0 neighbor(s)
FastEthernet0/0 is up, line protocol is up
Link Local Address FE80::219:56FF:FE2C:9856, Interface ID 3
Area 1, Process ID 1, Instance ID 0, Router ID 172.16.101.1
Network Type BROADCAST, Cost: 1
Transmit Delay is 1 sec, State DR, Priority 1
Designated Router (ID) 172.16.101.1, local address FE80::219:56FF:FE2C:9856
No backup designated router on this network
Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
Hello due in 00:00:01
Index 1/1/1, flood queue length 0
Next 0x0(0)/0x0(0)/0x0(0)
Last flood scan length is 0, maximum is 0
Last flood scan time is 0 msec, maximum is 0 msec
Neighbor Count is 0, Adjacent neighbor count is 0
Suppress hello for 0 neighbor(s)
R1#
R1# show ipv6 ospf neighbor
R1#
Now you would use the debug ipv6 ospf hello command to see any potential mismatches, as demonstrated in Example 6-44. On LAN interfaces, Hello messages occur every 10 seconds.
Example 6-44: debug ipv6 ospf hello Shows Mismatched Stub/Transit Area
R1# debug ipv6 ospf hello
OSPFv3 hello events debugging is on
R1#
R1#
*Aug 24 13:19:49.751: OSPFv3: Rcv hello from 103.103.103.103 area 1 from
FastEthernet0/0 FE80::219:55FF:FEF0:B7D0 interface ID 3
*Aug 24 13:19:49.751: OSPFv3: Hello from FE80::219:55FF:FEF0:B7D0 with mismatched
Stub/Transit area option bit
*Aug 24 13:19:56.087: OSPFv3: Send hello to FF02::5 area 1 on FastEthernet0/0 from
FE80::219:56FF:FE2C:9856 interface ID 3
*Aug 24 13:19:59.751: OSPFv3: Rcv hello from 103.103.103.103 area 1 from
FastEthernet0/0 FE80::219:55FF:FEF0:B7D0 interface ID 3
*Aug 24 13:19:59.751: OSPFv3: Hello from FE80::219:55FF:FEF0:B7D0 with mismatched
Stub/Transit area option bit
The mismatched Stub/Transit area option bit that the debug output shows indicates that either R1 is calling the area a stub and R3 does not, or R3 is calling the area a stub and R1 does not. The best way to see the area configuration is to use the show ipv6 ospf command. The result, shown in Example 6-45, indicates that on R1 area 1 is configured as a totally stubby area (it is a stub area, no summary LSA in this area); however, the same command on R3 shows area 1 as a normal area. That needs to be fixed. Note that no Hellos to/from the serial 0/0/0 interface can be seen in the output shown in Example 6-44. This is addressed later.
Example 6-45: show ipv6 ospf Command Output on R1 Indicates Area 1 Is Totally Stubby
R1# show ipv6 ospf
Routing Process "ospfv3 1" with ID 172.16.101.1
It is an area border router
SPF schedule delay 5 secs, Hold time between two SPFs 10 secs
Minimum LSA interval 5 secs. Minimum LSA arrival 1 secs
LSA group pacing timer 240 secs
Interface flood pacing timer 33 msecs
Retransmission pacing timer 66 msecs
Number of external LSA 0. Checksum Sum 0x000000
Number of areas in this router is 2. 1 normal 1 stub 0 nssa
Reference bandwidth unit is 100 mbps
Area BACKBONE(0) (Inactive)
Number of interfaces in this area is 1
SPF algorithm executed 3 times
Number of LSA 4. Checksum Sum 0x01F36B
Number of DCbitless LSA 0
Number of indication LSA 0
Number of DoNotAge LSA 0
Flood list length 0
Area 1
Number of interfaces in this area is 1
It is a stub area, no summary LSA in this area
Generates stub default route with cost 1
SPF algorithm executed 5 times
Number of LSA 4. Checksum Sum 0x016293
Number of DCbitless LSA 0
Number of indication LSA 0
Number of DoNotAge LSA 0
Flood list length 0
R3# show ipv6 ospf
Routing Process "ospfv3 1" with ID 103.103.103.103
SPF schedule delay 5 secs, Hold time between two SPFs 10 secs
Minimum LSA interval 5 secs. Minimum LSA arrival 1 secs
LSA group pacing timer 240 secs
Interface flood pacing timer 33 msecs
Retransmission pacing timer 66 msecs
Number of external LSA 0. Checksum Sum 0x000000
Number of areas in this router is 1. 1 normal 0 stub 0 nssa
Reference bandwidth unit is 100 mbps
Area 1
Number of interfaces in this area is 1
SPF algorithm executed 1 times
Number of LSA 3. Checksum Sum 0x02286D
Number of DCbitless LSA 0
Number of indication LSA 0
Number of DoNotAge LSA 0
Flood list length 0
R3#
You go into the OSPF routing process with the ipv6 router ospf 1 command and enter the area 1 stub command on router R3. Shown in Example 6-46, the adjacency forms almost immediately when the parameter mismatch is gone. Next, you ping R3’s loopback address from R1, and it is successful.
Example 6-46: Once Area 1 Is Configured as Stub on R3, the Adjacency with R1 Forms
R3#
R3# conf t
Enter configuration commands, one per line. End with CNTL/Z.
R3(config)#
R3(config)#
R3(config)# ipv6 router ospf 1
R3(config-rtr)#
R3(config-rtr)# area 1 stub
R3(config-rtr)# end
R3#
R3#
R3#
Sep 27 20:17:38.367: %SYS-5-CONFIG_I: Configured from console by console
Sep 27 20:17:38.747: %OSPFv3-5-ADJCHG: Process 1, Nbr 172.16.101.1 on
FastEthernet0/0 from LOADING to FULL. Loading Done
R1# ping 103::3
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 103::3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 0/0/0 ms
R1#
Now focus on the area 0 backbone over the Frame Relay network, because you are still not seeing Hello messages received on that link. Starting with R1, you check to see the mapping between IPv6 addresses and data-link connection identifiers (DLCIs) using the show frame-relay map command (see Example 6-47). The global unicast addresses are there, mapped to a DLCI. But that is not what OSPFv3 uses to send Hello messages. Routing protocols use the link-local address to send routing information to neighbors. The link-local addresses do not have a mapping to DLCIs, so the Hellos are not going across the nonbroadcast multiaccess (NBMA) network. On R2, you would use the show ipv6 interface brief command to obtain its link-local address. It starts with FE80, as usual. Copy this address to the Clipboard, go to the serial interface of R1, and use the frame-relay map ipv6 command, followed by the link-local address, followed by the DLCI number. You must use the broadcast keyword if you want routing protocols to operate by exchanging multicast packets. You need to do the same on R2; first, copy the link-local address of R1, and on R2 issue the frame-relay map ipv6 command with that address. You can see the OSPF adjacencies starting to pop up into full state. This work is shown on Example 6-47. Now ping R3 from R2, and as you can see, the ping is successful.
Example 6-47: Adding the Frame Relay Maps on R2 and R1 for Link-Local Addresses
R1# show frame-relay map
Serial0/0/0 (up): ipv6 12::12:2 dlci 122(0x7A, 0x1CA0), static
broadcast
CISCO, status defined, active
R1#
——————————————————————————————————————————————————————————————————————————————
R2# show ipv6 interface brief
FastEthernet0/0 [up/up]
FE80::219:55FF:FE92:A442
24::24:2
Serial0/0/0 [up/up]
FE80::219:55FF:FE92:A442
11::1:2
12::12:2
Loopback101 [up/up]
FE80::219:55FF:FE92:A442
R2#
——————————————————————————————————————————————————————————————————————————————
R1# conf t
Enter configuration commands, one per line. End with CNTL/Z
R1(config)# int s0/0/0
R1(config-if)# fram map ipv6 FE80::219:55FF:FE92:A442 122 broadcast
R1(config-if)# end
R1# show ipv6 interface brief
FastEthernet0/0 [up/up]
FE80::219:56FF:FE2C:9856
13::13:1
Serial0/0/0 [up/up]
FE80::219:56FF:FE2C:9856
11::1:1
12::12:1
Loopback101 [up/up]
FE80::219:56FF:FE2C:9856
R1#
——————————————————————————————————————————————————————————————————————————————
R2#
R2# conf t
Enter configuration commands, one per line. End with CNTL/A.
R2(config)# int s0/0/0
R2(config-if)# fram map ipv6 FE80::219:56FF:Fe2C:9856 221 br
R2(config-if)# end
R2#
*Aug 24 13:55:00.459: %SYS-5-CONFIG_I: Configured from console by console
*Aug 24 13:56:59.175: %OSPFv3-5-ADJCHG: Process 1, Nbr 172.16.101.1 on Serial0/0/0
from LOADING to FULL, Loading Done
R2#
R2# ping13::13:3
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 13::13:3, timeout is 2 seconds:
!!!!!
Now you need to fix the problem at the R2-to-R4 segment. You must first determine whether OSPF is configured on the interfaces with the show ipv6 ospf interface command. The results for both R2 and R4 are shown in Example 6-48. On R2, OSPFv3 is enabled on the fa0/0 interface in area 2, but R4, which also has OSPFv3 enabled on its fa0/0 interface, has it in area 0. This is an error. In OSPF, interfaces drop all OSPFv3 packets that do not have a matching OSPFv3 area ID in the packet header.
Example 6-48: Checking OSPFv3 Interfaces on R2 and R4
R2# show ipv6 ospf interface
FastEthernet0/0 is up, line protocol is up
Link Local Address FE80::219:55FF:FE92:A442, Interface ID 3
Area 2, Process ID 1, Instance ID 0, Router ID 172.16.102.1
Network Type BROADCAST, Cost: 1
Transmit Delay is 1 sec, State DR, Priority 1
Designated Router (ID) 172.16.102.1, local address FE80::219:55FF:FE92:A442
No backup designated router on this network
Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
Hello due in 00:00:04
Index 1/1/2, flood queue length 0
Next 0x0(0)/0x0(0)/0x0(0)
Last flood scan length is 0, maximum is 0
Last flood scan time is 0 msec, maximum is 0 msec
Neighbor Count is 0, Adjacent neighbor count is 0
Suppress hello for 0 neighbor(s)
Serial0/0/0 is up, line protocol is up
Link Local Address FE80::219:55FF:FE92:A442, Interface ID 6
Area 0, Process ID 1, Instance ID 0, Router ID 172.16.102.1
Network Type POINT_TO_POINT, Cost: 64
Transmit Delay is 1 sec, State POINT_TO_POINT
Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
Hello due in 00:00:01
Index 1/1/1, flood queue length 0
Next 0x0(0)/0x0(0)/0x0(0)
Last flood scan length is 1, maximum is 2
Last flood scan time is 0 msec, maximum is 0 msec
Neighbor Count is 1, Adjacent neighbor count is 1
Adjacent with neighbor 172.16.101.1
Suppress hello for 0 neighbor(s)
——————————————————————————————————————————————————————————————————————————————
R4# show ipv6 ospf interface
FastEthernet0/0 is up, line protocol is up
Link Local Address FE80::219:55FF:FEE0:F04, Interface ID 3
Area 0, Process ID 1, Instance ID 0, Router ID 104.104.104.104
Network Type BROADCAST, Cost: 1
Transmit Delay is 1 sec, State WAITING, Priority 1
No designated router on this network
No backup designated router on this network
Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
Hello due in 00:00:03
Wait time before Designated router selection 00:00:13
Index 1/1/1, flood queue length 0
Next 0x0(0)/0x0(0)/0x0(0)
Last flood scan length is 0, maximum is 0
Last flood scan time is 0 msec, maximum is 0 msec
Neighbor Count is 0, Adjacent neighbor count is 0
Suppress hello for 0 neighbor(s)
R4#
The next step is to fix the area number on R4 and test end-to-end connectivity by pinging R3’s looback interface from R4 once again. As seen in Example 6-49, after the correction was made, the ping is successful. This example demonstrates how a divide-and-conquer approach can prove helpful: Isolate problems in sections of the network along the troubleshooting path, starting at a point that is close to your estimated point of failure. Then, work your way backward, trying to fix the specific issues in each section. This will help you not only to focus on isolated problems, but also to make the network operational section by section, incrementally.
Example 6-49: Incorrect Area Number on R4 Is Fixed, and Connectivity Is Restored
R4# conf t
Enter configuration commands, one per line. End with CNTRL/Z.
R4(config)# int f0/0
R4(config-if)# ipv6 ospf 1 area 2
R4(config-if)# end
R4#
R4# ping 13::13:3
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 13::13:3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 56/58/60 ms
R4#
IPv6 Troubleshooting Example: OSPFv3 over 6to4 Tunnel
The fourth and final IPv6 troubleshooting example is based on the diagram shown in Figure 6-13. Two islands of RIPng are connected through an OSPFv3 domain across the 6to4 tunnel. After a readdressing exercise, some traffic cannot traverse the tunnel.
In the topology diagram you can see that routers R1 and R2 are edge/border routers and they are also the tunnel endpoints; you start troubleshooting on these routers. A useful command for this scenario is debug tunnel. Example 6-50 shows the debug output on R1 as you ping R2 (2002:AC10:6601::2), the other side of the tunnel. You can see the ping command succeeds, and the debug output shows the encapsulation and decapsulation messages.
Example 6-50: Ping R2 from R1 Is Successful and the Results from the debug tunnel Command
R1#
R1# ping 2002:AC10:6601::2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2002:AC10:6601::2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 32/33/36 ms
R1#
*Aug 24 14:39:52.863: Tunnel 0: count tx, adding 20 encap bytes
*Aug 24 14:39:52.895: Tunnel 0: IPv6/IP to classify 172.16.102.1 -> 172.16.101.1
(tbl=0, "default" len=120 ttl=254 tos=0x0)
*Aug 24 14:39:52.895: Tunnel 0: IPv6/IP (PS) to decaps 172.16.102.1 ->
172.16.101.1 (tbl=0, "default" len=120 ttl=254)
*Aug 24 14:39:52.895: Tunnel 0: decapsulated IPv6/IP packet (len 120)
*Aug 24 14:39:52.895: Tunnel 0 count tx, adding 20 encap bytes
*Aug 24 14:39:52.931: Tunnel 0: IPv6/IP to classify 172.16.102.1 -> 172.16.101.1
(tbl=0, "default" len=120 ttl=254 tos=0x0)
*Aug 24 14:39:52.931: Tunnel 0: IPv6/IP (PS) to decaps 172.16.102.1 ->
172.16.101.1 (tbl=0, "default" len=120 ttl=254)
*Aug 24 14:39:52.931: Tunnel 0: decapsulated IPv6/IP packet (len 120)
*Aug 24 14:39:52.931: Tunnel 0 count tx, adding 20 encap bytes
*Aug 24 14:39:52.963: Tunnel 0: IPv6/IP to classify 172.16.102.1 -> 172.16.101.1
(tbl=0, "default" len=120 ttl=254 tos=0x0)
*Aug 24 14:39:52.967: Tunnel 0: IPv6/IP (PS) to decaps 172.16.102.1 ->
172.16.101.1 (tbl=0, "default" len=120 ttl=254)
*Aug 24 14:39:52.967: Tunnel 0: decapsulated IPv6/IP packet (len 120)
*Aug 24 14:39:52.967: Tunnel 0 count tx, adding 20 encap bytes
*Aug 24 14:39:52.999: Tunnel 0: IPv6/IP to classify 172.16.102.1 -> 172.16.101.1
(tbl=0, "default" len=120 ttl=254 tos=0x0)
*Aug 24 14:39:52.999: Tunnel 0: IPv6/IP (PS) to decaps 172.16.102.1 ->
172.16.101.1 (tbl=0, "default" len=120 ttl=254)
*Aug 24 14:39:52.999: Tunnel 0: decapsulated IPv6/IP packet (len 120)
*Aug 24 14:39:52.003: Tunnel 0 count tx, adding 20 encap bytes
*Aug 24 14:39:53.035: Tunnel 0: IPv6/IP to classify 172.16.102.1 -> 172.16.101.1
(tbl=0, "default" len=120 ttl=254 tos=0x0)
*Aug 24 14:39:53.035: Tunnel 0: IPv6/IP (PS) to decaps 172.16.102.1 ->
172.16.101.1 (tbl=0, "default" len=120 ttl=254)
*Aug 24 14:39:53.035: Tunnel 0: decapsulated IPv6/IP packet (len 120)
*Aug 24 14:39:54.899: Tunnel 0 count tx, adding 20 encap bytes
However, R1 cannot ping beyond R2. For example, from R1 a ping to 24::24:4, which is R4’s fa0/0 IPv6 address, fails, as shown in Example 6-51.
Example 6-51: R1 Cannot Ping R4’s fa0/0 IPv6 Address 24::24:2
R1# ping 24::24:4
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 24::24:4, timeout is 2 seconds:
*Aug 24 14:41:12.927: Tunnel0 count tx, adding 20 encap bytes.
*Aug 24 14:41:14.899: Tunnel0 count tx, adding 20 encap bytes.
*Aug 24 14:41:14.927: Tunnel0 count tx, adding 20 encap bytes.
*Aug 24 14:41:16.927: Tunnel0 count tx, adding 20 encap bytes.
*Aug 24 14:41:18.927: Tunnel0 count tx, adding 20 encap bytes.
*Aug 24 14:41:20.927: Tunnel0 count tx, adding 20 encap bytes.
Success rate is 0 percent
Using the show ipv6 route command, you display R1’s IPv6 routing table, as shown in Example 6-52. Network 24::/64 is not present in R1’s IPv6 routing table, but there is a static route for 2002:AC10:6610::1 pointing to tunnel0 interface and a default route (gateway of last resort) also pointing to the tunnel0 interface. You have to examine validity of the static route for the 6to4 tunnel. You also have to find out why a static default was configured on R1, rather than just using OSPF.
Example 6-52: R1’s IPv6 Routing Table Shows Only Connected and Static Routes
R1# show ipv6 route
IPv6 Routing Table - 17 entries
Codes: C - Connected, L - Local, S - Static, R - RIP, B - BGP
U - Per-user Static Route
I1 - ISIS L1, I2 - ISIS L2, IA - ISIS interarea, IS - ISIS summary
O - OSPF intra, OI - OSPF inter, OE1 - OSPF ext 1, OE2 - OSPF ext 2
ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2
S ::/0 [1/0]
via ::, Tunnel0
C 11::/64 [0/0]
via ::, Serial0/0/0
L 11::11:1/128 [0/0]
via ::, Serial0/0/0
C 12::/64 [0/0]
via ::, Serial0/0/0
L 12::12:1/128 [0/0]
via ::, Serial0/0/0
C 13::/64 [0/0]
via ::, FastEthernet0/0
L 13::13:1/128 [0/0]
via ::, FastEthernet0/0
LC 2002:AC10:6501::1/128 [1/0]
via ::, Tunnel0
S 2002:AC10:6610::1/128 [1/0]
via Tunnel0
L FE80::/10 [0/0]
via ::, Null0
L FF00::/8 [0/0]
via ::, Null0
R1#
You need to refresh your understanding of 6to4 tunnels. For traffic to go through the tunnel, there must be a valid mapping between the IPv6 destination and the IPv4 next-hop address. In fact, that IPv4 next hop must be embedded in the IPv6 address. You know that someone has changed the addressing scheme recently. It seems that some changes were not made or mistakes have happened. Looking at that static entry a bit more closely, you know that it must point to the IPv6 address of the tunnel endpoint as the next hop, but it does not. The mapping is incorrect, and the packets are not forwarded through the tunnel. You need to change the static entry. On R1, you remove the static entry with the no ipv6 route command, and insert a new entry pointing to the correct IPv6 address, the address of the other side of the tunnel. But the ping to R2’s fa0/0 IPv6 address fails again. This work is shown in Example 6-53.
Example 6-53: The Invalid IPv6 Static Route for the 6to4 Tunnel Is Corrected
R1# conf 6
Enter configuration commands, one per line. End with CNTL/Z.
R1(config)#
R1(config)# no ipv6 route 2002:AC10:6610::1/128 tun0
R1(config)#
R1(config)#
R1(config)# ipv6 route 2002:AC10:6601::2/128 tun0
R1(config)#
R1(config)# end
R1#
R1# ping 24::24:4
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 24::24:24, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
R1#
You must check whether OSPF is working properly on R1. The show ipv6 protocols command shows OSPFv3 is active on the tunnel interface (see Example 6-54), but the show ipv6 neighbor command shows no neighbors. Using the debug ipv6 ospf hello shows that R1 is sending Hellos on the tunnel interface (also shown in Example 6-54), but it is not receiving Hello messages. Using debug ipv6 ospf hello on R2 shows that it is sending Hello messages. However, R2 is using its link-local address as the source. Two things are significant here: First, remember that OSPF uses the link-local addresses to exchange Hello packets and establish adjacencies; and furthermore, Hello messages are sent to multicast addresses. Second, those link-local addresses and multicasts do not comply with the rules of a 6to4 tunnel. 6to4 tunnels do not forward multicast messages that OSPF uses to establish adjacencies: There is no IPv4 address embedded in them to serve as a tunnel destination for automatic tunnel establishment.
Example 6-54: Checking OSPFv3 Configuration on R1
R1# show ipv6 prot
IPv6 Routing Protocol is "connected"
IPv6 Routing Protocol is "static"
IPv6 Routing Protocol is "rip RIPoTU"
Interfaces:
FastEthernet0/0
Redistribution:
None
IPv6 Routing Protocol is "ospf 1"
Interfaces (Area 0):
Tunnel0
Redistribution:
None
R1#
R1#show ipv6 os nei
R1#
R1# debug ipv6 os hello
OSPFv3 hello events debugging is on
R1#
R1#
R1#
*Aug 24 14:59:53.247: OSPFv3: Send hello to FF02::5 area 0 on Tunnel0 from
FE80::AC10:6501 interface ID 13
————————————————————————————————————————
R2# debug ipv6 os hello
OSPFv3 hello events debugging is on
R2#
*Aug 24 15:07:04.635: OSPFv3: Send hello to FE80::219:56FF:FE2C:9856 area 0 on
Serial0/0/0 from FE80::219:55FF:FE92:A442 interface ID 5
*Aug 24 15:07:04.755: OSPFv3: Send hello to FE80::219:56FF:FE2C:9856 area 0 on
Serial0/0/0 from FE80::219:55FF:FE92:A442 interface ID 5
*Aug 24 15:07:04.875: OSPFv3: Send hello to FE80::219:56FF:FE2C:9856 area 0 on
Serial0/0/0 from FE80::219:55FF:FE92:A442 interface ID 5
*Aug 24 15:07:04.995: OSPFv3: send hello to FF02::5 area 0 on Tunnel0 from
FE80::AC10:6601 interface ID 13
*Aug 24 15:07:04.995: OSPFv3: Send hello to FE80::219:56FF:FE2C:9856 area 0 on
Serial0/0/0 from FE80::219:55FF:FE92:A442 interface ID 5
*Aug 24 15:07:05.115: OSPFv3: Send hello to FE80::219:56FF:FE2C:9856 area 0 on
Serial0/0/0 from FE80::219:55FF:FE92:A442 interface ID 5
This means that perhaps this network is poorly designed because OSPF (or other traditional IGPs, for that matter) cannot exchange routes across the 6to4 tunnel; however, OSPF allows explicit neighbor configuration using the neighbor command, which causes communication between neighbors to become unicast based. The unicast address could be the IPv6 address at the other end of the tunnel. This address complies with 6to4 tunnels, and therefore the Hello messages should flow through. Unfortunately, when you go into interface configuration mode for the tunnel interface, and try to specify the other end of the tunnel as a neighbor, you receive an error message (see Example 6-55). The neighbor command is allowed only on NMBA and point-to-multipoint networks.
Example 6-55: The OSPF neighbor Command Is Not Allowed on the Tunnel Interface
R1# conf t
Enter configuration commands, one per line. End with CNTL/Z.
R1(config)# int tun 0
R1(config-if)# ipv6 os neigh FE80::AC10:6601
R1(config-if)# end
R1#
R1#
*Aug 24 15:19:16.219: %OSPFv3-4-CFG_NBR_INVAL_NET_TYPE: Can not use configured
neighbor: neighbor command is allowed only on NBMA and point-to-multipoint networks
*Aug 24 15:19:16.343: %SYS-5-CONFIG_I: Configured from console by console
If using a dynamic routing protocol between routers R1 and R2 is mandatory, the only option is BGP. BGP establishes peering based on TCP sessions that use unicasts. Those unicasts can be the 6to4 IPv6 address of the other side of the tunnel. If you choose not to use BGP, the only way to make this work is with static routes. You saw earlier that R1 had a faulty static route, which you fixed, and a static default. If you also add a proper static route on R2, you’ll restore connectivity across the network. In this example, the tunnel was configured correctly, and it was operational; however, it was routing through the tunnel that was failing. When troubleshooting, you should always think of temporary solutions that other troubleshooters left behind. In this example, OSPF was supposed to be running across the tunnel; however, it was not, and it seems that other troubleshooters tried static default routes to make it work. Static routes were indeed the correct option, and only BGP would have worked in this scenario for dynamic routing across the 6to4 tunnel.
Summary
The three main NAT categories are as follows:
The advantages of NAT include the following:
-
Conserves registered addresses
-
Hides the actual address of internal hosts and services
-
Increases flexibility when connecting to Internet
-
Eliminates address renumbering as the network changes from one ISP to another
The disadvantages of NAT are these:
-
Translation introduces processing delays.
-
Loss of end-to-end IP reachability.
-
Certain applications will not function with NAT enabled.
-
Considerations are needed when working with VPNs.
Examples of NAT sensitive protocols include the following:
Some of the useful NAT troubleshooting commands are as follows:
The main DHCP packets used during the address acquisition process are as follows:
-
DHCP discover
-
DHCP offer
-
DHCP request
-
DHCP ack
Other packet types involved in DHCP transactions include the following:
-
DHCP decline
-
DHCP nack
-
DHCP release
-
DHCP inform
With respect to DHCP, a router may play one of these roles:
-
DHCP server
-
DHCP client
-
DHCP relay agent
Enabling a router interface with the ip helper-address command makes the interface forward UDP broadcasts for six protocols (not just DHCP) to the IP address configured using the ip helper-address command. Those protocols are as follows:
The main DHCP options are these:
-
1: Subnet mask (Specifies the subnet mask for the client to use)
-
3: Router (The list of routers the client can use)
-
6: Domain Name Server (The list of DNS servers the client can use)
-
35: ARP cache timeout (Specifies the timeout, in seconds, for ARP cache entries)
-
51: IP address lease time (Specifies the period over which the IP address is leased for)
-
82: Relay agent information (Information about the port from which the DHCP request originates)
-
150: TFTP server IP address (Typically used by devices such as IP phones to download their configuration files)
Common troubleshooting issues related to DHCP snooping include the following:
-
Improper configuration of the DHCP snooping trust boundaries
-
Failure to configure DHCP snooping on certain VLANs
-
Improper configuration of the DHCP snooping rate limits
-
Performance degradation
The following Cisco IOS commands can prove helpful for DHCP troubleshooting:
Useful Cisco IOS IPv6 troubleshooting commands include the following:
-
debug ipv6 routing
-
debug ipv6 nd
-
debug tunnel
-
debug ipv6 packet
-
show ipv6 interface
-
show ipv6 routers
-
show ipv6 route
-
show ipv6 protocols
0 comments
Post a Comment