Unable to access google services over IPv6 via tserv24.sto1

[TAtari]

I can't access most of Googles services over IPv6... www.google.com isn't reachable but the main page of www.youtube.com is... but some of the resource servers isn't so it will show up with a lot of broken images.
This started after the problems tserv24.sto1 had.

Code Select Expand


Tracing route to www.google.com [2a00:1450:400f:801::1012]
over a maximum of 30 hops:

  1    <1 ms    <1 ms    <1 ms  2001:470:28:dbf:11::1
  2    11 ms    10 ms    10 ms  2001:470:27:dbf::1
  3    13 ms     8 ms    14 ms  2001:470:0:11e::1
  4    16 ms    21 ms    25 ms  2001:470:0:2ad::2
  5    30 ms    30 ms    42 ms  2001:470:0:2ac::1
  6    74 ms    78 ms    76 ms  2001:7f8::3b41:0:2
  7    32 ms    34 ms    31 ms  2001:4860::1:0:4ca3
  8    32 ms    60 ms    37 ms  2001:4860::8:0:5039
  9    49 ms    49 ms    49 ms  2001:4860::8:0:2e9c
10    62 ms    63 ms    62 ms  2001:4860::8:0:4fc8
11    62 ms    63 ms    63 ms  2001:4860::1:0:26eb
12    63 ms    67 ms    63 ms  2001:4860:0:1::2f3
13     *        *        *     Request timed out.
14  ^C


If I use another IPv6 link it works fine to access Google services

Via ping via tserv24.sto1

Code Select Expand


Pinging 2a00:1450:400f:801::1012 with 32 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Request timed out.

Ping statistics for 2a00:1450:400f:801::1012:
    Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),


Other link:

Code Select Expand


PING 2a00:1450:400f:801::1012(2a00:1450:400f:801::1012) 32 data bytes
40 bytes from 2a00:1450:400f:801::1012: icmp_seq=0 ttl=54 time=34.5 ms
40 bytes from 2a00:1450:400f:801::1012: icmp_seq=1 ttl=54 time=27.9 ms
40 bytes from 2a00:1450:400f:801::1012: icmp_seq=2 ttl=54 time=28.4 ms
40 bytes from 2a00:1450:400f:801::1012: icmp_seq=3 ttl=54 time=28.0 ms

--- 2a00:1450:400f:801::1012 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3012ms
rtt min/avg/max/mdev = 27.981/29.757/34.530/2.765 ms, pipe 2


[svenix]

There have been some stability issues with the Stockholm tunnelserver as you can read about in this thread:
https://www.tunnelbroker.net/forums/index.php?topic=3093.0

[kasperd]

There have been some stability issues with the Stockholm tunnelserver

The issue with the Stockholm server appears to have been resolved before this thread started. Moreover the symptoms presented in this thread indicate a problem far from the Stockholm tunnel server.

[kasperd]

I can confirm that 2a00:1450:400f:801::1012 is unreachable through a tunnel on the Stockholm server, but it is reachable through a tunnel on a different tunnel server. The next to last hop, from the source where it works is 2001:4860:0:1::2f3, that happens to be the last responding hop, when doing a traceroute from the Stockholm tunnel server.

Based on this it sounds like the route to 2a00:1450:400f:801::1012 is probably working, and if there is a routing problem, it is on the path from Google back to the tunnel server. But there is a working path back to HE, because otherwise it would not work from another tunnel.

Based on this, I think it is likely that either there is a routing problem inside the HE network, or Google is treating packets from HE users differently depending on which subrange of 2001:470::/32 they belong to.

I suggest you file a ticket with HE about the issue, you are seeing. I suggest that for two reasons. HE can verify if there is actually a routing problem inside the HE network. Additionally, they know if they are announcing longer prefixes on peerings with Google, which could explain why packets destined for different tunnel servers get different treatment.