Mailing List Archive

On Wed, 18 May 2005 16:31:29 +0100, Nick Hilliard wrote:
> You know, it's always fun when traffic takes a slightly circuitous route
> from A to B, but is it really necessary for ipv6 from dublin to
> amsterdam to go:

Nick, that thing is being settled with 2110 these minutes.

Basically I see two problems here:

a) HE
b) people still sending full table to (too) many others

a) I can probably fix for 3257, but b) is not much I can do
about as is probably obvious.

Anyone from HE here listening, and able to confirm you do
not differentiate between cust and peer routes?

Regards,
Alexander

On Wed, 18 May 2005, Nick Hilliard wrote:

> You know, it's always fun when traffic takes a slightly circuitous route
> from A to B, but is it really necessary for ipv6 from dublin to
> amsterdam to go:
>
> dublin
> CA, USA
> IN, USA
> seoul, korea
> beijing, china
> WA, USA
> NYC, USA
> london
> amsterdam

i've seen a lot of lisbon-lisbon traffic going through amsterdam or
london, but this dublin-amsterdam path beats that easily :-)


> ?
>
> And before anyone starts pointing the finger at the immediate upstream
> (AS2110), this goes well beyond any misconfiguration they might have.
>
> The AS path is a hilarious "2110 3549 11537 17579 1237 17832 24136 109
> 109 6939 3257 3333" - ouch!

glad not to see my ASN on this as-path :-)


now, to the serious question: can't you get an IPv6 transit provider based
in Europe? :-)


> Nick Hilliard
>
> --
>
> twinkie:/home/nick> traceroute6 www.ripe.net
> traceroute6 to kite-www.ripe.net (2001:610:240:0:a843::8) from 2001:7c8:51:d::2, 64 hops max, 12 byte packets
> 1 2001:7c8:51:d::1 24.551 ms 25.363 ms 29.466 ms
> 2 fe2-0.6rt501.cwt.esat.net 25.545 ms 30.837 ms 25.744 ms
> 3 fe0-0.6core001.cwt.esat.net 25.990 ms 29.274 ms 26.562 ms
> 4 fe1-0.6br002.cwt.esat.net 26.194 ms 28.596 ms 28.240 ms
> 5 2001:450:1:2001::c0 297.667 ms 374.650 ms 307.825 ms
> 6 3ffe:80a::c 283.053 ms 269.354 ms 264.996 ms
> 7 3ffe:80a::c 274.048 ms 266.894 ms 262.179 ms
> 8 3ffe:80a::bd 262.365 ms 259.719 ms 260.512 ms
> 9 sttlng-snvang.abilene.ucaid.edu 276.447 ms 275.009 ms 269.765 ms
> 10 2001:468:ff:16c1::6 456.615 ms 466.958 ms 466.970 ms
> 11 2001:320:1b00:1::1 455.235 ms 473.424 ms 467.670 ms
> 12 2001:320:1a05::4 460.621 ms 483.173 ms 471.106 ms
> 13 2001:320:1a06::2 458.305 ms 463.229 ms 467.939 ms
> 14 2001:320:1a07::20 465.043 ms 464.923 ms 468.042 ms
> 15 2001:320:1a07::2 464.441 ms 475.520 ms 465.939 ms
> 16 2001:2b8:0:81::82 468.064 ms 469.388 ms 476.418 ms
> 17 2001:2b8:4:30::2 675.663 ms 679.488 ms 683.676 ms
> 18 2001:dc7:ff:1000::2 687.167 ms 699.041 ms 693.122 ms
> 19 equinix6-was.ip.tiscali.net 438.838 ms 440.648 ms 440.359 ms
> 20 so-0-1-3.was10.ip6.tiscali.net 441.282 ms 442.252 ms 444.234 ms
> 21 so-0-0-0.nyc33.ip6.tiscali.net 443.926 ms 442.760 ms 442.975 ms
> 22 so-4-0-0.lon12.ip6.tiscali.net 443.613 ms 451.108 ms 442.985 ms
> 23 pos-7-1-1.ams11.ip6.tiscali.net 451.892 ms 453.952 ms 451.704 ms
> 24 so-7-0-0.ams10.ip6.tiscali.net 451.118 ms 447.377 ms 453.726 ms
> 25 nikipv6.ripe.net 455.056 ms 468.151 ms 465.417 ms
> 26 2001:610:240:0:a843::8 462.339 ms 464.724 ms 477.005 ms
> twinkie:/home/nick>
>


