For the most part, all of the IPv4 and IPv6 interoperability issues are due to misconfigurations, however, in some rare cases, software and hardware defects or bugs may cause problems with some of the mechanisms described in the previous section. Prior to jumping to such conclusions, however, first check and then double-check your configurations. After checking and double-checking your configurations, if you are still convinced that the desired mechanism has been configured correctly, contact the TAC for further assistance in your troubleshooting effort. Some common problems encountered with the tunneling mechanisms described in the previous section include the following:
- The configured tunnel interface will not come up
- The tunnel is up but you cannot ping across it
- Routing adjacencies won’t establish across the tunnel
There are several reasons why a tunnel interface may not come up. These reasons include:
- Layer 1 / Layer 2 Issues
- Layer 3 Issues
- Misconfigurations
Layer 1 / Layer 2 issues will prevent the tunnel interface from transitioning to the up/up state. Following your tunnel configuration, if you notice that the line protocol reflects an up/down state, check the status of the interface specified as the tunnel source using the show interfacescommand. In most cases, this state is reflective of this source interface being shutdown (administratively disabled) or down itself, meaning that there are Layer 1 or Layer 2 issues preventing it from coming up. Troubleshoot the issues using the relevant commands.
In order for the Tunnel interface to come up, the specified tunnel destination must be present in the RIB of the local router. Consider the following output for example:
| R2#show interfaces tunnel 0 Tunnel0 is up, line protocol is down Hardware is Tunnel MTU 1514 bytes, BW 9 Kbit/sec, DLY 500000 usec, reliability 255/255, txload 1/255, rxload 1/255 Encapsulation TUNNEL, loopback not set Keepalive not set Tunnel source 150.1.1.2, destination 160.1.1.1 Tunnel protocol/transport IPv6/IP Key disabled, sequencing disabled Checksumming of packets disabled[Truncated Output] |
After having verified that the tunnel source interface is up on the local router, next verify that the tunnel destination is known to the local router using the show ip route command:
| R2#show ip route 160.1.1.1 % Network not in table |
In the output above, the specified tunnel destination address is not known to the local router hence the reason for the tunnel being in an up/down state. Depending on your routing configuration, add a static route to the tunnel destination or verify dynamic routing protocol configuration to ensure that this address is not being incorrectly filtered, for example. In our example, we will simply assume that the tunnel destination will be reachable via a static route pointing to out the Serial0/0 interface of the local router and add the following configuration:
| R2(config)#ip route 160.1.1.1 255.255.255.255 serial 0/0 |
Following this configuration, and having verified connectivity to the tunnel destination address, the tunnel interface transitions to the up/up state as follows:
| R2#show interfaces tunnel 0 Tunnel0 is up, line protocol is up Hardware is Tunnel MTU 1514 bytes, BW 9 Kbit/sec, DLY 500000 usec, reliability 255/255, txload 28/255, rxload 1/255 Encapsulation TUNNEL, loopback not set Keepalive not set Tunnel source 150.1.1.2, destination 160.1.1.1 Tunnel protocol/transport IPv6/IP Key disabled, sequencing disabled Checksumming of packets disabled Tunnel TTL 255[Truncated Output] |
Common configuration mistakes when implementing tunneling range from using or specifying the incorrect tunnel source and / or destination addresses to specifying the incorrect encapsulation type for the tunnel. For example, when configuring a manual tunnel, if you specify the tunnel mode as IPv6, meaning that the tunnel will encapsulate using IPv6 packets, the tunnel will not come if the tunnel source and tunnel destination addresses are IPv4 addresses as illustrated in the following output:
| R1#show interfaces tunnel 0 Tunnel0 is up, line protocol is down Hardware is Tunnel MTU 1514 bytes, BW 9 Kbit/sec, DLY 500000 usec, reliability 255/255, txload 1/255, rxload 1/255 Encapsulation TUNNEL, loopback not set Keepalive not set Tunnel source 160.1.1.2, destination 150.1.1.2 Tunnel protocol/transport IPv6 Tunnel TTL 255[Truncated Output] |
When specifying IPv4 addresses as the tunnel source and tunnel destination addresses, you are configuring an IPv4 tunnel. You must therefore specify that the IPv6 packets are encapsulated using IPv4 packets by issuing the tunnel mode ipv6ip interface configuration command. Thetunnel mode ipv6 command would be used to tunnel IPv4 packets in IPv6 packets which you would do if you were configuring an IPv6 tunnel instead, i.e. the specified tunnel source and tunnel destination addresses were IPv6 address. The same applies to the other tunneling mechanisms that are also described in this guide.
The most common reasons for a tunnel interface being up but you are unable to ping across it are due to basic misconfigurations, such as incorrectly typing in the tunnel address, and filtering. When routers are connected to public networks, such as the Internet, it is common practice to implement ACL filtering to protect both the device and network from unauthorized access. When implementing tunnels between two such routers, it is important to ensure that the specified encapsulation protocol is permitted between the two host address, i.e. between the tunnel source and tunnel destination addresses.
Another common reason for being unable to ping across tunnel interfaces is due to mismatched encapsulations on the tunnel interfaces. By default, tunnel interfaces default to GRE encapsulation in Cisco IOS software. If you specify a non-default encapsulation type, this must be the same on both endpoints. For example, assume that a simple tunnel is configured between two routers named R1 and R2. The tunnel configuration on R1 is as follows:
| R1#show running-config interface tunnel 0 Building configuration…Current configuration : 145 bytes ! interface Tunnel0 no ip address ipv6 address 3FF3:ABCD::1/64 tunnel source 160.1.1.2 tunnel destination 150.1.1.2 tunnel mode ipv6ip end |
On the remote endpoint, R2, the tunnel configuration has been implemented as follows:
| R2#show running-config interface tunnel 0 Building configuration…Current configuration : 125 bytes ! interface Tunnel0 no ip address ipv6 address 3FF3:ABCD::2/64 tunnel source 150.1.1.2 tunnel destination 160.1.1.2 end |
For verification purposes, a simple ping between the tunnel source and destination addresses will be used to validate end-to-end connectivity between the two as follows:
| R2#ping 160.1.1.2 source 150.1.1.2 repeat 10Type escape sequence to abort. Sending 10, 100-byte ICMP Echos to 160.1.1.2, timeout is 2 seconds: Packet sent with a source address of 150.1.1.2 !!!!!!!!!! Success rate is 100 percent (10/10), round-trip min/avg/max = 1/3/4 ms |
Because of the reachability between the tunnel endpoints, the tunnel interfaces are in an up/up state as illustrated in the output of the show interfaces command on R2 as follows:
| R2#show interfaces tunnel 0 Tunnel0 is up, line protocol is up Hardware is Tunnel MTU 1514 bytes, BW 9 Kbit/sec, DLY 500000 usec, reliability 255/255, txload 1/255, rxload 1/255 Encapsulation TUNNEL, loopback not set Keepalive not set Tunnel source 150.1.1.2, destination 160.1.1.2 Tunnel protocol/transport GRE/IP Key disabled, sequencing disabled Checksumming of packets disabled Tunnel TTL 255 |
However, despite the tunnel interface state, you notice that the routers cannot ping one another:
| R2#ping 3FF3:ABCD::1 repeat 10Type escape sequence to abort. Sending 10, 100-byte ICMP Echos to 3FF3:ABCD::1, timeout is 2 seconds: ………. Success rate is 0 percent (0/10) |
Parsing through the configurations again, you notice that one endpoint (R1) is using a tunnel mode of ipv6ip while the other endpoint (R2) is using the default, which is GRE. This encapsulation mismatch is the root cause of the problem. The recommended solution would therefore be to correct the configuration on R2 as follows:
| R2(config)#interface tunnel 0 R2(config-if)#tunnel mode ipv6ip R2(config-if)#exit |
Following this reconfiguration, you will be able to successfully ping between the routers:
| R2#ping 3FF3:ABCD::1 repeat 10Type escape sequence to abort. Sending 10, 100-byte ICMP Echos to 3FF3:ABCD::1, timeout is 2 seconds: !!!!!!!!!! Success rate is 100 percent (10/10), round-trip min/avg/max = 4/4/8 ms |
When you are troubleshooting routing protocol adjacency problems across tunnel interfaces, you should first perform the Layer 1, 2, and 3 checks that are described in this section. Following this, validate routing protocol configuration on both endpoints, diligently checking for things such as incorrectly specified passive interfaces and mismatched parameters, for example. Given that these steps are described in this and previous chapters, the same will not be repeated again in this section to avoid being unnecessarily repetitive and redundant.