Tunnel stopped working

mackmgg · February 05, 2011, 07:33:41 PM

I have a tunnel setup right now for both my /64 and /48, and today it just stopped working. I can't ping out from it, I can't do a traceroute, and I can't ping those IPs from another computer. I haven't changed any of the config though, it seems as though it randomly stopped working. I'm using a tunnel in Ashburn, VA.

Anyone else have this problem, or know what may be wrong?

ping6 from the server:

Quote[22:28:42] mack[tty0]~ $ ping6 he.net
PING he.net(he.net) 56 data bytes
^C
--- he.net ping statistics ---
4 packets transmitted, 0 received, 100% packet loss, time 3014ms

And a ping to the server from another computer:

Quoteping6 ipv6.mackgoodstein.com
PING6(56=40+8+8 bytes) 2001:470:8:a15:21b:63ff:fe95:3672 --> 2001:470:e31f::1234:1
Request timeout for icmp_seq=0
Request timeout for icmp_seq=1
Request timeout for icmp_seq=2
Request timeout for icmp_seq=3
^C
--- ipv6.mackgoodstein.com ping6 statistics ---
5 packets transmitted, 0 packets received, 100.0% packet loss

baryluk · February 06, 2011, 08:51:08 AM

I do not know. I have today some routing problems (over ipv4) to HE from my univeristy network, but It is probably only me. As in traceroute I see some loops way before HE networks.

mackmgg · February 06, 2011, 11:09:46 AM

Oh right, I forgot to include the result of a traceroute. This is what I get with that:

Quote[14:08:25] mack[tty0]~ $ traceroute6 he.net
traceroute to he.net (2001:470:0:76::2), 30 hops max, 40 byte packets
1 * * *
2 * * *
3 * * *
4 * * *
5 * * *
6 * * *
7 * * *
8 * * *
9 * * *
10 * * *
11 * * *
12 * * *
13 * * *
14 * * *
15 * * *
16 * * *
17 * * *
18 * * *
19 * * *
20 * * *
21 * * *
22 * * *
23 * * *
24 * * *
25 * * *
26 * * *
27 * * *
28 * * *
29 * * *
30 * * *

sasexprt · February 06, 2011, 11:54:37 AM

