Troubleshooting IPv6 Automatic 6to4 Tunnel

In this lesson we’ll take a look how to troubleshoot an automatic IPv6 6to4 tunnel. Take a look at the following topology:

IPv6 automatic 6 to 4 tunnel

This scenario requires some more explanation. R1 and R3 each have a loopback0 interface with an IPv6 prefix on it. The FastEthernet interfaces of R1, R2 and R3 only have IPv4 addresses. The network engineer that designed this topology created an automatic 6to4 tunnel to establish connectivity between the two IPv6 networks. Of course this is not working so we’ll have some fixing to do.

I’ll show you the tunnel configuration from the running-config:

R1#show running-config | begin Tunnel0  
interface Tunnel0
 no ip address
 no ip redirects
 ipv6 address 2002:A0A:A01::1/64
 tunnel source FastEthernet0/0
 tunnel mode ipv6ip 6to4
R3#show running-config | begin Tunnel0
interface Tunnel0
 no ip address
 no ip redirects
 ipv6 address 2002:A14:1403::3/64
 tunnel source FastEthernet0/0
 tunnel mode ipv6ip 6to4

Above you can see the tunnel interfaces, they have been configured for 6to4 tunneling and there’s an IPv6 address on each tunnel. Let’s see if the tunnel works:

R1#ping 2001:1::3

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001:1::3, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5) 
R3#ping 2001:1::1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001:1::1, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)

A quick ping shows us that we can’t ping the IPv6 addresses on the loopback interfaces. So where should we start troubleshooting? Let’s check if R1 and R3 are able to reach each other:

R1#ping 192.168.23.3 source fastEthernet 0/0

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.23.3, timeout is 2 seconds:
Packet sent with a source address of 192.168.12.1 
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/8/12 ms

The tunnel 0 interfaces are sourced from the FastEthernet 0/0 interfaces of R1 and R3. By sending a ping from R1 to R3 between the FastEthernet 0/0 interfaces I know that IPv4 routing is not the issue. Let’s take a closer look at the IPv6 addresses:

R1#show ipv6 interface brief 
FastEthernet0/0            [up/up]
Loopback0                  [up/up]
    FE80::CE09:25FF:FEB0:0
    2001:1::1
Tunnel0                    [up/up]
    FE80::C0A8:C01
    2002:A0A:A01::1
R3#show ipv6 interface brief 
FastEthernet0/0            [up/up]
Loopback0                  [up/up]
    FE80::CE0B:25FF:FEB0:0
    2001:1::3
Tunnel0                    [up/up]
    FE80::C0A8:1703
    2002:A14:1403::3

Taking a quick look at the interfaces tells us that the IPv6 addresses on the loopback 0 interfaces have been configured correctly and that the interfaces are up and running. You can also see the IPv6 addresses on the tunnel 0 interfaces. What do the 2002:A0A:A01::1 and 2002:A14:1403::3 addresses mean?

Keep in mind that the tunnel mode is automatic 6to4. The “automatic” part means that the tunnel destination IP is not configured statically but within the IPv6 address. 2002::/16 is the range that is reserved for tunnels. Let’s see if we can ping these tunnel IPv6 addresses:

R1#ping 2002:A14:1403::3

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2002:A14:1403::3, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
R3#ping 2002:A0A:A01::1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2002:A0A:A01::1, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)

We are unable to ping the IPv6 addresses on the tunnel 0 interfaces. This could mean that 2002:A0A:A01::1 and 2002:A14:1403::3 are not correct or that my routing is not working.

The tunnel should be built between IP address 192.168.12.1 and 192.168.23.3. If you want you can manually calculate from decimal to hexadecimal but there’s an easier method! Here’s how:

R1(config)#ipv6 general-prefix IAMLAZY 6to4 fastEthernet 0/0

We can let our router do the calculation from decimal to hexadecimal for us. Here’s the result:

R1#show ipv6 general-prefix 
IPv6 Prefix IAMLAZY, acquired via 6to4
  2002:C0A8:C01::/48

There you go, the IPv6 address should be in this range 2002:C0A8:C01/48 so 2002:A0A:A01::1/64 on R1 is incorrect. Let’s fix it:

R1(config)#interface tunnel 0
R1(config-if)#no ipv6 address 2002:A0A:A01::1/64
R1(config-if)#ipv6 address 2002:C0A8:C01::1/64

We’ll remove the old IPv6 address and configure a new one in the 2002:C0A8:C01/48 range. Let’s see if the address on R3 is correct as well:

R3(config)#ipv6 general-prefix IAMLAZY 6to4 FastEthernet 0/0

Here’s the result:

R3#show ipv6 general-prefix 
IPv6 Prefix IAMLAZY, acquired via 6to4
  2002:C0A8:1703::/48

The correct prefix is 2002:C0A8:1703::/48 so 2002:A14:1403::3 is not going to work. Let’s fix it:

R3(config-if)#no ipv6 address 2002:A14:1403::3/64
R3(config-if)#ipv6 address 2002:C0A8:1703::3/64

We’ll remove the IPv6 address and configure another one that falls within the 2002:A14:1403::3 range.

Now we know that the IPv6 addresses on the tunnel 0 interfaces are correct. Next step is to check our routing to see if R1 and R3 know how to reach each other’s IPv6 addresses. Let’s check the routing tables:

R1#show ipv6 route
IPv6 Routing Table - 7 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
LC  2001:1::1/128 [0/0]
     via ::, Loopback0
S   2001:1::3/128 [1/0]
     via 2002:A14:1403::3
S   2002::/16 [1/0]
     via ::, Tunnel0
C   2002:C0A8:C01::/64 [0/0]
     via ::, Tunnel0
L   2002:C0A8:C01::1/128 [0/0]
     via ::, Tunnel0
L   FE80::/10 [0/0]
     via ::, Null0
L   FF00::/8 [0/0]
     via ::, Null0

There are two static routes here. The 2001:1::3/128 points to the loopback 0 interface of R3 but the next hop IPv6 address is 2002:A14:1403::3. This next hop is incorrect so we’ll have to change it. The static route for 2002::/16 to the tunnel 0 interface is fine. This prefix is reserved for tunneling and we need it because the router will do a recursive routing looking when it tries to reach 2001:1::3/128. Let’s fix it:

We're Sorry, Full Content Access is for Members Only...

If you like to keep on reading, Become a Member Now! Here is why:

  • Learn any CCNA, CCNP and CCIE R&S Topic. Explained As Simple As Possible.
  • Try for Just $1. The Best Dollar You've Ever Spent on Your Cisco Career!
  • Full Access to our 662 Lessons. More Lessons Added Every Week!
  • Content created by Rene Molenaar (CCIE #41726)

519 Sign Ups in the last 30 days

satisfaction-guaranteed
100% Satisfaction Guaranteed!
You may cancel your monthly membership at any time.
No Questions Asked!

Ask a question or start a discussion by visiting our Community Forum