Ticket ID: SIXXS #1273208 Ticket Status: Resolved PoP: ittrn01 - ITgate (Torino)
Tunnel T16701 not functioning properly
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
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
Jeroen Massar on Friday, 04 December 2009 16:17:47
The state of this ticket has been changed to resolved
Tunnel T16701 not functioning properly
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
Shadow Hawkins on Tuesday, 23 November 2010 22:06:58
OK, the tunnel is working again. TNX
Posting is only allowed when you are logged in. |