Mailing List Archive

Canarie / 2001:410::/32 (Was: Filters) (fwd)
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@unfix.org>
To: William F. Maton Sotomayor <wmaton@ryouko.imsb.nrc.ca>
Cc: Richard <rh@concepts.nl>, Joris Vandalon <joris@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
Canarie / 2001:410::/32 (Was: Filters) (fwd) [ In reply to ]
Hi,

> 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.

Canarie seems to be a downstream of Abilene. Abilene seems to have a
funny routing policy, to say the least. When looking at the paths of the
Canarie prefix

http://www.sixxs.net/tools/grh/lg/?find=2001:410::/32

or the Viagenie one

http://www.sixxs.net/tools/grh/lg/?find=2001:468::/32

I'm not able to make out an upstream. The international connectivity
seems to be mostly done by sending those routes to other NRENs in the
APNIC region and then sent to some "strategic" routeswappers (AS6939 for
example). Inbound routes to Abilene are strange as well, for a newly
advertised prefix Abilene sees

11537 17579 9270 7660 2500 1273 680 12816

Europe - Asia - America

Abilene seems to take what they get (even if it doesn't make sense at
all) and trust the forces of routeswap to get their own prefixes
visible. This mostly works (with long paths, in special occasions
several times around the globe), but sometimes doesn't. The prefix I'm
talking about above had a loooong path from Abilene through es.net this
noon, with es.net happily advertising but then sending "destination
unreachable" for every packet following that path.

Those who are downstream customers of the few ASNs peering with Abilene
(GBLX, Verio, ISC) can be happy here, for all others the available paths
are pure crap.

I can't currently see any decent service provided by Abilene. GEANT
being the european REN isn't that much better.

Bernhard
Canarie / 2001:410::/32 (Was: Filters) (fwd) [ In reply to ]
Hi,

> or the Viagenie one
>
> http://www.sixxs.net/tools/grh/lg/?find=2001:468::/32

Sorry, that ought to be Abilene.

And now from today's horror cabinet the traceroute from one of my
colocated boxes to William's MX

6 ge-0-2-0.pr1.k90.fra.de.v6.eurotransit.net (2001:1bc0::ffff:ffff:11)
9.134
ms
7 Ge5-0.FFTBB2.Frankfurt.ipv6.opentransit.net (2001:688:0:3:7::2)
43.508 ms
8 P3-0.FFT6AR1.Frankfurt.ipv6.opentransit.net (2001:688:0:2:1::f)
44.053 ms
9 P5-0-0.PAS6AR1.Paris.ipv6.opentransit.net (2001:688:0:2:1::) 42.285 ms
10 2001:688:0:2:6:: (2001:688:0:2:6::) 285.205 ms
11 2001:200:0:1800::5511:0 (2001:200:0:1800::5511:0) 284.36 ms
12 hitachi1.otemachi.wide.ad.jp (2001:200:0:1800::9c4:2) 285.201 ms
13 pc6.otemachi.wide.ad.jp (2001:200:0:1800::9c4:0) 285.269 ms
14 2001:200:0:1800::4725:1 (2001:200:0:1800::4725:1) 284.226 ms
15 STOsrn03-101.nw.v6.odn.ne.jp (2001:278:0:2081::1) 286.822 ms
16 pax-gw3-201.nw.v6.odn.ne.jp (2001:278:0:2181::2) 412.863 ms
17 3ffe:80a::bd (3ffe:80a::bd) 474.154 ms
18 sttlng-snvang.abilene.ucaid.edu (2001:468:ff:1617::1) 461.9 ms
19 transpac-pacwave.abilene.ucaid.edu (2001:468:ff:16c1::3) 532.509 ms
20 2001:410:101:2::2 (2001:410:101:2::2) 529.17 ms
21 2001:478:149::1 (2001:478:149::1) 536.275 ms
22 2001:478:149::11 (2001:478:149::11) 590.854 ms
23 ncrgate-pap-3.ipv6.nrc.ca (2001:410:9000::a) 536.21 ms
24 ryouko.imsb.nrc.ca (2001:410:9000:127::10) 536.952 ms

Bernhard, scared
Canarie / 2001:410::/32 (Was: Filters) (fwd) [ In reply to ]
On Tue, May 24, 2005 at 08:25:05PM +0200, Bernhard Schmidt wrote:

[ snip ]

>
> I can't currently see any decent service provided by Abilene. GEANT
> being the european REN isn't that much better.

Now that we are talking about RENs :) One of the GEANT routing policies[1]
I've heard from several sources is that they will take commercial transit
(GBLX) for European v6 destinations, but yet, take Abilene for all non-EU
routes, i.e. US destinations.

While I agree that this may be a sane choice of policy, I would hope that
people understand that Abilene currently has capability to peer with
commercial/commodity v6 players in the west coast US only (PAIX-PA, and
possibly LAIIX/PacWave). Being a US network myself, this gives me quite
*bad* routing to European NREN destinations for our end-users who reside
in the east coast of United States, while it is fine for west coast users,
as return packets from European RENs go all the way to west coast via
Abilene, then come back to east.

What is even more interesting is that this "take Abilene for US routes"
"policy" is not just GEANT only, it also seems to be exercised by regional
EU NRENs as well (i.e. SURFnet), even though such regional networks have
direct transit from C&W or other similar commodity transit.


[1]: Accuracy of this statement is not guaranteed and I may be wrong.
So please feel free to correct as needed.

-J

--
James Jun
Infrastructure and Technology Services
TowardEX Technologies
Office +1-617-459-4051 x179 | Mobile +1-978-394-2867
james@towardex.com | www.towardex.com
Canarie / 2001:410::/32 (Was: Filters) (fwd) [ In reply to ]
> Date: Tue, 24 May 2005 22:23:40 -0400
> From: James <james@towardex.com>
> Cc: ipv6-ops@lists.cluenet.de
> Subject: Re: Canarie / 2001:410::/32 (Was: Filters) (fwd)

> On Tue, May 24, 2005 at 08:25:05PM +0200, Bernhard Schmidt wrote:
> [ snip ]

> > I can't currently see any decent service provided by Abilene. GEANT
> > being the european REN isn't that much better.

> Now that we are talking about RENs :) One of the GEANT routing policies[1]
> I've heard from several sources is that they will take commercial transit
> (GBLX) for European v6 destinations, but yet, take Abilene for all non-EU
> routes, i.e. US destinations.

There might be some more history to that then obvious...

> [ ... ]
> What is even more interesting is that this "take Abilene for US routes"
> "policy" is not just GEANT only, it also seems to be exercised by regional
> EU NRENs as well (i.e. SURFnet), even though such regional networks have
> direct transit from C&W or other similar commodity transit.

In the past I (being a SURFnet customer amongst others) complained to
them about the same. The reason(s) cited then were that SURFnet had
agreed to provide transit to other NREN's, and that at the time those
policies were the least worst solution. Though nowadays I agree they
should just think about doing it the right way.

Due note, that SURFnet is undergoing a transition from their current
SURFnet5 to SURFnet6 network. And like all semi-government operations
"large changes" like these are the points of which they've been
telling you for years when these and a whole bunch of those other
issues *finally* will be resolved...

> [1]: Accuracy of this statement is not guaranteed and I may be wrong.
> So please feel free to correct as needed.

idem.

Kind regards,
JP Velders