[28079] in North American Network Operators' Group
RE: Policies: Routing a subset of another ISP's address block
daemon@ATHENA.MIT.EDU (Hank Nussbacher)
Sat Apr 8 14:15:21 2000
Message-Id: <3.0.5.32.20000408195926.007f4100@max.ibm.net.il>
Date: Sat, 08 Apr 2000 19:59:26 +0200
To: "Dmitri Krioukov" <dima@dimension.net>,
"Greene, Dylan" <DGreene@NaviSite.com>,
"Jesper Skriver" <jesper@skriver.dk>
From: Hank Nussbacher <hank@att.net.il>
Cc: <nanog@merit.edu>
In-Reply-To: <NCBBIKACLKNMKDHKKKNFMECOEJAA.dima@dimension.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Errors-To: owner-nanog-outgoing@merit.edu
At 21:04 07/04/00 -0400, Dmitri Krioukov wrote:
The route object described in http://www.ripe.net/ripe/docs/ripe-189.html
states that origin AS is a single occurence. RIPE-189 should then be
updated to allow multiple occurences of the origin tag.
-Hank
>
>it does generate inconsistent origin as'es and it does break
>path filters, but not only. it breaks all the tools/methods
>based on the uniqueness of the route->origin-as mapping. i'm
>looking for a more or less complete list of these tools/methods.
>
>it seems, though, that the inconsistent-as list is growing and
>this doesn't produce too much panic.
>
>and if you examine this list more closely, you'll notice that it
>looks like the major part of it is generated by the isps doing
>the aforementioned trick.
>--
>dima.
>
>> -----Original Message-----
>> From: Greene, Dylan [mailto:DGreene@NaviSite.com]
>> Sent: Friday, April 07, 2000 6:06 PM
>> To: 'Dmitri Krioukov'; Jesper Skriver
>> Cc: nanog@merit.edu
>> Subject: RE: Policies: Routing a subset of another ISP's address block
>>
>>
>>
>> Hey there..
>>
>> I'd imagine this works fine, but doesn't it leave you w/ inconsistent-as,
>> where you've got a prefix being advertised from the private ASN,
>> stripped &
>> replaced w/ each upstream ASN?
>>
>> I mean, it should work, but is it a very good idea? The
>> inconsistent-as list
>> isn't _too_ big right now, which is good, as each one effectively breaks a
>> number of common path filters. But if that starts to becomes common
>> practice, the list gets bigger and bigger & more filters get broken.
>>
>> ..Dylan
>>
>>
>> > -----Original Message-----
>> > From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu]On Behalf Of
>> > Jesper Skriver
>> > Sent: Friday, April 07, 2000 2:21 PM
>> > To: Daniel L. Golding
>> > Cc: David Harrison; nanog@merit.edu
>> > Subject: Re: Policies: Routing a subset of another ISP's address block
>> >
>> > Actually I've helped quite a few such customers, my recommendation
>> > usually is to get PI space from RIPE, and get both providers to announce
>> > it from their ASN, this works quite well, and also save a ASN - if the
>> > customer really want to run BGP, we have arrangements with other ISP's
>> > here, that we find a private ASN (that none of us use currently), and
>> > assign this ASN to the customer, and we then strip the private ASN on
>> > the edges of our network.
>>
>> this is interesting (since it overwrites the rule that multihoming to two
>> isps requires a public asn assignment) and i've tested exactly
>> this scenario
>> (again, a customer uses some private asn and is peering with two isps;
>> both of them strip this asn at their boundaries (remove-private-as))
>> in my lab before and it worked fine. it results in propagating routes to
>> the same networks with two distinct as path attributes, though. i've been
>> looking for any operational experience with this setup. so, do you claim
>> that you couldn't detect *any* problems with this setup?
>> --
>> dima.
>>
>>
>>
>
>
>
