Hey all! I'm trying to figure out exactly how to characterize the Cogent<->Google IPv6 split/dispute.
The main question I'm trying to answer is: Is Google using BGP communities to withhold their IPv6 routes from Cogent in order to coerce them into a peering agreement, or is Google (as with HE.net) only paying for IPv4 transit from providers that, in the IPv6 world, regard them as peers?
I was able to determine this in HE.net's case by looking at their communities+preference in Telia's LG. Their IPv4 routes have "customer" local preference (200) while their IPv6 routes have only "peering" local preference (150), and Hurricane isn't using any do-not-advertise communities on their v6 routes. So there isn't a "simple" configuration change that they can make to fix the partition (despite what I've seen Cogent sometimes allege), because Telia isn't even providing v6 transit service to HE.net.
Google (AS15169) seems to be in the same situation, but I want to make sure. Per Cogent's LG, Google's IPv4 routes arrive by way of Tata (AS6453 - is that Google's only transit provider?), and Tata's LG indicates that these are customer routes (as they have the 6453:50/customer community, not 6453:86/peer). I have tried to check the communities on Google's IPv6 routes but the looking glass appears to have a bug that prevents displaying any output.
Wondering if anybody here is in the know -- or has BGP peering with Tata to see the informational communities on Google's v6 routes -- who would be willing to elucidate. :)
No comments:
Post a Comment