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

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

Started by PaulosV, June 05, 2013, 02:21:49 PM

Previous topic - Next topic

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:

$ 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):
#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


malamber

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


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

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


~$ 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:

QuoteUltimately, 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

Quote from: broquea on June 08, 2013, 12:07:39 PMSimple, 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


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.

AS6939    MISSING!    216.66.80.0/20

kasperd

Quote from: jthnetdkeu on June 12, 2013, 09:07:15 AMtrraceroute 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