./Carlos
-------------- http://www.ip6.fccn.pt/nativeRCTS2.html

Wide Area Network (WAN) Workgroup, CMF8-RIPE, CF596-ARIN
FCCN - Fundacao para a Computacao Cientifica Nacional http://www.fccn.pt

"Internet is just routes (150665/657), naming (millions) and... people!"

Hi,

On Wed, May 18, 2005 at 04:38:40PM +0100, Carlos Friacas wrote:
> >And before anyone starts pointing the finger at the immediate upstream
> >(AS2110), this goes well beyond any misconfiguration they might have.
> >
> >The AS path is a hilarious "2110 3549 11537 17579 1237 17832 24136 109
> >109 6939 3257 3333" - ouch!
>
> glad not to see my ASN on this as-path :-)
>
> now, to the serious question: can't you get an IPv6 transit provider based
> in Europe? :-)

Hmmm, well, 3549 *does* have v6 routers in Europe... and even though
still tunnel-based internally, they are not the worst AS out there (by far).

Gert Doering
-- NetMaster
--
Total number of prefixes smaller than registry allocations: 71007 (66629)

SpaceNet AG Mail: netmaster@Space.Net
Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0
D- 80807 Muenchen Fax : +49-89-32356-234

On Wed, 18 May 2005, Gert Doering wrote:

> Hi,
>
> On Wed, May 18, 2005 at 04:38:40PM +0100, Carlos Friacas wrote:
>>> And before anyone starts pointing the finger at the immediate upstream
>>> (AS2110), this goes well beyond any misconfiguration they might have.
>>>
>>> The AS path is a hilarious "2110 3549 11537 17579 1237 17832 24136 109
>>> 109 6939 3257 3333" - ouch!
>>
>> glad not to see my ASN on this as-path :-)
>>
>> now, to the serious question: can't you get an IPv6 transit provider based
>> in Europe? :-)
>
> Hmmm, well, 3549 *does* have v6 routers in Europe... and even though
> still tunnel-based internally, they are not the worst AS out there (by far).


Sounds strange to me... doesn't AS3549 have a v6 router in ams-ix, do
they need to go through abilene? :-)


> Gert Doering
> -- NetMaster
> --
> Total number of prefixes smaller than registry allocations: 71007 (66629)
>
> SpaceNet AG Mail: netmaster@Space.Net
> Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0
> D- 80807 Muenchen Fax : +49-89-32356-234
>


./Carlos
-------------- http://www.ip6.fccn.pt/nativeRCTS2.html

Wide Area Network (WAN) Workgroup, CMF8-RIPE, CF596-ARIN
FCCN - Fundacao para a Computacao Cientifica Nacional http://www.fccn.pt

"Internet is just routes (150665/657), naming (millions) and... people!"

On Wed, 18 May 2005, Nick Hilliard wrote:

> You know, it's always fun when traffic takes a slightly circuitous route
> from A to B, but is it really necessary for ipv6 from dublin to
> amsterdam to go:

> And before anyone starts pointing the finger at the immediate upstream
> (AS2110), this goes well beyond any misconfiguration they might have.
>
> The AS path is a hilarious "2110 3549 11537 17579 1237 17832 24136 109
> 109 6939 3257 3333" - ouch!

We "fixed" this same issue today for ourselves by filtering
2001:610:240::/42 off - apparently somebody doesn't care about the
"no-export" tag set by RIPE on all their peers.. Please, correct me if I'm
wrong, but if you don't directly peer with RIPE you shouldn't see this
more-specific prefix at all?


