Can't reach v6.testmyipv6.com with IPv6 tunnel

[PaulosV]

Hi everyone,
I'm having a kind of strange issue with the tunneled IPv6 connection. It had been flawless until now, when I wanted to try out the v6.testmyipv6.com webpage.

The interned browsers couldn't connect and I was curious why. And here's what I found using traceroute:

Code Select Expand

$ nmap -sn -Pn -6 --traceroute v6.testmyipv6.com

Starting Nmap 6.25 ( http://nmap.org ) at 2013-06-05 21:30 ope
Nmap scan report for v6.testmyipv6.com (2001:4830:2502:8002::ac10:a)
Host is up.
rDNS record for 2001:4830:2502:8002::ac10:a: srv01.lal.lwxdatacom.net

TRACEROUTE (using proto 58/ipv6-icmp)
HOP RTT       ADDRESS
1   0.00 ms   2001:470:6f:54::1
2   8.00 ms   paulosv-2.tunnel.tserv27.prg1.ipv6.he.net (2001:470:6e:54::1)
3   7.00 ms   gige-g2-20.core1.prg1.he.net (2001:470:0:221::1)
4   15.00 ms  10gigabitethernet5-2.core1.fra1.he.net (2001:470:0:213::1)
5   29.00 ms  10gigabitethernet5-3.core1.lon1.he.net (2001:470:0:1d2::1)
6   109.00 ms 10gigabitethernet10-4.core1.nyc4.he.net (2001:470:0:128::1)
7   116.00 ms 100gigabitethernet7-2.core1.chi1.he.net (2001:470:0:298::1)
8   168.00 ms 10gigabitethernet11-4.core1.pao1.he.net (2001:470:0:283::1)
9   ... 30

Nmap done: 1 IP address (1 host up) scanned in 20.24 seconds

It seems that the route is broken somewhere right after HE's routers. The destination AS is AS30071.

I wasn't satisfied with this result since Google could see the page and offered it to me in the search results. So I tried some random online traceroute. That offered a bit different result (4or6.com):

Code Select Expand

#traceroute -6  -I 2001:4830:2502:8002::ac10:a
traceroute to 2001:4830:2502:8002::ac10:a (2001:4830:2502:8002::ac10:a), 30 hops max, 80 byte packets
1  2607:f2f8:1600::1 (2607:f2f8:1600::1)  3.993 ms  3.841 ms  3.816 ms
2   (2001:504:13::8)  5.245 ms  5.228 ms  5.197 ms
3  bbr01-p1-2.dlls01.occaid.net (2001:4830:ff:e101::2)  36.698 ms  36.820 ms  37.004 ms
4  2001:4830:e4:17::2 (2001:4830:e4:17::2)  86.180 ms  86.175 ms  86.155 ms
5  srv01.lal.lwxdatacom.net (2001:4830:2502:8002::ac10:a)  81.018 ms  81.035 ms  81.015 ms

It almost seems like HE.net doesn't have a connectivity (maybe no route) to this particular hoster. Could it be true? Traceroute from Looking Glass also stops after the gigabit entries. How can I find out what's exactly going on?

Thanks!
Pavel

[kasperd]

The destination AS is AS30071.

Looks like HE is peering directly with that AS. http://bgp.he.net/AS30071#_peers6

[malamber]

I'm having the same issue for a few days now.  What's the deal?

Code Select Expand


traceroute to ashaman (2001:4830:3000:2:204:8ff:fe08:1108), 30 hops max, 80 byte packets
1  malamber-1.tunnel.tserv13.ash1.ipv6.he.net (2001:470:7:1124::1)  29.159 ms  32.726 ms  33.391 ms
2  gige-g4-12.core1.ash1.he.net (2001:470:0:90::1)  40.969 ms  40.955 ms  42.059 ms
3  10gigabitethernet12-7.core1.chi1.he.net (2001:470:0:286::1)  48.586 ms  48.572 ms  56.453 ms
4  10gigabitethernet11-4.core1.pao1.he.net (2001:470:0:283::1)  111.381 ms  111.142 ms  111.346 ms
5  * * *


[broquea]

Simple, the prefix isn't getting announced to HE:

Code Select Expand


~$ telnet route-server.he.net
Trying 2001:470:0:cf::2...
Connected to route-server.he.net.
--snip MOTD--
route-server> sh ipv6 bgp 2001:4830::/32
% Network not in table


HE can't make someone announce prefixes to them.

What HE can do is contact that network's POC/NOC and mention that their users are complaining that they can't reach a particular destination in that network, and see if it can get resolved.

[PaulosV]

Oh, that's bummer. I wasn't quite sure on how to find out exactly. Now I know. Thanks!

How to complain though? Will an email to HE be sufficient? I think it could be, especially when there's a non-functional IPv6 connectivity test with that prefix.

[PaulosV]

OK, sent a mail and got a quick response:

Ultimately, control of the announcement of that specific prefix is up to
OCCAID.  They announce pieces of the /32, but not the portion containing
that address.  I'll see if there's some reason for that from them.

[kasperd]

Simple, the prefix isn't getting announced to HE

In that case I'd have expected to see some ICMPv6 error codes coming back.

I checked a few other networks, and I found one network where I would also see packet loss, as well as two networks that could successfully traceroute all the way to the server.

[mhwarfield]

This has been an on again / off again problem for ages.  Infrequent but frustrating for everyone for sure.

I've mentioned it to the OCCAID NOC before.  I think it was James over there told me that there was something unusual in the BGP setup from HE.  He didn't give me details and that was several years ago.

They (OCCAID) require that I actively BGP peer with them and advertise my assigned /48 (which, at the time, HE didn't even allow for individual BGP peering, which I needed) to them.  That should be aggregated into the larger /32 such that my advertisements never hit the core routing tables and should have no effect on this.  AFACT, my BGP daemon is up and squaking  quite happily with my OCCAID POP and I can ping6 SixXs and ARIN, so that seems to be routing fine into other areas of the v6 net.

I have another message into their NOC to see if they can tell me what's going on from this side.

[mhwarfield]

I got a reply from James over at OCCAID.  They are aware of the problem and are working to resolve it.  He's promising to follow up with updates soon.

[PaulosV]

Wonderful!

[STH1]

Is this issue related to that I can not reach tunnel endpoint with IP address 216.66.80.90?

[jthnetdkeu]

All day June 12th there has been no connection to 216.66.80.90

trraceroute is stopping at
ae0-0.ldn4nqp1.uk.ip.tdc.net (83.88.25.27)

[STH1]

Missing routes to AS6939.

Code Select Expand

AS6939    MISSING!    216.66.80.0/20

[kasperd]

trraceroute is stopping at
ae0-0.ldn4nqp1.uk.ip.tdc.net (83.88.25.27)

TDC had an outage which for me lasted 11 hours as observed from thinkbroadband through my tunnel on the Stockholm tunnel server (216.66.80.90):

I only noticed this during the last hour where the outage got worse. During that last hour of the outage 80.160.0.0/13 was unreachable through all IPv4 networks I tested it from.

From the limited observations I have from the first 10 hours of the outage, it is possible that at that time only IPv4 packets from HE to TDC were affected.

[wildlava]

This topic is rather old, but I just ran into the same issue, so it seems it is ongoing:

PING v6.testmyipv6.com(srv01.lal.lwxdatacom.net) 56 data bytes
^C
--- v6.testmyipv6.com ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 2007ms