• Welcome to Hurricane Electric's IPv6 Tunnel Broker Forums.

News:

Welcome to Hurricane Electric's Tunnelbroker.net forums!

Main Menu

Tunnel stopped working

Started by mackmgg, February 05, 2011, 07:33:41 PM

Previous topic - Next topic

mackmgg

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

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

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

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

cconn

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

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

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

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.

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

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


[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

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

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

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