2001:610:240::/42 *[BGP/170] 1d 08:24:22, MED 50, localpref 90
AS path: 6667 3549 11537 17579 1237 17832 24136 109 109 6939 3257 3333 I
> to 2001:1430:0:1::2 via ge-1/3/0.5

.. goes away and is replaced by ..

2001:610::/32 *[BGP/170] 1w0d 16:48:24, MED 50, localpref 90
AS path: 3246 1103 I
> to 2001:1430::ffff:2 via ge-1/3/0.50




-- juhas

That is no fun at all. We also noticed some rather long paths @
NANOG34 this week, but I believe that was because they tunneled from
Seattle to Internet2 back on the east coast.

Looks good from my side (Thanks Alexander ;)

traceroute to kite-www.ripe.net (2001:610:240:0:a843::8) from
2001:4838:f000::1, 30 hops max, 16 byte packets
1 2001:4838:f000::2 (2001:4838:f000::2) 0.429 ms 0.412 ms 0.359 ms
2 ae0-10.was10.ip6.tiscali.net (2001:668:0:3::8000:1) 1.878 ms
0.46 ms 0.39 ms
3 so-0-0-0.nyc33.ip6.tiscali.net (2001:668:0:2::200) 5.75 ms 5.763
ms 5.753 ms
4 so-4-0-0.lon12.ip6.tiscali.net (2001:668:0:2::1e0) 71.698 ms
71.679 ms 71.76 ms
5 pos-7-1-1.ams11.ip6.tiscali.net (2001:668:0:2::30) 79.302 ms
79.344 ms 79.217 ms
6 so-7-0-0.ams10.ip6.tiscali.net (2001:668:0:2::570) 79.528 ms
181.435 ms 79.4 ms
7 nikipv6.ripe.net (2001:7f8:1::a500:3333:1) 80.585 ms 80.448 ms
80.628 ms
8 2001:610:240:0:a843::8 (2001:610:240:0:a843::8) 80.487 ms 80.634
ms 80.454 ms

-Scott


On May 18, 2005, at 8:31 AM, Nick Hilliard wrote:

> You know, it's always fun when traffic takes a slightly circuitous
> route
> from A to B, but is it really necessary for ipv6 from dublin to
> amsterdam to go:
>
> dublin
> CA, USA
> IN, USA
> seoul, korea
> beijing, china
> WA, USA
> NYC, USA
> london
> amsterdam
>
> ?
>
> And before anyone starts pointing the finger at the immediate upstream
> (AS2110), this goes well beyond any misconfiguration they might have.
>
> The AS path is a hilarious "2110 3549 11537 17579 1237 17832 24136 109
> 109 6939 3257 3333" - ouch!
>
> Nick Hilliard
>
> --
>
> twinkie:/home/nick> traceroute6 www.ripe.net
> traceroute6 to kite-www.ripe.net (2001:610:240:0:a843::8) from
> 2001:7c8:51:d::2, 64 hops max, 12 byte packets
> 1 2001:7c8:51:d::1 24.551 ms 25.363 ms 29.466 ms
> 2 fe2-0.6rt501.cwt.esat.net 25.545 ms 30.837 ms 25.744 ms
> 3 fe0-0.6core001.cwt.esat.net 25.990 ms 29.274 ms 26.562 ms
> 4 fe1-0.6br002.cwt.esat.net 26.194 ms 28.596 ms 28.240 ms
> 5 2001:450:1:2001::c0 297.667 ms 374.650 ms 307.825 ms
> 6 3ffe:80a::c 283.053 ms 269.354 ms 264.996 ms
> 7 3ffe:80a::c 274.048 ms 266.894 ms 262.179 ms
> 8 3ffe:80a::bd 262.365 ms 259.719 ms 260.512 ms
> 9 sttlng-snvang.abilene.ucaid.edu 276.447 ms 275.009 ms
> 269.765 ms
> 10 2001:468:ff:16c1::6 456.615 ms 466.958 ms 466.970 ms
> 11 2001:320:1b00:1::1 455.235 ms 473.424 ms 467.670 ms
> 12 2001:320:1a05::4 460.621 ms 483.173 ms 471.106 ms
> 13 2001:320:1a06::2 458.305 ms 463.229 ms 467.939 ms
> 14 2001:320:1a07::20 465.043 ms 464.923 ms 468.042 ms
> 15 2001:320:1a07::2 464.441 ms 475.520 ms 465.939 ms
> 16 2001:2b8:0:81::82 468.064 ms 469.388 ms 476.418 ms
> 17 2001:2b8:4:30::2 675.663 ms 679.488 ms 683.676 ms
> 18 2001:dc7:ff:1000::2 687.167 ms 699.041 ms 693.122 ms
> 19 equinix6-was.ip.tiscali.net 438.838 ms 440.648 ms 440.359 ms
> 20 so-0-1-3.was10.ip6.tiscali.net 441.282 ms 442.252 ms 444.234 ms
> 21 so-0-0-0.nyc33.ip6.tiscali.net 443.926 ms 442.760 ms 442.975 ms
> 22 so-4-0-0.lon12.ip6.tiscali.net 443.613 ms 451.108 ms 442.985 ms
> 23 pos-7-1-1.ams11.ip6.tiscali.net 451.892 ms 453.952 ms
> 451.704 ms
> 24 so-7-0-0.ams10.ip6.tiscali.net 451.118 ms 447.377 ms 453.726 ms
> 25 nikipv6.ripe.net 455.056 ms 468.151 ms 465.417 ms
> 26 2001:610:240:0:a843::8 462.339 ms 464.724 ms 477.005 ms
> twinkie:/home/nick>
>
>

