Hi,
I can't connect to the internet using the tunnelendpoint fra1. A ping6 to he.net or tunnelbroker.net results in packet loss (same with other IPv6-Sites). Traceroute6 shows me, that my Server IPv6 Address is the last one which can be reached. Pinging my second tunnel (allocated on my server; same endpoint) works great. But same symptoms into the internet. No connection to any other server.
The last time it lasts round about 8h and works than for a few days without problems. Did nothing to get it work just waited "a bit".
So what is going on here?
Email ipv6@he.net
I emailed ipv6@he.net about this both times, ticket number 1836708. When it happened four days ago, the problem was fixed, and I received a reply exactly three hours later. And today I emailed exactly three hours ago, and it looks like it just got fixed.
I do however find the thread useful in letting me know, that it is not only affecting me. Maybe next time something like that happen I should just start a thread myself mentioning that there is a ticket already. But then HE might not get to know how many people are affected.
It is down again. Ticket #1851294. It is not the same problem as last time. Last time the tunnel server had no IPv6 connectivity. This time it does seem to have IPv6 connectivity, but no IPv4 connectivity.
Does anybody know what http://tunnelbroker.net/status.php use to determine if a tunnel server is up or down? As far as I recall, it has shown both of the fra1 tunnel servers being up throughout all of these outages.
I would have thought whatever criteria was being used either would rely on IPv4 being up or would rely on IPv6 being up. But it appears to say up if just one of the two is up.
The status page reports that the tunnel-server is responding to probes, not the client's side of the tunnel status.
I see problems with fra1 again. It is not completely down. It is just that occasionally the packet loss through the tunnel server goes up between 20% and 25%. I filed ticket #1880341.
Quote from: broquea on March 14, 2012, 07:55:01 AMThe status page reports that the tunnel-server is responding to probes, not the client's side of the tunnel status.
Does it try both IPv4 and IPv6 probes such that it can report the tunnel server as up if either of the two is working? I would say a better way to test availability of the tunnel server is to run a client in a different pop and test connectivity between that client (using 6in4) and some other IPv6 address which is not located in the same pop as the tunnel server, neither using the same tunnel server. Assuming the system that does the collection of data is using native IPv6 it could just ping a client at each tunnel server to verify that connectivity is working.
How it tests is secret sauce, but suffice to say that what is publicly shown is an oversimplification of all the tests performed behind the scenes.