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