|
Ticket ID: SIXXS #689202 Ticket Status: User PoP: nlede01 - BIT BV (Ede)
IPv6 connectivity problem
![[lu]](/s/countries/lu.gif) Shadow Hawkins on Sunday, 16 March 2008 13:44:03
I have read and followed the "Reporting Problems" section on the Contact page and am providing the following details for this report based on the list of items stated there:
Hello,
Since yesterday evening (as it looks in the noc.sixxs.org page) my IPv6 connectivity through Sixxs is not working anymore. To be more precise:
- I have one account (DJO1-SIXXS), with two tunnels:
1) T12407 to my workplace used for an IPv6 related project, the router is a Gentoo Linux machine running aiccu provided by the Gentoo portage tree (AICCU 2007.01.15-console-linux by Jeroen Massar)
2) T14191 to my home, the router is a Linksys WRT54GS running OpenWRT Kamikaze 7.09 with the aiccu version provided by the OpenWRT project (AICCU 2007.01.15-console by Jeroen Massar)
On both systems, I am able to start aiccu, it does not give any error messages even in verbose mode, the tunnels seem to be set up correctly.
When I ping to the world (I generally use www.switch.ch or www.bit.nl), I can see the ICMP6 echo requests going out (with tcpdump), but no reply.
I also tried to ping my router machines using [1], but could not see any traffic coming in.
The PoP status page says that nlede01 is up.
Of course this worked previously without problem, and I have not changed anything to the configuration. The router for the first tunnel is running 24/24 on an ADSL line, the router for the second tunnel is only running when I'm at home.
Thanks and best regards,
Dan Jungels
[1] http://lg.consulintel.euro6ix.org/
State change: user
The state of this ticket has been changed to user
IPv6 connectivity problem
Please actually try and read and use the "Reporting Problems" checklist.
IPv6 connectivity problem
Shadow Hawkins on Sunday, 16 March 2008 19:40:57
Hi Jeroen,
I'm not sure if you want me to contact you by email (there is this yellow "i" info box telling that one should contact you to the "contact address").. on the contact page you also mention the ticket system...?
Anyway, here my results of the checklist.
* Always include clear descriptive information about your problem or inquiry. I think I did this already in the previous post. But to repeat in a clear way the problem of the first post: the tunnel works (at least the interface is up and sends out traffic), but no IPv6 traffic comes through my tunnels anymore back to me (on two different routers at two different locations).
I was absent this afternoon, and when I came back now, the connectivity seems to be working again, but I now get DUPs when pinging...
PING www.switch.ch(aslan.switch.ch) 56 data bytes
64 bytes from aslan.switch.ch: icmp_seq=1 ttl=56 time=109 ms
64 bytes from aslan.switch.ch: icmp_seq=1 ttl=56 time=110 ms (DUP!)
64 bytes from aslan.switch.ch: icmp_seq=2 ttl=56 time=104 ms
64 bytes from aslan.switch.ch: icmp_seq=2 ttl=56 time=106 ms (DUP!)
* When on a UNIX-alike platform that supports AICCU, please run AICCU and run it using "aiccu test". Before my first post, test number 7 failed. Because since noon the situation seems to have changed, I redid the test, and here are the outputs:
For tunnel T12407:
u2010-rtr01 ~ # aiccu test
#######
####### AICCU Quick Connectivity Test
#######
####### [1/8] Ping the IPv4 Local/Your Outer Endpoint (192.168.130.22)
### 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.130.22 (192.168.130.22) 56(84) bytes of data.
64 bytes from 192.168.130.22: icmp_seq=1 ttl=64 time=0.164 ms
64 bytes from 192.168.130.22: icmp_seq=2 ttl=64 time=0.089 ms
64 bytes from 192.168.130.22: icmp_seq=3 ttl=64 time=0.097 ms
--- 192.168.130.22 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 1998ms
rtt min/avg/max/mdev = 0.089/0.116/0.164/0.035 ms
######
Did this work? [Y/n] y
####### [2/8] Ping the IPv4 Remote/PoP Outer Endpoint (193.109.122.244)
### 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 193.109.122.244 (193.109.122.244) 56(84) bytes of data.
64 bytes from 193.109.122.244: icmp_seq=1 ttl=56 time=40.7 ms
64 bytes from 193.109.122.244: icmp_seq=2 ttl=56 time=34.0 ms
64 bytes from 193.109.122.244: icmp_seq=3 ttl=56 time=33.2 ms
--- 193.109.122.244 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 1998ms
rtt min/avg/max/mdev = 33.229/35.999/40.759/3.380 ms
######
Did this work? [Y/n] y
####### [3/8] Traceroute to the PoP (193.109.122.244) 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 193.109.122.244 (193.109.122.244), 30 hops max, 40 byte packets
1 192.168.130.254 (192.168.130.254) 3.716 ms 4.782 ms 5.902 ms
2 * * *
3 * * *
4 * * *
5 * * *
6 * * *
7 213.166.61.205 (213.166.61.205) 30.092 ms 27.784 ms 24.997 ms
8 213.166.61.201 (213.166.61.201) 33.249 ms 33.788 ms 34.550 ms
9 amsix-501.xe-0-0-0.jun1.kelvin.network.bit.nl (195.69.144.200) 33.575 ms 33.533 ms 33.566 ms
10 nlede01.sixxs.net (193.109.122.244) 35.501 ms 34.044 ms 35.375 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.081 ms
64 bytes from ::1: icmp_seq=2 ttl=64 time=0.045 ms
64 bytes from ::1: icmp_seq=3 ttl=64 time=0.042 ms
--- ::1 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 1998ms
rtt min/avg/max/mdev = 0.042/0.056/0.081/0.017 ms
######
Did this work? [Y/n] y
###### [5/8] Ping the IPv6 Local/Your Inner Tunnel Endpoint (2001:7b8:2ff:175::2)
### This confirms that your tunnel is configured
### If it doesn't reply then check your interface and routing tables
PING 2001:7b8:2ff:175::2(2001:7b8:2ff:175::2) 56 data bytes
64 bytes from 2001:7b8:2ff:175::2: icmp_seq=1 ttl=64 time=0.087 ms
64 bytes from 2001:7b8:2ff:175::2: icmp_seq=2 ttl=64 time=0.048 ms
64 bytes from 2001:7b8:2ff:175::2: icmp_seq=3 ttl=64 time=0.046 ms
--- 2001:7b8:2ff:175::2 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 1998ms
rtt min/avg/max/mdev = 0.046/0.060/0.087/0.019 ms
######
Did this work? [Y/n] y
###### [6/8] Ping the IPv6 Remote/PoP Inner Tunnel Endpoint (2001:7b8:2ff:175::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:7b8:2ff:175::1(2001:7b8:2ff:175::1) 56 data bytes
64 bytes from 2001:7b8:2ff:175::1: icmp_seq=1 ttl=64 time=42.1 ms
64 bytes from 2001:7b8:2ff:175::1: icmp_seq=1 ttl=64 time=43.4 ms (DUP!)
64 bytes from 2001:7b8:2ff:175::1: icmp_seq=2 ttl=64 time=35.8 ms
64 bytes from 2001:7b8:2ff:175::1: icmp_seq=2 ttl=64 time=37.0 ms (DUP!)
64 bytes from 2001:7b8:2ff:175::1: icmp_seq=3 ttl=64 time=36.3 ms
--- 2001:7b8:2ff:175::1 ping statistics ---
3 packets transmitted, 3 received, +2 duplicates, 0% packet loss, time 2000ms
rtt min/avg/max/mdev = 35.821/38.982/43.488/3.194 ms
######
Did this work? [Y/n] y
###### [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:7b8:2ff:175::2, 30 hops max, 16 byte packets
1 gw-374.ede-01.nl.sixxs.net (2001:7b8:2ff:175::1) 42.352 ms 39.675 ms 39.841 ms
2 sixxs-gw.ipv6.network.bit.nl (2001:7b8:3:4f:290:6900:4fc6:d81f) 41.264 ms 39.391 ms 40.206 ms
3 ams-ix.ipv6.concepts.nl (2001:7f8:1::a501:2871:1) 43.714 ms 41.882 ms 41.949 ms
4 2001:838:0:10::2 (2001:838:0:10::2) 45.899 ms 41.672 ms 44.633 ms
5 noc.sixxs.net (2001:838:1:1:210:dcff:fe20:7c7c) 45.446 ms 42.018 ms 44.508 ms
######
Did this work? [Y/n] y
###### [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 www.kame.net (2001:200:0:8002:203:47ff:fea5:3085) from 2001:7b8:2ff:175::2, 30 hops max, 16 byte packets
1 gw-374.ede-01.nl.sixxs.net (2001:7b8:2ff:175::1) 41.392 ms 41.814 ms *
2 sixxs-gw.ipv6.network.bit.nl (2001:7b8:3:4f:290:6900:4fc6:d81f) 40.074 ms 40.55 ms 38.645 ms
3 ge-1-11.r01.amstnl02.nl.bb.gin.ntt.net (2001:728:1800:5000::1) 41.68 ms 42.581 ms 43.345 ms
4 xe-2-0-0.r23.amstnl02.nl.bb.gin.ntt.net (2001:728:0:2000::41) 42.287 ms 42.129 ms 40.663 ms
5 as-0.r20.asbnva01.us.bb.gin.ntt.net (2001:728:0:2000::121) 133.981 ms 131.952 ms 130.668 ms
6 as-0.r20.snjsca04.us.bb.gin.ntt.net (2001:418:0:2000::1de) 204.984 ms 201.209 ms 201.378 ms
7 as-2.r20.tokyjp01.jp.bb.gin.ntt.net (2001:218:0:2000::ce) 311.45 ms 307.997 ms 307.606 ms
8 xe-3-2.a15.tokyjp01.jp.ra.gin.ntt.net (2001:218:0:6000::10e) 308.904 ms 308.978 ms 307.181 ms
9 ge-8-2.a15.tokyjp01.jp.ra.gin.ntt.net (2001:218:2000:5000::82) 306.99 ms 307.725 ms 307.212 ms
10 ve-4.nec2.yagami.wide.ad.jp (2001:200:0:1c04:230:13ff:feae:5b) 310.89 ms 310.622 ms 309.167 ms
11 lo0.alaxala1.k2.wide.ad.jp (2001:200:0:4800::7800:1) 307.143 ms 310.263 ms 308.19 ms
12 orange.kame.net (2001:200:0:8002:203:47ff:fea5:3085) 306.071 ms 310.571 ms 309.1 ms
######
Did this work? [Y/n] y
###### ACCU Quick Connectivity Test (done)
### Either the above all works and gives no problems
### or it shows you where what goes wrong
### Check the SixXS FAQ (http://www.sixxs.net/faq/
### for more information and possible solutions or hints
### Don't forget to check the Forums (http://www.sixxs.net/forum/)
### for a helping hand.
### Passing the output of 'aiccu autotest >aiccu.log' is a good idea.
*** press a key to continue ***
For tunnel T14191:
On OpenWRT the test option does not work correctly, because the ping command does not take the same arguments (e.g. it does not know "-v"):
####### [1/8] Ping the IPv4 Local/Your Outer Endpoint (192.168.33.10)
### 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
[AYIYA-tun->tundev] : (Socket to TUN) started
ping: illegal option -- v
BusyBox v1.4.2 (2007-09-29 09:01:24 CEST) multi-call binary
Usage: ping [OPTION]... host
Send ICMP ECHO_REQUEST packets to network hosts
Options:
-c CNT Send only CNT pings
-s SIZE Send SIZE data bytes in packets (default=56)
-I IP Use IP as source address
-q Quiet mode, only displays output at start
and when finished
######
Did this work? [Y/n]
But the behaviour of the two routers is the same (I get DUPs on both).
* When using AICCU, check that you are using the latest version, and of course please specify where the binary comes from. See first post. It is the latest version for Linux, and it's the version provided by Gentoo and OpenWRT. I made no changes in the last days.
* Always provide your NIC handle and if applicable the Tunnel or Route IDs you wish to discuss. DJO1-SIXXS
tunnels T12407 and T14191
* Use the email address you have provided in your handle as that is what we use as a contact handle. Hm, well, I suppose using the webinterface here is also OK, or does it need to be email?
* Provide details of the setup, type of connections, where NATs are located. In both cases it's an ADSL connection, using a US-Robotics home router (tunnel T12407) and a FritzBox router (tunnel T14191). They both provide NAT. But as mentioned, it worked very fine for several months/weeks, so I don't think it's a problem related to the ADSL routers.
* Provide information of your OS type, version and release (ie. uname -a), noting also the distribution name. 1) Gentoo
Linux u2010-rtr01 2.6.23-gentoo-r9dj #1 Sat Mar 8 12:17:11 CET 2008 i686 Pentium III (Katmai) GenuineIntel GNU/Linux
2) OpenWRT
Linux gate2 2.4.34 #3 Sun Sep 30 20:33:21 CEST 2007 mips unknown
* Include full interface, routing and firewall tables. For the first tunnel, it is:
u2010-rtr01 ~ # ifconfig
eth0 Link encap:Ethernet HWaddr 00:04:AC:96:E3:00
inet addr:10.20.10.254 Bcast:10.20.10.255 Mask:255.255.255.0
inet6 addr: 2001:7b8:3bf:1::1/64 Scope:Global
inet6 addr: fe80::204:acff:fe96:e300/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:300 errors:0 dropped:0 overruns:0 frame:0
TX packets:3481 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:43483 (42.4 Kb) TX bytes:376566 (367.7 Kb)
eth1 Link encap:Ethernet HWaddr 00:50:04:4B:5D:A2
inet addr:192.168.130.22 Bcast:192.168.130.255 Mask:255.255.255.0
inet6 addr: fe80::250:4ff:fe4b:5da2/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:10990 errors:0 dropped:0 overruns:0 frame:0
TX packets:3029 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:862506 (842.2 Kb) TX bytes:428718 (418.6 Kb)
Interrupt:9 Base address:0xaf80
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:180 errors:0 dropped:0 overruns:0 frame:0
TX packets:180 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:31974 (31.2 Kb) TX bytes:31974 (31.2 Kb)
u2010-rtr01 ~ # ip route
192.168.130.0/24 dev eth1 proto kernel scope link src 192.168.130.22
10.20.10.0/24 dev eth0 proto kernel scope link src 10.20.10.254
127.0.0.0/8 dev lo scope link
default via 192.168.130.254 dev eth1
u2010-rtr01 ~ # ip -6 route
2001:7b8:2ff:175::/64 dev sixxs metric 256 expires 21333525sec mtu 1280 advmss 1220 hoplimit 4294967295
2001:7b8:3bf:1::/64 dev eth0 metric 256 expires 21311918sec mtu 1500 advmss 1440 hoplimit 4294967295
2001:7b8:3bf:2::/64 via 2001:7b8:3bf:1:20a:9dff:fe00:9b29 dev eth0 metric 1024 expires 21311918sec mtu 1500 advmss 1440 hoplimit 4294967295
fe80::/64 dev eth0 metric 256 expires 21311914sec mtu 1500 advmss 1440 hoplimit 4294967295
fe80::/64 dev eth1 metric 256 expires 21311920sec mtu 1500 advmss 1440 hoplimit 4294967295
fe80::/64 dev sixxs metric 256 expires 21333525sec mtu 1280 advmss 1220 hoplimit 4294967295
ff00::/8 dev eth0 metric 256 expires 21311914sec mtu 1500 advmss 1440 hoplimit 4294967295
ff00::/8 dev eth1 metric 256 expires 21311920sec mtu 1500 advmss 1440 hoplimit 4294967295
ff00::/8 dev sixxs metric 256 expires 21333525sec mtu 1280 advmss 1220 hoplimit 4294967295
default via 2001:7b8:2ff:175::1 dev sixxs metric 1024 expires 21333525sec mtu 1280 advmss 1220 hoplimit 4294967295
There is no firewall installed on the machine.
* Include a IPv4 and IPv6 traceroute to the PoP in question. Both traceroutes are in the "aiccu test" above.
* With heartbeat tunnels, first check clock synchronization or better: use AICCU. I'm using aiccu. In addition there is NTP running on the machine.
* Check with Wireshark or tcpdumps of the interface over which the tunnel runs. Use -n (numeric) as an option and don't filter returning ICMP which could also come from routers between your endpoint and the PoP and also use -s 1500 so that one gets the full packet.
The tunnel runs over the interface eth1:
u2010-rtr01 ~ # tcpdump -i eth1 -n
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 96 bytes
19:17:00.035978 IP 192.168.130.22.32768 > 192.168.130.254.53: 36063+% [1au] AAAA? www.switch.ch. (42)
19:17:00.092886 IP 192.168.130.254.53 > 192.168.130.22.32768: 36063 2/0/0 CNAME aslan.switch.ch., (79)
19:17:00.096805 IP 192.168.130.22.32815 > 193.109.122.244.5072: UDP, length 148
19:17:00.205960 IP 193.109.122.244.5072 > 192.168.130.22.32815: UDP, length 148
19:17:00.207289 IP 193.109.122.244.5072 > 192.168.130.22.32815: UDP, length 148
19:17:01.095772 IP 192.168.130.22.32815 > 193.109.122.244.5072: UDP, length 148
19:17:01.201795 IP 193.109.122.244.5072 > 192.168.130.22.32815: UDP, length 148
19:17:01.203262 IP 193.109.122.244.5072 > 192.168.130.22.32815: UDP, length 148
19:17:02.095385 IP 192.168.130.22.32815 > 193.109.122.244.5072: UDP, length 148
19:17:02.201857 IP 193.109.122.244.5072 > 192.168.130.22.32815: UDP, length 148
19:17:02.203324 IP 193.109.122.244.5072 > 192.168.130.22.32815: UDP, length 148
19:17:03.095408 IP 192.168.130.22.32815 > 193.109.122.244.5072: UDP, length 148
19:17:03.203405 IP 193.109.122.244.5072 > 192.168.130.22.32815: UDP, length 148
19:17:03.204872 IP 193.109.122.244.5072 > 192.168.130.22.32815: UDP, length 148
Tcpdump of the tunnel itself:
u2010-rtr01 ~ # tcpdump -n -i sixxs
tcpdump: WARNING: arptype 65534 not supported by libpcap - falling back to cooked socket
tcpdump: WARNING: sixxs: no IPv4 address assigned
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on sixxs, link-type LINUX_SLL (Linux cooked), capture size 96 bytes
19:15:57.998252 IP6 2001:7b8:2ff:175::2 > 2001:620:0:14::c: ICMP6, echo request, seq 1, length 64
19:15:58.106836 IP6 2001:620:0:14::c > 2001:7b8:2ff:175::2: ICMP6, echo reply, seq 1, length 64
19:15:58.108598 IP6 2001:620:0:14::c > 2001:7b8:2ff:175::2: ICMP6, echo reply, seq 1, length 64
19:15:58.997246 IP6 2001:7b8:2ff:175::2 > 2001:620:0:14::c: ICMP6, echo request, seq 2, length 64
19:15:59.104711 IP6 2001:620:0:14::c > 2001:7b8:2ff:175::2: ICMP6, echo reply, seq 2, length 64
19:15:59.106440 IP6 2001:620:0:14::c > 2001:7b8:2ff:175::2: ICMP6, echo reply, seq 2, length 64
19:15:59.996234 IP6 2001:7b8:2ff:175::2 > 2001:620:0:14::c: ICMP6, echo request, seq 3, length 64
19:16:00.101814 IP6 2001:620:0:14::c > 2001:7b8:2ff:175::2: ICMP6, echo reply, seq 3, length 64
19:16:00.103587 IP6 2001:620:0:14::c > 2001:7b8:2ff:175::2: ICMP6, echo reply, seq 3, length 64
* The status of the PoP is listed on the PoP Status page, if it is marked down there we are aware of the issue and we will try to resolve it as soon as possible. Additionally other issues are listed in the Ticket Tracker Ticket Tracker. Nothing marked there.
* We are not your personal helpdesk, thus first read the FAQ and/or use the forum, many cases can already be solved that way, but we do want to have you actually use the tunnel thus do contact us if the problem persists. Well, the tunnel now "works" again (I did not change anything), but I get duplicate packets...
best regards,
Dan
|
![[ch]](/s/countries/ch.gif)
on Sunday, 16 March 2008 15:45:58
Posting is only allowed when you are