SixXS::Sunset 2017-06-06

Ticket ID: SIXXS #1273208
Ticket Status: Resolved

PoP: ittrn01 - ITgate (Torino)

Tunnel T16701 not functioning properly
[it] Shadow Hawkins on Wednesday, 25 November 2009 00:08:23
The AYIYA tunnel T16701 is not functioning properly. The tunnel seems to set up correctly, as you can see in the following sections, but I cannot ping6 the other side of the tunnel (cfr. test). On the same machine, if I change in the configuration file (/etc/aiccu.conf) the tunnel from T16701 to T10893 (the one I usually use on the notebook) everything works correctly and I can ping the other side without any problem. The issue seems to be strictly related with the tunnel T16701. The version of aiccu I use is the one available in Debian Sid (20070115-10) and as I said works perfectly with other tunnels on other machines. Ask if you need more informations. ########################################################################## ## aiccu test ##########################################################################
dumbo:~# aiccu test Tunnel Information for T16701: POP Id : ittrn01 IPv6 Local : 2001:1418:100:288::2/64 IPv6 Remote : 2001:1418:100:288::1/64 Tunnel Type : ayiya Adminstate : enabled Userstate : enabled ####### ####### AICCU Quick Connectivity Test ####### ####### [1/8] Ping the IPv4 Local/Your Outer Endpoint (192.168.192.1) ### 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 192.168.192.1 (192.168.192.1) 56(84) bytes of data. 64 bytes from 192.168.192.1: icmp_seq=1 ttl=64 time=0.041 ms 64 bytes from 192.168.192.1: icmp_seq=2 ttl=64 time=0.039 ms 64 bytes from 192.168.192.1: icmp_seq=3 ttl=64 time=0.039 ms --- 192.168.192.1 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2001ms rtt min/avg/max/mdev = 0.039/0.039/0.041/0.007 ms ###### Did this work? [Y/n] y ####### [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(84) bytes of data. 64 bytes from 213.254.12.34: icmp_seq=1 ttl=56 time=101 ms 64 bytes from 213.254.12.34: icmp_seq=2 ttl=56 time=73.3 ms 64 bytes from 213.254.12.34: icmp_seq=3 ttl=56 time=94.5 ms --- 213.254.12.34 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2004ms rtt min/avg/max/mdev = 73.312/89.866/101.758/12.071 ms ###### Did this work? [Y/n] y ####### [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, 60 byte packets 1 192.168.192.254 (192.168.192.254) 0.923 ms 1.363 ms 1.814 ms 2 adsl3-tn.aknet.it (213.21.129.33) 33.425 ms 35.745 ms 36.143 ms 3 gw1-tn-te1.aknet.it (213.21.128.133) 37.703 ms 39.322 ms 40.784 ms 4 gw1-rm-gi0.aknet.it (213.21.132.1) 53.080 ms 53.521 ms 55.200 ms 5 net84-253-128-001.mclink.it (84.253.128.1) 57.215 ms 58.118 ms 60.097 ms 6 if-0-0-4.core1.RCT-Rome.as6453.net (195.219.163.33) 64.555 ms 64.842 ms 67.276 ms 7 if-7-0.core3.MLT-Milan.as6453.net (195.219.158.49) 68.404 ms 44.260 ms 44.649 ms 8 if-6-0-0.mcore3.L78-London.as6453.net (195.219.158.58) 72.151 ms 73.988 ms 74.446 ms 9 if-5-0-0.mcore3.LDN-London.as6453.net (195.219.195.9) 75.541 ms 77.355 ms 78.320 ms 10 Vlan463.icore1.LDN-London.as6453.net (195.219.195.38) 85.758 ms 86.072 ms 86.435 ms 11 ge4-1-0-1000M.ar3.LON2.gblx.net (64.208.110.81) 84.182 ms 85.057 ms 86.763 ms 12 64.210.15.114 (64.210.15.114) 88.313 ms 90.214 ms 91.129 ms 13 if-0-3.scooby-monster.core.TRN.itgate.net (213.254.31.241) 72.111 ms 71.755 ms 226.885 ms 14 if-0-0.charleston.CBQ.TRN.itgate.net (213.254.0.13) 229.363 ms 231.029 ms 231.664 ms 15 frejus.ITgate.net (213.254.12.34) 233.245 ms 234.587 ms 235.997 ms ###### Did this work? [Y/n] y ###### [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: icmp_seq=1 ttl=64 time=0.033 ms 64 bytes from ::1: icmp_seq=2 ttl=64 time=0.032 ms 64 bytes from ::1: icmp_seq=3 ttl=64 time=0.037 ms --- ::1 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 1998ms rtt min/avg/max/mdev = 0.032/0.034/0.037/0.002 ms ###### Did this work? [Y/n] y ###### [5/8] Ping the IPv6 Local/Your Inner Tunnel Endpoint (2001:1418:100:288::2) ### This confirms that your tunnel is configured ### If it doesn't reply then check your interface and routing tables PING 2001:1418:100:288::2(2001:1418:100:288::2) 56 data bytes 64 bytes from 2001:1418:100:288::2: icmp_seq=1 ttl=64 time=0.042 ms 64 bytes from 2001:1418:100:288::2: icmp_seq=2 ttl=64 time=0.029 ms 64 bytes from 2001:1418:100:288::2: icmp_seq=3 ttl=64 time=0.028 ms --- 2001:1418:100:288::2 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 1998ms rtt min/avg/max/mdev = 0.028/0.033/0.042/0.006 ms ###### Did this work? [Y/n] y ###### [6/8] Ping the IPv6 Remote/PoP Inner Tunnel Endpoint (2001:1418:100:288::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:288::1(2001:1418:100:288::1) 56 data bytes --- 2001:1418:100:288::1 ping statistics --- 3 packets transmitted, 0 received, 100% packet loss, time 2015ms ###### Did this work? [Y/n] n
########################################################################## ########################################################################## ## Startup of the tunnel ##########################################################################
dumbo:~# aiccu start sock_getline() : "200 SixXS TIC Service on noc.sixxs.net ready (http://www.sixxs.net)" sock_printf() : "client TIC/draft-00 AICCU/2007.01.15-console-linux Linux/2.6.31-1-amd64" sock_getline() : "200 Client Identity accepted" sock_printf() : "get unixtime" sock_getline() : "200 1259102774" sock_printf() : "starttls" sock_getline() : "400 This service is not SSL enabled (yet)" TIC Server does not support TLS but TLS is not required, continuing sock_printf() : "username FV2151-RIPE" sock_getline() : "200 Choose your authentication challenge please" sock_printf() : "challenge md5" sock_getline() : "200 fbb6ee4146ad19f67c8939451ada1e37" sock_printf() : "authenticate md5 87c2548530ab1a2c073c1e1e913a1dfb" sock_getline() : "200 Succesfully logged in using md5 as FV2151-RIPE (Flavio Visentin) from 2001:960:800::2" sock_printf() : "tunnel show T16701" sock_getline() : "201 Showing tunnel information for T16701" sock_getline() : "TunnelId: T16701" sock_getline() : "Type: ayiya" sock_getline() : "IPv6 Endpoint: 2001:1418:100:288::2" sock_getline() : "IPv6 POP: 2001:1418:100:288::1" sock_getline() : "IPv6 PrefixLength: 64" sock_getline() : "Tunnel MTU: 1280" sock_getline() : "Tunnel Name: Tunnel Home" sock_getline() : "POP Id: ittrn01" sock_getline() : "IPv4 Endpoint: ayiya" sock_getline() : "IPv4 POP: 213.254.12.34" sock_getline() : "UserState: enabled" sock_getline() : "AdminState: enabled" sock_getline() : "Password: b0fcbdedaf999b9e1e1fe4092b5171b6" sock_getline() : "Heartbeat_Interval: 60" sock_getline() : "202 Done" Succesfully retrieved tunnel information for T16701 sock_printf() : "QUIT Running Down That Hill" Tunnel Information for T16701: POP Id : ittrn01 IPv6 Local : 2001:1418:100:288::2/64 IPv6 Remote : 2001:1418:100:288::1/64 Tunnel Type : ayiya Adminstate : enabled Userstate : enabled [AYIYA-start] : Anything in Anything (draft-02) [AYIYA-tun->tundev] : (Socket to TUN) started
##########################################################################
Tunnel T16701 not functioning properly
[it] Shadow Hawkins on Wednesday, 25 November 2009 00:14:02
I forgot to mention that a tcpdump shows all the packets going out but any packet coming back. The trace inside the tunnel shows the icmpv6 request but obviously not the replies dumbo:~# tcpdump -i any -n host 213.254.12.34 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on any, link-type LINUX_SLL (Linux cooked), capture size 96 bytes 00:11:18.229278 IP 192.168.192.1.47453 > 213.254.12.34.5072: UDP, length 92 00:11:18.233475 IP 192.168.192.1.47453 > 213.254.12.34.5072: UDP, length 44 00:11:18.234059 IP 192.168.192.1.47453 > 213.254.12.34.5072: UDP, length 44 00:11:18.234071 IP 192.168.192.1.47453 > 213.254.12.34.5072: UDP, length 44 00:11:22.229544 IP 192.168.192.1.47453 > 213.254.12.34.5072: UDP, length 92 00:11:26.229537 IP 192.168.192.1.47453 > 213.254.12.34.5072: UDP, length 92 00:11:44.478465 IP 192.168.192.1.47453 > 213.254.12.34.5072: UDP, length 148 00:11:45.477557 IP 192.168.192.1.47453 > 213.254.12.34.5072: UDP, length 148 00:11:46.477552 IP 192.168.192.1.47453 > 213.254.12.34.5072: UDP, length 148 00:11:47.477556 IP 192.168.192.1.47453 > 213.254.12.34.5072: UDP, length 148 00:11:48.477556 IP 192.168.192.1.47453 > 213.254.12.34.5072: UDP, length 148 00:11:49.477557 IP 192.168.192.1.47453 > 213.254.12.34.5072: UDP, length 148 00:11:50.477541 IP 192.168.192.1.47453 > 213.254.12.34.5072: UDP, length 148 00:11:51.477561 IP 192.168.192.1.47453 > 213.254.12.34.5072: UDP, length 148 00:11:52.477537 IP 192.168.192.1.47453 > 213.254.12.34.5072: UDP, length 148 00:11:53.477534 IP 192.168.192.1.47453 > 213.254.12.34.5072: UDP, length 148 dumbo:~# tcpdump -i sixxs -n tcpdump: WARNING: sixxs: no IPv4 address assigned tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on sixxs, link-type RAW (Raw IP), capture size 96 bytes 00:12:59.014184 IP6 2001:1418:100:288::2 > 2001:1418:100:288::1: ICMP6, echo request, seq 1, length 64 00:13:00.013496 IP6 2001:1418:100:288::2 > 2001:1418:100:288::1: ICMP6, echo request, seq 2, length 64 00:13:01.013521 IP6 2001:1418:100:288::2 > 2001:1418:100:288::1: ICMP6, echo request, seq 3, length 64 00:13:02.013517 IP6 2001:1418:100:288::2 > 2001:1418:100:288::1: ICMP6, echo request, seq 4, length 64 00:13:03.013494 IP6 2001:1418:100:288::2 > 2001:1418:100:288::1: ICMP6, echo request, seq 5, length 64 00:13:04.013515 IP6 2001:1418:100:288::2 > 2001:1418:100:288::1: ICMP6, echo request, seq 6, length 64 00:13:05.013516 IP6 2001:1418:100:288::2 > 2001:1418:100:288::1: ICMP6, echo request, seq 7, length 64
State change: resolved Locked
[ch] Jeroen Massar SixXS Staff on Friday, 04 December 2009 16:17:47
Message is Locked
The state of this ticket has been changed to resolved
Tunnel T16701 not functioning properly
[it] Shadow Hawkins on Sunday, 21 November 2010 03:12:35
Last week the tunnel stopped to function again. Initially I thought it was caused by the kernel update, but if I change the tunnel everything works fine. The problem is the very same; same behaviour, same output of the commands.
Tunnel T16701 not functioning properly
[it] Shadow Hawkins on Tuesday, 23 November 2010 22:06:58
OK, the tunnel is working again. TNX

Please note Posting is only allowed when you are logged in.

Static Sunset Edition of SixXS
©2001-2017 SixXS - IPv6 Deployment & Tunnel Broker