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
Quote from: PaulosV on June 05, 2013, 02:21:49 PMThe destination AS is AS30071.
Looks like HE is peering directly with that AS. http://bgp.he.net/AS30071#_peers6
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 * * *
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.
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.
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.
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.
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.
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.
Wonderful!
Is this issue related to that I can not reach tunnel endpoint with IP address 216.66.80.90?
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)
Missing routes to AS6939.
AS6939 MISSING! 216.66.80.0/20
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): (http://www.thinkbroadband.com/ping/share-large/e276f56ab89b9ec08bc5a4f2df7df6b4-12-06-2013.png)
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.
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
I am having the same issue through all of my HE tunnels. From dual-homed hosts I can access v6.testmyipv6.com (2001:4830:2502:8002::ac10:a) just fine. Traceroutes are normal and it responds to pings.
However, from my two tunnels, I get the following:
traceroute to v6.testmyipv6.com (2001:4830:2502:8002::ac10:a) from 2001:470:67:6ef:1c69:a0ba:f826:d7d9, 30 hops max, 24 byte packets
1 ares.abq.siriuscloud.co (2001:470:67:6ef::1) 0.501 ms 0.429 ms 0.39 ms
2 kasimir-2.tunnel.tserv29.fmt1.ipv6.he.net (2001:470:66:6ef::1) 58.476 ms 57.894 ms 58.868 ms
3 ge5-1.core1.fmt1.he.net (2001:470:0:206::1) 56.388 ms 75.192 ms 65.816 ms
4 * * *
5 * * *
6 * * *
...
and
traceroute6 v6.testmyipv6.com
traceroute to v6.testmyipv6.com (2001:4830:2502:8002::ac10:a) from 2001:470:b:1e7::3010, 30 hops max, 24 byte packets
1 2001:470:b:1e7::2000 (2001:470:b:1e7::2000) 0.376 ms 0.358 ms 0.355 ms
2 kasimir-1.tunnel.tserv14.sea1.ipv6.he.net (2001:470:a:1e7::1) 22.611 ms 22.784 ms 22.614 ms
3 ge2-6.core1.sea1.he.net (2001:470:0:9b::1) 21.138 ms 21.334 ms 21.346 ms
4 * * *
5 * * *
6 * * *
...
This seems to impact much more than just testmyipv6.com. Any help would be appreciated.
TowardEX doesn't appear to be announcing the /32 or /48 the destination resides in to HE.NET (even though they appear to peer):
route-server> sh ipv6 bgp 2001:4830:2502:8002::ac10:a
% Network not in table
route-server> sh ipv6 bgp 2001:4830:2502::/48
% Network not in table
route-server> sh ipv6 bgp 2001:4830::/32
% Network not in table
This is something TowardEX fixes.