The T17841 tunnel is having problems, and they have been verified on two different Linux-based platforms. The very same platforms configured for a different tunnel I have, T37145, work without problems. Unfortunately, T17841 is where I have my subnet routed, so it is quite important for my IPv6 connectivity. The AICCU autotest log follows, point #6 fails and thus #7 and #8 fail too. ####### ####### AICCU Quick Connectivity Test ####### ####### [1/8] Ping the IPv4 Local/Your Outer Endpoint (1.118.199.137) ### This should return so called 'echo replies' ### If it doesn't then check your firewall settings ### Your local endpoint should always be pingable ### It could also indicate problems with your IPv4 stack PING 1.118.199.137 (1.118.199.137): 56 data bytes 64 bytes from 1.118.199.137: seq=0 ttl=64 time=1.270 ms 64 bytes from 1.118.199.137: seq=1 ttl=64 time=0.717 ms 64 bytes from 1.118.199.137: seq=2 ttl=64 time=0.715 ms --- 1.118.199.137 ping statistics --- 3 packets transmitted, 3 packets received, 0% packet loss round-trip min/avg/max = 0.715/0.900/1.270 ms ###### ####### [2/8] Ping the IPv4 Remote/PoP Outer Endpoint (213.254.12.34) ### These pings should reach the PoP and come back to you ### In case there are problems along the route between your ### host and the PoP this could not return replies ### Check your firewall settings if problems occur PING 213.254.12.34 (213.254.12.34): 56 data bytes 64 bytes from 213.254.12.34: seq=0 ttl=56 time=7.460 ms 64 bytes from 213.254.12.34: seq=1 ttl=56 time=11.909 ms 64 bytes from 213.254.12.34: seq=2 ttl=56 time=8.331 ms --- 213.254.12.34 ping statistics --- 3 packets transmitted, 3 packets received, 0% packet loss round-trip min/avg/max = 7.460/9.233/11.909 ms ###### ####### [3/8] Traceroute to the PoP (213.254.12.34) over IPv4 ### This traceroute should reach the PoP ### In case this traceroute fails then you have no connectivity ### to the PoP and this is most probably the problem traceroute to 213.254.12.34 (213.254.12.34), 30 hops max, 38 byte packets 1 1.118.199.2 (1.118.199.2) 2.050 ms 2.051 ms 1.860 ms 2 10.251.130.65 (10.251.130.65) 1.796 ms 2.289 ms 1.726 ms 3 10.251.126.23 (10.251.126.23) 1.895 ms 1.940 ms 1.767 ms 4 10.251.127.1 (10.251.127.1) 2.177 ms 2.045 ms 1.929 ms 5 10.247.124.173 (10.247.124.173) 1.905 ms 3.446 ms 2.605 ms 6 10.251.131.194 (10.251.131.194) 2.099 ms 2.075 ms 2.629 ms 7 10.0.16.73 (10.0.16.73) 2.024 ms 2.415 ms 1.835 ms 8 10.0.1.150 (10.0.1.150) 2.579 ms 2.536 ms 2.221 ms 9 10.254.9.250 (10.254.9.250) 2.305 ms 2.621 ms 2.088 ms 10 10.254.9.202 (10.254.9.202) 4.507 ms 2.878 ms 2.518 ms 11 89.96.200.154 (89.96.200.154) 3.131 ms 2.898 ms 3.324 ms 12 89.96.200.117 (89.96.200.117) 5.586 ms 2.701 ms 2.795 ms 13 itgate-pub.topix.it (194.116.96.4) 5.928 ms 6.274 ms 6.074 ms 14 if-0-0.charleston.CBQ.TRN.itgate.net (213.254.0.13) 6.107 ms 5.846 ms 5.607 ms 15 * ###### ###### [4/8] Checking if we can ping IPv6 localhost (::1) ### This confirms if your IPv6 is working ### If ::1 doesn't reply then something is wrong with your IPv6 stack PING ::1 (::1): 56 data bytes 64 bytes from ::1: seq=0 ttl=64 time=0.684 ms 64 bytes from ::1: seq=1 ttl=64 time=0.569 ms 64 bytes from ::1: seq=2 ttl=64 time=0.582 ms --- ::1 ping statistics --- 3 packets transmitted, 3 packets received, 0% packet loss round-trip min/avg/max = 0.569/0.611/0.684 ms ###### ###### [5/8] Ping the IPv6 Local/Your Inner Tunnel Endpoint (2001:1418:100:2a1::2) ### This confirms that your tunnel is configured ### If it doesn't reply then check your interface and routing tables PING 2001:1418:100:2a1::2 (2001:1418:100:2a1::2): 56 data bytes 64 bytes from 2001:1418:100:2a1::2: seq=0 ttl=64 time=0.781 ms 64 bytes from 2001:1418:100:2a1::2: seq=1 ttl=64 time=0.638 ms 64 bytes from 2001:1418:100:2a1::2: seq=2 ttl=64 time=0.628 ms --- 2001:1418:100:2a1::2 ping statistics --- 3 packets transmitted, 3 packets received, 0% packet loss round-trip min/avg/max = 0.628/0.682/0.781 ms ###### ###### [6/8] Ping the IPv6 Remote/PoP Inner Tunnel Endpoint (2001:1418:100:2a1::1) ### This confirms the reachability of the other side of the tunnel ### If it doesn't reply then check your interface and routing tables ### Don't forget to check your firewall of course ### If the previous test was succesful then this could be both ### a firewalling and a routing/interface problem PING 2001:1418:100:2a1::1 (2001:1418:100:2a1::1): 56 data bytes --- 2001:1418:100:2a1::1 ping statistics --- 3 packets transmitted, 0 packets received, 100% packet loss ###### ###### [7/8] Traceroute6 to the central SixXS machine (noc.sixxs.net) ### This confirms that you can reach the central machine of SixXS ### If that one is reachable you should be able to reach most IPv6 destinations ### Also check http://www.sixxs.net/ipv6calc/ which should show an IPv6 connection ### If your browser supports IPv6 and uses it of course. traceroute to noc.sixxs.net (2001:838:1:1:210:dcff:fe20:7c7c) from 2001:1418:100:2a1::2, 30 hops max, 16 byte packets 1 * * * 2 * ###### ###### [8/8] Traceroute6 to (www.kame.net) ### This confirms that you can reach a Japanese IPv6 destination ### If that one is reachable you should be able to reach most IPv6 destinations ### You should also check http://www.kame.net which should display ### a animated kame (turtle), of course only when your browser supports and uses IPv6 traceroute to orange.kame.net (2001:200:dff:fff1:216:3eff:feb1:44d7) from 2001:1418:100:2a1::2, 30 hops max, 16 byte packets 1 ###### Given that this very same tunnel had problems in the past, I am wondering if the same issue has resurfaced on Dec 7th, the last day the tunnel worked properly. Many thanks and best regards, Luca LBU3-SIXXS