On Wed, 18 May 2005, Juha Suhonen wrote:

> On Wed, 18 May 2005, Nick Hilliard wrote:
>
>> You know, it's always fun when traffic takes a slightly circuitous route
>> from A to B, but is it really necessary for ipv6 from dublin to amsterdam
>> to go:
>
>> And before anyone starts pointing the finger at the immediate upstream
>> (AS2110), this goes well beyond any misconfiguration they might have.
>>
>> The AS path is a hilarious "2110 3549 11537 17579 1237 17832 24136 109 109
>> 6939 3257 3333" - ouch!
>
> We "fixed" this same issue today for ourselves by filtering 2001:610:240::/42
> off - apparently somebody doesn't care about the "no-export" tag set by RIPE
> on all their peers.. Please, correct me if I'm wrong, but if you don't
> directly peer with RIPE you shouldn't see this more-specific prefix at all?
>
>
> 2001:610:240::/42 *[BGP/170] 1d 08:24:22, MED 50, localpref 90
> AS path: 6667 3549 11537 17579 1237 17832 24136 109 109
> 6939 3257 3333 I
> > to 2001:1430:0:1::2 via ge-1/3/0.5


yep, i dont see it. i only see 2001:610::/32


> .. goes away and is replaced by ..
>
> 2001:610::/32 *[BGP/170] 1w0d 16:48:24, MED 50, localpref 90
> AS path: 3246 1103 I
> > to 2001:1430::ffff:2 via ge-1/3/0.50

which is surfnet (my v6 roundtrip to www.ripe.net is ~37ms, from Lisbon)
:-)


./Carlos
-------------- http://www.ip6.fccn.pt/nativeRCTS2.html

Wide Area Network (WAN) Workgroup, CMF8-RIPE, CF596-ARIN
FCCN - Fundacao para a Computacao Cientifica Nacional http://www.fccn.pt

"Internet is just routes (150665/657), naming (millions) and... people!"

On Wed, May 18, 2005 at 04:31:29PM +0100, Nick Hilliard wrote:
> And before anyone starts pointing the finger at the immediate upstream
> (AS2110), this goes well beyond any misconfiguration they might have.

What you see is the result of multiple problems. 2110 is NOT to blame
here.

> The AS path is a hilarious "2110 3549 11537 17579 1237 17832 24136 109
> 109 6939 3257 3333" - ouch!

