Print

[qdeqde]

Hello

today i discovered that my tunnel is not working,no packets incoming
i verified my setup with wireshark that the proto 41 packets are outgoing.

Code: [Select]

traceroute to endpoint ip  216.66.86.122 tserv27.prg1
 5  100ge7-2.core1.fra1.he.net (80.81.192.172)  20.455 ms 20ge1-3.core1.prg1.he.net (91.210.16.201)  15.787 ms 100ge7-2.core1.fra1.he.net (80.81.192.172)  20.441 ms
 6  100ge5-1.core1.waw1.he.net (184.105.80.146)  24.902 ms 10ge2-1.core1.muc1.he.net (184.105.80.22)  29.236 ms 100ge5-1.core1.waw1.he.net (184.105.80.146)  23.740 ms
 7  10ge3-1.core1.ber1.he.net (184.105.213.226)  30.410 ms  36.531 ms 10ge1-3.core1.ber1.he.net (184.105.80.114)  33.118 ms
 8  * * *


Code: [Select]

ping -O tserv27.prg1.ipv6.he.net
PING tserv27.prg1.ipv6.he.net (216.66.86.122) 56(84) bytes of data.
no answer yet for icmp_seq=1
no answer yet for icmp_seq=2
no answer yet for icmp_seq=3
no answer yet for icmp_seq=4
no answer yet for icmp_seq=5
no answer yet for icmp_seq=6

ping 216.66.86.122 does only timeout

pinging the frankfurt server works

Code: [Select]

ping 216.66.80.30
PING 216.66.80.30 (216.66.80.30) 56(84) bytes of data.
64 bytes from 216.66.80.30: icmp_seq=1 ttl=59 time=13.3 ms
64 bytes from 216.66.80.30: icmp_seq=2 ttl=59 time=13.3 ms
tunnel server status says it is UP
tserv27.prg1   Prague, CZ   Up

can anyone help what could be the cause ?

Thank you.

User ID: 34bca5089be584f776a783f121b4dcaa
tunnel id : qdeqde-1.tunnel.tserv27.prg1.ipv6.he.net

[post-factum]

Same here. If it helps, traceroute is almost the same:

Code: [Select]

  3.|-- 20ge1-3.core1.prg1.he.net (91.210.16.201)                      0.0%     1   17.2  17.2  17.2  17.2   0.0
  4.|-- 100ge5-1.core1.waw1.he.net (184.105.80.146)                    0.0%     1   19.4  19.4  19.4  19.4   0.0
  5.|-- 10ge3-1.core1.ber1.he.net (184.105.213.226)                    0.0%     1   46.9  46.9  46.9  46.9   0.0
  6.|-- ???
Kindly ask about any info on it. Thanks.

[kastner]

Hello,

I have the same problem.

ping 216.66.86.122 is not working.

[janosec]

The same for me.

BGP looks OK, but routing to IP 216.66.86.122 go wrong way.

[janosec]

Case with support@he.net was logged with ID: [HE#3416807] and [HE#3417393]. No answers yet.

I would welcome if anyone could help.

[janosec]

Here are the outputs from http://lg.he.net/

core1.fra1.he.net> traceroute 216.66.86.122 source-ip 216.218.252.174 numeric
 
Tracing the route to IP node (216.66.86.122) from 1 to 30 hops

  1    32 ms   29 ms   20 ms 184.105.80.22
  2    24 ms   24 ms   29 ms 184.105.80.114
  3    *       *       *     ?
  4    *       *       *     ?
  5    *       *       *     ?
  6    *       *       *     ?
IP: Errno( Trace Route Failed, no response from target node.


# Entry cached for another 24 seconds.
core1.prg1.he.net> traceroute 216.66.86.122 source-ip 216.218.252.188 numeric
 
Tracing the route to IP node (216.66.86.122) from 1 to 30 hops

  1    17 ms   22 ms   24 ms 184.105.80.146
  2    26 ms   55 ms   23 ms 184.105.213.226
  3    *       *       *     ?
  4    *       *       *     ?
  5    *       *       *     ?
  6    *       *       *     ?
IP: Errno( Trace Route Failed, no response from target node.


# Entry cached for another 55 seconds.
core1.fmt1.he.net> traceroute 216.66.86.122 source-ip 216.218.252.161 numeric
 
Tracing the route to IP node (216.66.86.122) from 1 to 30 hops

  1     1 ms    2 ms   <1 ms 72.52.92.110
  2    80 ms   76 ms   72 ms 184.105.81.214
  3   153 ms  149 ms  150 ms 184.105.81.78
  4   163 ms  145 ms  141 ms 72.52.92.14
  5   154 ms  150 ms  151 ms 184.105.80.22
  6   181 ms  157 ms  184 ms 184.105.80.114
  7    *       *       *     ?
  8    *       *       *     ?
  9    *       *       *     ?
 10    *       *       *     ?
IP: Errno( Trace Route Failed, no response from target node.

# Entry cached for another 30 seconds.

[tjeske]

Same here (Saxony, East-Germany).

sorry, actually, I'm connecting to Berlin (216.66.86.114), but that is down as well!

[doktornotor]

Yeah, Prague has been down since ~ Feb 20 14:30 CET as well. Verified with 3 different locations/ISPs.

P.S. And the status monitoring page is either useless, or the monitoring scripts needs a rewrite. https://tunnelbroker.net/status.php

[broquea]

We are currently waiting on a remote hands request to complete at the facility to restore the tunnel server(s). No ETA as of yet, but we are aware of the issue.

[doktornotor]

We are currently waiting on a remote hands request to complete at the facility to restore the tunnel server(s). No ETA as of yet, but we are aware of the issue.

Thanks for info and quick response! 

[HECZ]

Endpoint in Prague (216.66.86.122) is down for a while (due to HW issue) and is anchored in Berlin (216.66.86.114). Now endpoint in Berlin is down too. :/ Unluckiness...

[tjeske]

But they failed at the same time, the same minute. It must be related, not unluckyness. Same/related hosting company maybe? (Berlin: IPB CarrierColo Berlin; Prague: CEColo/Sitel; however, Budapest is "CE Colo", so same as Prague?, but Budapest is working).

[HECZ]

tjeske: https://forums.he.net/index.php?topic=3572.0

[oskar]

But they failed at the same time, the same minute. It must be related, not unluckyness. Same/related hosting company maybe?

As I understand it, the tunnel server in Prague has been down since at least Jun 20, 2016 due to a hardware issue. To avoid service interruption, they moved service in Prague (including IPv4 endpoint address) to the server in Berlin. And what happened yesterday is that the server in Berlin failed. That is why both Prague and Berlin failed at the very same moment, because they were in fact the very same server. I would call this a double failure.

Too bad that even in 2017, we are still dependent on HE.net free service to do the job, that is supposed to be provided by the ISPs that we pay. 

[tjeske]

I do have native IPv6 at home. Just at university I need the tunnel, cause I couldn't convince the IT department to switch to IPv6. They'll do it eventually, but god knows when. However, they were so kind to allow my tunnel through the firewall.

Prague-server being now at Berlin is then probably also the reason why some services mistake me being from CZ. If they take usage patterns from genuine CZ users connecting to the Prague-server in Berlin, they might appear similar to mine (also, I'm not too far from the border, in case they're using ping times and such). Bit annoying at times, if I use services that rely on the false GeoIP-database. Thanks for the info.

As for the tunnel, the people in Berlin are most likely not working a night shift to resolve this (I'm not sure how the industry works, though). So they'll respond to the request tomorrow morning, and hopefully during the day, or latest by Thursday, the tunnel will be up again.