Canarie / 2001:410::/32 (Was: Filters) (fwd)
William F. Maton Sotomayor
wmaton at ryouko.imsb.nrc.ca
Tue May 24 16:49:51 CEST 2005
Thanks to Jeroen's fine forensic work, looks like some AS's are having
some problems between each other. Of course, none of this would have been
noticed had my prospective peering with sixxs.net not been tested first
with a simple traceroute.
In short, I cannot reach 2001:838:1:1:210:dcff:fe20:7c7c from, for
example, 2001:410:9000:127::10.
wfms
---------- Forwarded message ----------
Date: Tue, 24 May 2005 15:05:37 +0200
From: Jeroen Massar <jeroen at unfix.org>
To: William F. Maton Sotomayor <wmaton at ryouko.imsb.nrc.ca>
Cc: Richard <rh at concepts.nl>, Joris Vandalon <joris at io.nl>
Subject: Canarie / 2001:410::/32 (Was: Filters)
On Tue, 2005-05-24 at 07:52 -0400, William F. Maton Sotomayor wrote:
> On Tue, 24 May 2005, Jeroen Massar wrote:
>
>> [can I invite ISP's who are not peering with GRH to peer with the
>> system? See http://www.sixxs.net/tools/grh/peering/ for the details.
>> The more information it receives the better the quality.]
>
> Hi Jeroen,
>
> If that's an invitation, then yes, we'd like to peer. However,
> I'm not entirely sure we can reach you:
>
> ryouko (Mail) 682# traceroute6 2001:838:1:1:210:dcff:fe20:7c7c
> traceroute to 2001:838:1:1:210:dcff:fe20:7c7c
> (2001:838:1:1:210:dcff:fe20:7c7c) from 2001:410:9000:127::10, 30 hops max,
> 16 byte packets
> 1 ncrgate-vlan270.nrc.ca (2001:410:9000:127::1) 0.37 ms 0.372 ms 0.291 ms
> 2 nrcgate-pap-1.ipv6.nrc.ca (2001:410:9000::9) 0.445 ms 0.356 ms 0.261 ms
This looks odd, going into EP.net, apparently
http://www.gigafed.net/infocentre.html
Information is not in whois though, it would be handy to have inet6num's
for 2001:478:149::/48 in there. Thanks for Google though to point in the
right direction.
> 3 2001:478:149::12 (2001:478:149::12) 7.602 ms 7.283 ms 7.162 ms
and then back into your own prefix at 200ms later...
> 4 2001:410:101:30::2 (2001:410:101:30::2) 262.799 ms 262.524 ms 262.875 ms
> 5 2001:320:1a02::b (2001:320:1a02::b) 262.735 ms 262.496 ms *
inet6num: 2001:0320::/32
netname: KREONET2-KRNIC-KR-20010823
descr: KREONET2
descr: Korea Research Environment Open Network 2)
Welcome to Korea. This definitely looks like a transit problem.
> 6 2001:220:1000:400::2 (2001:220:1000:400::2) 265.603 ms 265.498 ms
> 265.403 ms
> 7 2001:660:3000:1002:0:11:0:2200 (2001:660:3000:1002:0:11:0:2200)
> 428.336 ms 368.395 ms 371.16 ms
> 8 renater-10G.fr1.fr.geant.net (2001:798:2016:10aa::5) 377.832 ms
> 372.909 ms 366.911 ms
> 9 fr.de1.de.geant.net (2001:798:20cc:1401:1601::1) 366.892 ms 370.923
> ms 371.764 ms
> 10 glbx-gw.de1.de.geant.net (2001:798:2014:20dd::6) 421.85 ms 413.89 ms
> 412.534 ms
> 11 * * *
>
> I guess there's some more things to sort out in the routing table...
Now lets take the information we can get from GRH:
http://www.sixxs.net/tools/grh/lg/?find=2001:410::/32
This reveals that there is no such 2001:410::/32 coming from Concepts,
where 2001:838::/32 resides, IO, their upstream, don't have it either,
both parties CC'd. They both don't seem to have a path back at all.
As transits you apparently have GEANT + Abilene. The bad part about this
is that GEANT/Abilene policy is that they don't do transit for
commercial parties. Though sometimes it does work out, most of the times
it does not.
Paths that arrive in .nl:
Abilene -> Powerdcom (jp) -> Hurricane (us) -> UPC -> C&W (de) -> .nl:
2001:410::/32 16131 1273 6830 6830 6830 6830 6939 4716 11537 6509
2001:410::/32 12859 3265 6175 4555 6939 4716 11537 6509
2001:410::/32 12634 12702 1275 5609 6939 4716 11537 6509
Abilene -> Powerdcom (jp) -> Hurricane (us) -> EP (us) -> Sprint (us) ->
XS4all (nl)
2001:410::/32 12902 12859 3265 6175 4555 6939 4716 11537 6509
2001:410::/32 31383 12859 3265 6175 4555 6939 4716 11537 6509
Abilene -> ODN (jp) -> WIDE (jp) -> IIJ (jp) -> Tiscali (us/eu) ->
Realroot (be/nl)
2001:410::/32 24875 28747 3257 2497 2500 4725 11537 6509
Abilene -> Gblx (us) -> Eunet (fi) -> Port80 (se)
2001:410::/32 8954 16150 6667 3549 11537 6509
Geant (1103 = Surfnet, dutch NREN)
2001:410::/32 1103 20965 6509
2001:410::/32 1888 1103 20965 6509
Abilene -> Verio (us)
2001:410::/32 21155 2914 11537 6509
2001:410::/32 28788 21155 2914 11537 6509
Possible solution: More transit providers on both sides, better
distribution of the prefixes etc.
Quick solution: Do not route US routes back to the US when receiving
them from Japan.
You might want to forward this example to a number of people concerned
in the various ASN's mentioned here, or just forward it to the ipv6-ops
list.
Greets,
Jeroen
More information about the ipv6-ops
mailing list