Problem 1 is, that www.ripe.net is inside route 2001:610:240::/42
which is being filtered in many places. As such, your AS_PATHs do
become worse-than-ideal automatically. GBLX seems to have only(?)
Abilene as source for this /42 (they could peer with RIPE directly
at AMSIX though). Looking at the GRH looking glass at
http://www.sixxs.net/tools/grh/lg/?prefix=2001:610:240::/42, it shows
nicely that the propagation of the /42 is quite limited due to
filtering, but most that DO have a route to the /42, have a "good"
path. The exception is the "leak" via 3257=>6939=>109=>24136 which I
describe later...

Then you're seeing the problem that Abilene is... hm.. confused.
Policy of all those NREN networks is that they don't transit traffic
from ISPs to other ISPs thru them (which makes sense). Unfortunately,
both "up"streams of Abilene (KREONET2 [17579] and APAN) don't tag
their routes, thus Abilene can't easily distinguish "commercial"
from "noncommercial" routes. So, for Abilene, all routes received
from KREONET2 and APAN are "noncommercial" routes, as they are
received from NRENs - and thus get reannounced to GBLX.

Third problem is, that Abilene seems to only provide FULL table to
peers @ PAIX-PA and then leave it up to the peers to filter away
what they don't want. So effectively, there is little policy enforcement
going on.

Fourth problem (not seen here) is that Abilene also reannounces all
routes received from commercial ISP peers @ PAIX-PA to everbuddy else.
So we have the ISP<->Abilene<->ISP transit problem in both directions.

Now, even if Abilene and KREONET[2] would sort out their routing policy,
things would still be bad.

Take a look at the AS_PATH in reverse order:

3333 3257 6939 109 24136 17832 1237 17579 ...

RIPE peers with Tiscali (3257), and Tiscali engages in some kind of
route swap with 6939 (HE.net), so provides full/partial transit to HE.
HE.net seems to swap full table with 109 (Cisco), and those with 24136
(SIXNGIX - probably some kind of L3 IXP in Korea).

End result is, that the RIPE route could only take such a path due to
multiple problems with multiple operators having a questionable
routing policy.

Cisco stopping to play tunnel transit left-and-right around the world
would be a first good step to help preventing those kind of things to
happen. :-)

Another good idea would be for Abilene to stop sending routes received
from commercial peers to APAN/KREONET2. When they're at it, they can
also stop reannouncing routes received from ISPs at PAIX-PA back to
ISP peers @ PAIX-PA. :-) And finally, Abilene should send only their
own routes (Abilene's /32 and the connected universities, GigaPOPs,
research/defense networks etc.) to ISP peers instead of sending a full
table and relying on the ISP to sort it out with inbound filters.
The ISPs have a hard time manually filtering that and Abilene's
communities don't really help there too much last time I checked.


Best regards,
Daniel

--
CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0

On Wed, May 18, 2005 at 07:05:22PM +0300, Juha Suhonen wrote:
> We "fixed" this same issue today for ourselves by filtering
> 2001:610:240::/42 off - apparently somebody doesn't care about the
> "no-export" tag set by RIPE on all their peers.. Please, correct me if I'm
> wrong, but if you don't directly peer with RIPE you shouldn't see this
> more-specific prefix at all?

Good point, indeed. Alexander? ;)


Best regards,
Daniel

--
CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0

On Wed, 18 May 2005 18:14:51 +0200, Daniel Roesen wrote:
> On Wed, May 18, 2005 at 07:05:22PM +0300, Juha Suhonen wrote:
> > We "fixed" this same issue today for ourselves by filtering
> > 2001:610:240::/42 off - apparently somebody doesn't care about the
> > "no-export" tag set by RIPE on all their peers.. Please, correct me if I'm
> > wrong, but if you don't directly peer with RIPE you shouldn't see this
> > more-specific prefix at all?
>
> Good point, indeed. Alexander? ;)

First of all I 'fixed' the HE thing for me. Not sure how
many emails or IRC comments I got for this per week but it
were too many.