I've got the same problem starting about the same time. Frustrating to say the least. :'(

cconn · February 06, 2011, 12:14:48 PM

Quote from: mackmgg on February 06, 2011, 11:09:46 AM
Oh right, I forgot to include the result of a traceroute. This is what I get with that:
Quote[14:08:25] mack[tty0]~ $ traceroute6 he.net
traceroute to he.net (2001:470:0:76::2), 30 hops max, 40 byte packets

29 * * *
30 * * *

Any chance of seeing an ipv4 trace to the tunnel endpoint to see what is going on? This trace just shows that the tunnel to HE is down

cholzhauer · February 06, 2011, 01:43:41 PM

Did you check the tunnel server status page?

Have you emailed ipv6@he.net to see if they are any outages that they haven't posted yet?

mackmgg · February 07, 2011, 04:53:57 PM

Here's a traceroute to the tunnel from the server that doesn't work:

Quote[19:51:36] mack[tty0]~ $ traceroute 216.66.22.2
traceroute to 216.66.22.2 (216.66.22.2), 30 hops max, 40 byte packets
1 ool-addcd171.static.optonline.net (173.220.209.113) 2.937 ms 3.213 ms 3.518 ms
2 * * *
3 dstswr1-vlan2.rh.lwbony.cv.net (67.83.228.161) 12.569 ms 12.641 ms 12.622 ms
4 rtr1-ge1-10.mhe.whplny.cv.net (67.83.228.129) 15.342 ms 16.303 ms 16.364 ms
5 64.15.8.18 (64.15.8.18) 16.444 ms 16.498 ms 16.548 ms
6 rtr4-tg11-1.in.nycmny83.cv.net (64.15.0.41) 17.146 ms 10.315 ms 14.521 ms
7 core1.nyc4.he.net (198.32.118.57) 15.568 ms 15.627 ms 15.687 ms
8 10gigabitethernet2-3.core1.ash1.he.net (72.52.92.86) 30.187 ms 31.127 ms 31.182 ms
9 tserv13.ash1.ipv6.he.net (216.66.22.2) 22.741 ms 23.748 ms 23.626 ms

The part that I don't get is why it wouldn't be working on the server, but it works fine on my laptop in the same location:

QuoteMack-Goodsteins-MacBook-Pro:~ Mack$ traceroute 216.66.22.2traceroute to 216.66.22.2 (216.66.22.2), 64 hops max, 52 byte packets
1 192.168.1.1 (192.168.1.1) 180.641 ms 0.993 ms 0.798 ms
2 ool-addcd171.static.optonline.net (173.220.209.113) 1.494 ms 1.572 ms 1.469 ms
3 192.168.1.1 (192.168.1.1) 8.550 ms 10.303 ms 7.921 ms
4 dstswr2-vlan4.rh.lwbony.cv.net (67.83.228.194) 8.154 ms 9.256 ms 7.903 ms
5 rtr2-ge1-10.mhe.whplny.cv.net (67.83.228.133) 9.975 ms 10.130 ms 9.479 ms
6 64.15.8.90 (64.15.8.90) 12.243 ms 10.722 ms 12.185 ms
7 rtr4-tg11-1.in.nycmny83.cv.net (64.15.0.41) 11.919 ms 12.089 ms 11.995 ms
8 core1.nyc4.he.net (198.32.118.57) 20.338 ms 14.950 ms 24.728 ms
9 10gigabitethernet2-3.core1.ash1.he.net (72.52.92.86) 24.762 ms 18.071 ms 21.762 ms
10 tserv13.ash1.ipv6.he.net (216.66.22.2) 17.854 ms 17.674 ms 18.254 ms

thorvoquien · February 08, 2011, 05:55:54 AM

I am having similar problems. The tunnel didn't stop working but it suffers 60-75% packet loss and the round trip times are about double normal. This happens on two different machines with two different tunnels on two completely different networks. Here are two pings from my machine (going through the chicago tunnel) to a server with native v6 connectivity living in HE's Fremont data center.

Code Select

Thor:~ zaphoyd$ ping6 2001:470:1:41:a800:ff:fe3e:cddb
PING6(56=40+8+8 bytes) 2001:470:c141::1 --> 2001:470:1:41:a800:ff:fe3e:cddb
Request timeout for icmp_seq=0
Request timeout for icmp_seq=1
Request timeout for icmp_seq=2
16 bytes from 2001:470:1:41:a800:ff:fe3e:cddb, icmp_seq=3 hlim=57 time=135.253 ms
Request timeout for icmp_seq=4
Request timeout for icmp_seq=5
16 bytes from 2001:470:1:41:a800:ff:fe3e:cddb, icmp_seq=6 hlim=57 time=125.130 ms
Request timeout for icmp_seq=7
16 bytes from 2001:470:1:41:a800:ff:fe3e:cddb, icmp_seq=8 hlim=57 time=155.120 ms
Request timeout for icmp_seq=9
Request timeout for icmp_seq=10
16 bytes from 2001:470:1:41:a800:ff:fe3e:cddb, icmp_seq=11 hlim=57 time=155.060 ms
Request timeout for icmp_seq=12
Request timeout for icmp_seq=13
Request timeout for icmp_seq=14
^C
--- 2001:470:1:41:a800:ff:fe3e:cddb ping6 statistics ---
16 packets transmitted, 4 packets received, 75.0% packet loss
round-trip min/avg/max/std-dev = 125.130/142.641/155.120/12.954 ms

cholzhauer · February 08, 2011, 06:07:03 AM

That's strange...I'm also on the Chicago tunnel:

Code Select


[carl@mars ~]$ ping6 2001:470:1:41:a800:ff:fe3e:cddb
PING6(56=40+8+8 bytes) 2001:470:c27d:e000:20c:29ff:fe8a:1618 --> 2001:470:1:41:a800:ff:fe3e:cddb
16 bytes from 2001:470:1:41:a800:ff:fe3e:cddb, icmp_seq=0 hlim=57 time=188.945 ms
16 bytes from 2001:470:1:41:a800:ff:fe3e:cddb, icmp_seq=1 hlim=57 time=161.989 ms
16 bytes from 2001:470:1:41:a800:ff:fe3e:cddb, icmp_seq=2 hlim=57 time=190.631 ms
16 bytes from 2001:470:1:41:a800:ff:fe3e:cddb, icmp_seq=3 hlim=57 time=184.357 ms
16 bytes from 2001:470:1:41:a800:ff:fe3e:cddb, icmp_seq=4 hlim=57 time=185.673 ms
16 bytes from 2001:470:1:41:a800:ff:fe3e:cddb, icmp_seq=5 hlim=57 time=223.341 ms
16 bytes from 2001:470:1:41:a800:ff:fe3e:cddb, icmp_seq=6 hlim=57 time=229.988 ms
16 bytes from 2001:470:1:41:a800:ff:fe3e:cddb, icmp_seq=7 hlim=57 time=185.177 ms
16 bytes from 2001:470:1:41:a800:ff:fe3e:cddb, icmp_seq=8 hlim=57 time=161.286 ms
16 bytes from 2001:470:1:41:a800:ff:fe3e:cddb, icmp_seq=9 hlim=57 time=184.976 ms
16 bytes from 2001:470:1:41:a800:ff:fe3e:cddb, icmp_seq=10 hlim=57 time=151.438 ms
16 bytes from 2001:470:1:41:a800:ff:fe3e:cddb, icmp_seq=11 hlim=57 time=194.293 ms
16 bytes from 2001:470:1:41:a800:ff:fe3e:cddb, icmp_seq=12 hlim=57 time=207.892 ms
16 bytes from 2001:470:1:41:a800:ff:fe3e:cddb, icmp_seq=13 hlim=57 time=168.311 ms
16 bytes from 2001:470:1:41:a800:ff:fe3e:cddb, icmp_seq=14 hlim=57 time=125.260 ms
16 bytes from 2001:470:1:41:a800:ff:fe3e:cddb, icmp_seq=15 hlim=57 time=329.228 ms
16 bytes from 2001:470:1:41:a800:ff:fe3e:cddb, icmp_seq=16 hlim=57 time=199.030 ms
16 bytes from 2001:470:1:41:a800:ff:fe3e:cddb, icmp_seq=17 hlim=57 time=141.936 ms
16 bytes from 2001:470:1:41:a800:ff:fe3e:cddb, icmp_seq=18 hlim=57 time=179.187 ms
16 bytes from 2001:470:1:41:a800:ff:fe3e:cddb, icmp_seq=19 hlim=57 time=144.176 ms
16 bytes from 2001:470:1:41:a800:ff:fe3e:cddb, icmp_seq=20 hlim=57 time=175.419 ms
16 bytes from 2001:470:1:41:a800:ff:fe3e:cddb, icmp_seq=21 hlim=57 time=161.889 ms
16 bytes from 2001:470:1:41:a800:ff:fe3e:cddb, icmp_seq=22 hlim=57 time=124.293 ms
^C
--- 2001:470:1:41:a800:ff:fe3e:cddb ping6 statistics ---
24 packets transmitted, 23 packets received, 4.2% packet loss
round-trip min/avg/max/std-dev = 124.293/182.553/329.228/41.149 ms

jschweitzer · February 18, 2011, 12:26:46 PM

was this ever resolved?

recently, i figured out why my tunnel would randomly stop working... my IPv4 private address would change every few days. my 192.168.11.x would change. you have to update the tunnel to reflect the new IP. HE offers some script you can configure to make these changes automatically for you.

cholzhauer · February 18, 2011, 01:10:54 PM

They offer a script, but that's only to change the tunnel info on their end if your public info changes.

Really, if you're running a router, you should either set a static address or have a DHCP reservation

mackmgg · March 15, 2011, 02:26:59 PM

Well, rebooting solved it previously, but it's happening again now :/

Quote from: cholzhauer on February 18, 2011, 01:10:54 PM
They offer a script, but that's only to change the tunnel info on their end if your public info changes.

Really, if you're running a router, you should either set a static address or have a DHCP reservation

The server does have a static IP. The only thing I can think of is since it has 2 IPs that it may be connecting from the wrong one. No idea why that would happen randomly though

News:

Tunnel stopped working