Routing to ARIN from Teleglobe (2001:5a0::/32)
Bernhard Schmidt
berni at birkenwald.de
Sun Feb 11 18:06:10 CET 2007
On Sun, Feb 11, 2007 at 11:44:51AM -0500, Randy Epstein wrote:
> >> OCCAID can't reach Teleglobe as it isn't in their routing tables.
> Teleglobe can't reach OCCAID,
Yes they can (shortened, from the second posting by nenad in this
thread):
| 7 zpr2.amt.cw.net (2001:7f8:1::a500:1273:1) 45.544 ms
| 8 as0-dcr2.amd.cw.net (2001:5000:0:11::2) 45.460 ms
| 9 so-4-0-0-dcr1.tsd.cw.net (2001:5000:0:20::2) 52.230 ms
| 10 * * *
Hop 10 would be OCCAID in London.
> OCCAID can't reach Teleglobe.
That is correct. Because it is not in the routing table of OCCAID.
> Hmm. Maybe they should peer?a
Valid conclusion. Thing is, both 1273 (Cable and Wireless) and 3257
(Tiscali) send a fulltable to OCCAID, and both have a direct peering
with Teleglobe (and of course both have it in the table). So why are
those prefixes not accepted?
> OCCAID *is* an R&D network that provides IPv6 connectivity to many
> institutions. If you are a customer of Teleglobe and you can't reach
> OCCAID, I think you should be taking out your frustration on Teleglobe. You
> PAY Teleglobe for connectivity, not OCCAID.
There is nothing Teleglobe can do about this, because the Teleglobe
routing is sane. Well, except peering up OCCAID. But I don't know why
entities like ARIN have to be single-homed behind an R&D network.
www.arin.net resolves to two IPv4 prefixes, one is single-homed behind
Sprint (not a great IPv6 transit, but better than nothing), one has at
least GBLX and Verio as upstream, both pretty sane IPv6 transits.
> >Along with a lot more than one hundred other allocations. Thanks to
> >Jeroen there is a nifty tool to analyze the situation
> >http://www.sixxs.net/tools/grh/dfp/all/?missing=30071
> According to Jeroen's tool, the number is 63. Out of those 63, 30 of those
> prefixes are not seen by most (some are exchange (IX) prefixes, some are
> just not routed to the Internet as a whole, etc). This leaves 33, with most
> likely half being resolved if Teleglobe would peer with OCCAID.
I bet both of my hands that the number used to be around 150 yesterday.
Wait, not only yesterday, this has been an issue since (grepping IRC
logs) at least mid-August 2006. OCCAID have been missing quite some
routes since then, now they are apparently starting to fix it.
Jeroen, is there a way to get the "Missing prefixes" thing for a past
date?
> Teleglobe is the one flaunting the restrictive peering policy, whereas
> OCCAID has taken a more reasonable approach. Maybe these two networks
> should just get a room, eh?
Is this 6bone where you throw a tunnel/peering to anyone you want to
exchange traffic with because the available transits might be broken?
:-)
I'm not here to blame OCCAID (this time), but finger-pointing to
Teleglobe in this case is utter bullsh*t. The missing of half a
fulltable at OCCAID has been widely known for months now.
Regards,
Bernhard
More information about the ipv6-ops
mailing list