With regards to RIPE's /42 we overwrite our peering partners
community like we do in good old v4 world. We accept more
specs with no-export on specific request from certain peers,
but only on specific request and where it makes any sense at
all. Having had the same issue with another /48 I do invite
my peers to not announce stuff to me that they tag no-export.

Regards,
Alexander,
just in a practical mood

Hi Daniel,

Daniel Roesen said the following on 19/05/2005 02:11:
>
> Cisco stopping to play tunnel transit left-and-right around the world
> would be a first good step to help preventing those kind of things to
> happen. :-)

Well, for the record we've added no new "transit" tunnels for at least
two years. There are sufficient providers of IPv6 connectivity now that
Cisco doesn't really need to be helping with providing this boot strap
service any more.

And last year I "fixed" non-US transits by local pref'ing them out of
sight at my end, and doing the single AS-PATH prepend outbound. 109
appears twice in the AS-PATH - so it takes some pretty severe brokenness
to send stuff our way. Maybe I need to do more prepends, but I suspect
it's broken filtering somewhere along the way that's causing some of this.

But... I've had sufficient conversations with people in the last couple
of weeks (i.e. at RIPE and at NANOG) that I'm going to take a serious
look at the transit provision we are doing. I really dislike seeing some
of the routing mess here, and definitely don't want to be seen as
inadvertently contributing to it.

best wishes!

philip
--

Hi Philip,

On Thu, May 19, 2005 at 02:50:03AM +1000, Philip Smith wrote:
> But... I've had sufficient conversations with people in the last couple
> of weeks (i.e. at RIPE and at NANOG) that I'm going to take a serious
> look at the transit provision we are doing. I really dislike seeing some
> of the routing mess here, and definitely don't want to be seen as
> inadvertently contributing to it.

Excellent, thanks Philip! I'm sure OCCAID and others will be glad to
chime in for folks who currently rely on solely 109 providing transit.


Best regards,
Daniel

--
CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0

On Thu, 19 May 2005 02:50:03 +1000, Philip Smith wrote:
[..]
> And last year I "fixed" non-US transits by local pref'ing them out of
> sight at my end, and doing the single AS-PATH prepend outbound.

Ehm... brute force with regards to localpref, and the
smallest of all things you could do for outbound?

> 109 appears twice in the AS-PATH - so it takes some pretty
> severe brokenness to send stuff our way.

I beg to differ. Given current AS paths and typical
suppliers of real v6 transit are not that wide- spread,
then clearly one prepend is not enough to accomplish that,
judging by experience alone. I could be wrong.

> But... I've had sufficient conversations with people in the last couple
> of weeks (i.e. at RIPE and at NANOG) that I'm going to take a serious
> look at the transit provision we are doing. I really dislike seeing some
> of the routing mess here, and definitely don't want to be seen as
> inadvertently contributing to it.

Thanks lots for having a look there. Kick your peers to do
real peering instead of other methods maybe like in v4? But
I welcome that move a lot, thanks Phil!

Alexander

On Wed, May 18, 2005 at 06:55:58PM +0200, Daniel Roesen wrote:
> Hi Philip,
>
> On Thu, May 19, 2005 at 02:50:03AM +1000, Philip Smith wrote:
> > But... I've had sufficient conversations with people in the last couple
> > of weeks (i.e. at RIPE and at NANOG) that I'm going to take a serious
> > look at the transit provision we are doing. I really dislike seeing some
> > of the routing mess here, and definitely don't want to be seen as
> > inadvertently contributing to it.
>
> Excellent, thanks Philip! I'm sure OCCAID and others will be glad to
> chime in for folks who currently rely on solely 109 providing transit.
>

Yup, we will be very happy/glad to assist.

Thank you all,

-J

>
> Best regards,
> Daniel

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

On Thu, May 19, 2005 at 02:50:03AM +1000, Philip Smith wrote:
Hi Phil,

