nanog mailing list archives

RE: Policies: Routing a subset of another ISP's address block


From: "Dmitri Krioukov" <dima () dimension net>
Date: Fri, 7 Apr 2000 21:04:36 -0400


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.







Current thread: