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?
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.
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..
Single-homed behind Cogent: http://bgp.he.net/AS32875
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
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.
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
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...
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.
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.
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.
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.
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.
Paying someone to reach other networks (transit), versus not paying (peering).
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.
Quote from: broquea on June 18, 2015, 06:19:52 AM
Paying someone to reach other networks (transit), versus not paying (peering).
Being a noob on the whole big world of internet routing, that is one concept I was never really clear about.. Thanks for putting it so simply.. In other words, Cogent, the bandwidth provider my vps vendor connects to, does not peer with anybody, they require explicit paid contracts "transit" for carrying data to/from other networks, and HE simply says "hey. I'll send your traffic if you send mine.." ie: "peering".. The term used earlier "single-homed behind Cogent" I believe means there *is* no other route to/from the greater internet *other* than thru Cogent... In which case, perhaps I better investigate Sixxs's 4to6 tunnel product if I want to be able to access my vps via ipv6 anytime soon, assuming Sixxs has full routing view...
Dfrandin:
No no no no no, Cogent DOES peer with other networks, just more selectively, and in some cases requires others pay them to access their chunk of the internet (paid peering, transit, etc). HE openly peers with anyone that wants to (open peering policy versus selective), or sells transit (no paid peering product). Your provider pays Cogent to access the internet as their transit provider.
Sixxs doesn't actually operate a network, they deploy POPs into other network operators' locations and utilize their connectivity.
evantkh:
I already explained why IPv6 packets can't be routed between HE and Cogent: neither HE or Cogent PAY another network to deliver IPv6 traffic to other networks (transit). And you see those partial Cogent routes because some Cogent customers got an LOA (letter of authorization) issued from Cogent, to re-announce that IPv6 space to other BGP networks; like HE, NTT, etc. You need a better basic understanding of both how BGP works, as well as the overall internet design. The IPv4 example shows exactly how both transit and peering work. Your provider buys transit from their upstream ASN, who then in turn peers off that traffic to the destination either for free or paid (you'll never know).
Quote from: broquea on June 18, 2015, 07:14:08 AM
evantkh:
I already explained why IPv6 packets can't be routed between HE and Cogent: neither HE or Cogent PAY another network to deliver IPv6 traffic to other networks (transit). And you see those partial Cogent routes because some Cogent customers got an LOA (letter of authorization) issued from Cogent, to re-announce that IPv6 space to other BGP networks; like HE, NTT, etc. You need a better basic understanding of both how BGP works, as well as the overall internet design. The IPv4 example shows exactly how both transit and peering work. Your provider buys transit from their upstream ASN, who then in turn peers off that traffic to the destination either for free or paid (you'll never know).
Then why HE.NET is able to see AS174 peers and even the prefixes under this ASN?(on bgp.he.net)
HKIX is a transit!!! or ISPs have direct BGP sessions between each other on HKIX subnet, bypassing HKIX routers?
When I do a BGP route lookup on lg.he.net(selecting Hong Kong as the location), looking up 121.202.1.1, I see HE.NET is directly having BGP session with SmarTone but the next hop is a HKIX IP address.
After looking for some information online, is it correct to say the following?
1. When I am using a transit service from HE.NET, my prefix will be announced to other networks connected with HE.NET with BGP sessions as my own ASN and I can access other networks like Level 3 through HE.NET network. Since HE.NET is peering with Level 3 network, I will not be able to reach other networks behind Level 3.
2. When I am peering with HE.NET, my prefix will not be announced to other networks connected with HE.NET with BGP sessions as my own ASN and I need to add another peering line to Level 3 to access Level 3 network. And also cannot receives routes from other networks in the BGP session with HE.NET.
bgp.he.net is based off data from public sources, and not views from within HE itself, as to avoid bias.
A network (normally) announces its own routes, and the routes of its customers to a peer. A network (usually) would announce its complete routes (including those learned from a peer) to a customer. There are some variances on these, but that's pretty much the rule for 99.9% of those relationships.
So in the case where you have networks A and C peering with B: A sees B's routes, and B's customer's routes; C sees B's routes and B's customer routes; and B sees both A and C's routes and A and C's customer routes. If B announces A to C, then B is providing transit for A. If this is not something intended by A, then this is a leak, and extremely poor form for B to do and is a big faux pas (and sometimes cause for A to depeer B).
Quote from: kcochran on June 18, 2015, 08:08:46 AM
bgp.he.net is based off data from public sources, and not views from within HE itself, as to avoid bias.
A network (normally) announces its own routes, and the routes of its customers to a peer. A network (usually) would announce its complete routes (including those learned from a peer) to a customer. There are some variances on these, but that's pretty much the rule for 99.9% of those relationships.
So in the case where you have networks A and C peering with B: A sees B's routes, and B's customer's routes; C sees B's routes and B's customer routes; and B sees both A and C's routes and A and C's customer routes. If B announces A to C, then B is providing transit for A. If this is not something intended by A, then this is a leak, and extremely poor form for B to do and is a big faux pas (and sometimes cause for A to depeer B).
Thanks.
So if I only use peering, I need to peer with all Tier 1 networks to reach the whole internet, and if I use transit, connect to a few transit providers will be enough. Am I correct?
He just said, because HE nor Cogent pay for IPv6 transit.
Cogent is basically IPv6 clueless. They had an assigned IPv6 allocation for about 6 years go unused because no one enabled IPv6 in their routers. They'd rather live in an IPv4-only world than upgrade.