> Well, for the record we've added no new "transit" tunnels for at least
> two years. There are sufficient providers of IPv6 connectivity now that
> Cisco doesn't really need to be helping with providing this boot strap
> service any more.

that is indeed a good start.


> And last year I "fixed" non-US transits by local pref'ing them out of
> sight at my end, and doing the single AS-PATH prepend outbound. 109
> appears twice in the AS-PATH - so it takes some pretty severe brokenness
> to send stuff our way. Maybe I need to do more prepends, but I suspect
> it's broken filtering somewhere along the way that's causing some of this.

I tend to agree with Alexander. prepending once doesnt look any good.
Especially on peering sessions with "route swappers".


best regards

Udo

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

> Another good idea would be for Abilene to stop sending routes received
> from commercial peers to APAN/KREONET2. When they're at it, they can
> also stop reannouncing routes received from ISPs at PAIX-PA back to
> ISP peers @ PAIX-PA. :-) And finally, Abilene should send only their
> own routes (Abilene's /32 and the connected universities, GigaPOPs,
> research/defense networks etc.) to ISP peers instead of sending a full
> table and relying on the ISP to sort it out with inbound filters.
> The ISPs have a hard time manually filtering that and Abilene's
> communities don't really help there too much last time I checked.
>

Abilene tags the routes it receives directly from commercial peers
with the 11537:2001 community. We also block advertisements of
these routes to other commercial peers by default. This is a
recent change (ie within the last couple of months).

We still advertise routes we learn from commercial peers to other
NRNs and visa versa. I'll start a discussion internally to see if
we want to change this as well. Even if we do this, we still
can't easily distinguish between commercial vs non-commercial routes
that we receive from other NRNs so we may still be transiting other
commercial routes, but this would be a good start.

Also, we tag IPv6 routes we receive through a tunneled interface with
the 11537:600 community.

You can see a full description of our routing policies and community
usage at the following URL...

http://www.abilene.iu.edu/bgpcommun.html

- - Matt

Matt Davy
Chief Network Engineer, Indiana University
Abilene Network Operations Center
2711 East 10th Street, Bloomington IN, 47403
mpd@grnoc.iu.edu / 812.855.7728
PGP key fingerprint: A84D DFB6 9DD5 BEB4 1EF7 D713 956F F85C 6422 CBEB

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)

iD8DBQFCi3oGlW/4XGQiy+sRAn1BAJoC7+uwvJ7FFwQN8R/41927gQNW8QCgqs4+
Ac86PEDWkg/EPwvNu3AvJ/M=
=xrUm
-----END PGP SIGNATURE-----

On Wed, May 18, 2005 at 12:23:18PM -0500, Matthew Davy wrote:

Hi Matthew,

> Abilene tags the routes it receives directly from commercial peers
> with the 11537:2001 community. We also block advertisements of
> these routes to other commercial peers by default. This is a
> recent change (ie within the last couple of months).

that is nice. But you guys still send full routes to your commercial
peers. It'd be appreciated if you fix that :))

best regards

Udo

Alexander Koch said the following on 19/05/2005 02:52:
>
> Ehm... brute force with regards to localpref, and the
> smallest of all things you could do for outbound?

It was the first step of a plan I had a year ago... I haven't had time
to take the next step... But doing it now, and over the next few weeks.

> I beg to differ. Given current AS paths and typical
> suppliers of real v6 transit are not that wide- spread,
> then clearly one prepend is not enough to accomplish that,
> judging by experience alone. I could be wrong.

It's actually a good question. I don't know either, and I could be wrong
too. When I did the prepend, the major problems of intra-European
traffic going via San Jose had disappeared. At least, people stopped
complaining to me. ;-) So I thought maybe the difference between Gert's
severe and relaxed prefix filters was causing the current problems (we
implement the relaxed filters, btw, which would explain us being used
for transit despite the prepend).

> Thanks lots for having a look there. Kick your peers to do
> real peering instead of other methods maybe like in v4? But
> I welcome that move a lot, thanks Phil!

No problems, sorry to everyone for leaving this for so long.

philip
--