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

Apparent routing issue...

Started by dfrandin, May 29, 2015, 08:10:20 AM

Previous topic - Next topic

dfrandin

I have a Linux vps hosted with a vendor that supplies ipv6 addresses with their products. I have a AAAA record in my domain dns pointing to the statically assigned v6 address on the vps. A ping6 of the url returns the correct ipv6 address, but no ping/pong... At the moment, there is no ip6tables config. I'd complained to the vendor tech support that I was unable to access the server via ipv6 so they checked, and showed me screenshots of their being able to access it via cogent and ntt networks. Since my only ipv6 access currently is via a tunnelbroker 6to4 tunnel, I have no way of cross-checking this.. Ideas?

broquea

HE should have NTT peering up. Please provide hostname/IPs if you want us to test. Otherwise can't really come up with ideas other than either you misconfigured something, or your provider did.

dfrandin

Thanks... Sorry, should have put it in the original question.. The vps is hosted by Virpus Networks in Kansas City, the ip in question is  2604:c00:a:2:0:1:c0ab:61ed. As I said, I have an AAAA record in the domain dns that points to that address, ipv6.bestnewage.net.. Cannot ping/ssh/http to either the ip or the url...ipv4 works fine..

broquea


dfrandin

So could you ping it? Any idea why I can't? I get to everything else I've tried accessing thru the HE tunnel, except this...

Thanks

broquea

Cogent doesn't have a full IPv6 routing table/view, which includes HE.NET's network. Either that provider needs to add additional IPv6 transits that DO, or bug Cogent to peer with HE. Until then, networks single-homed behind Cogent cannot reach some IPv6 networks.

dfrandin

Ok.. Thanks!! I'll pass that info on to my vps vendor and see if they can troubleshoot it from their end, with the idea of *them* fixing
their system so the features I pay for actually *work*....

Thanks again

dfrandin

Further update on this issue and a question... I put a ticket in with the vps vendor and they claim to be "working" on the issue for going on a month.. Being that I'm curious, I did a google search for "routing hurricane electric cogent" and found all sorts of links pertaining to a peering dispute between Cogent & HE.. Now I'm also a noob when it comes to "big iron" routing, but I was always under the impression that the world-wide Internet was a kind of like a mesh network, and if one route to a host was missing other routes could get packets to the destination. Am I all wet behind the ears on this??? Curious minds want to know, if this is going to lead to "finger-pointing" by HE and Cogent...

evantkh

This problem is not only on HE.NET's network, and I want to know does all AS single-homed behind HE.NET have this problem.

broquea

#9
Of course, single-home behind 1 provider and you'll feel whatever pain is there. That is why any network worth its salt, gets multi-homed to at least 2 providers (or more), and doesn't rely on a single point of failure. Those customers that single-home, are likely in areas where either no other provider services, or they don't want to, or can't, spend the money or manhours properly multihoming. Which makes you wonder how/why they bothered to get an ASN in the first place if a default route would have worked just as well.

So yeah, to flip it on it's head and victim-blame a little, it isn't actually really HE or Cogent's fault anymore. Both are THE CHEAPEST BANDWIDTH YOU CAN BUY, relatively. Those single-homed networks should be properly connecting themselves with true multi-homed connections to various providers. Otherwise they do the disservice to themselves and their customers. I mean if their only connection to the internet goes down, poof, they're gone.

evantkh

#10
Quote from: broquea on June 17, 2015, 08:05:02 PM
Of course, single-home behind 1 provider and you'll feel whatever pain is there. That is why any network worth its salt, gets multi-homed to at least 2 providers (or more), and doesn't rely on a single point of failure. Those customers that single-home, are likely in areas where either no other provider services, or they don't want to, or can't, spend the money or manhours properly multihoming. Which makes you wonder how/why they bothered to get an ASN in the first place if a default route would have worked just as well.

So yeah, to flip it on it's head and victim-blame a little, it isn't actually really HE or Cogent's fault anymore. Both are THE CHEAPEST BANDWIDTH YOU CAN BUY, relatively. Those single-homed networks should be properly connecting themselves with true multi-homed connections to various providers. Otherwise they do the disservice to themselves and their customers. I mean if their only connection to the internet goes down, poof, they're gone.

However, why HE.NET prefix is unable to be announced in Cogent network? Although there is no peering between HE and Cogent, both have some common peers like NTT.

broquea

#11
Because HE doesn't use anyone for IPv6 transit. They openly peer with any network that has a pulse and IPv6 (and legacy IPv4). Cogent actively refuses to peer, and not just with HE.

evantkh

Quote from: broquea on June 18, 2015, 02:58:56 AM
Because HE doesn't use anyone for IPv6 transit. They openly peer with any network that has a pulse and IPv6 (and legacy IPv4). Cogent actively refuses to peer, and not just with HE.
Actually, what is the difference between peering and transit in terms of the technology? It seems that both of them are using BGP.

broquea

Paying someone to reach other networks (transit), versus not paying (peering).

evantkh

Quote from: broquea on June 18, 2015, 06:19:52 AM
Paying someone to reach other networks (transit), versus not paying (peering).
Although there is no direct peering between HE and Cogent, why packets cannot be routed through other peers like NTT, Level 3 etc.? And I can see Cogent prefixes is announced in HE.NET's network.

If direct peering is really necessary, how to explain the following?

My IPv4 network is on AS9269, and there is no peering session to HGC according to http://bgp.he.net/AS9269#_peers
When I do a traceroute to an IP in AS4807, the forward route passes through HKIX and then HGC and finally AS4807.