[28071] in North American Network Operators' Group

home help back first fref pref prev next nref lref last post

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

daemon@ATHENA.MIT.EDU (Dmitri Krioukov)
Fri Apr 7 16:21:39 2000

From: "Dmitri Krioukov" <dima@dimension.net>
To: "Jesper Skriver" <jesper@skriver.dk>
Cc: <nanog@merit.edu>
Date: Fri, 7 Apr 2000 16:34:16 -0400
Message-ID: <NCBBIKACLKNMKDHKKKNFOECKEJAA.dima@dimension.net>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
In-Reply-To: <20000407202047.D85221@skriver.dk>
Errors-To: owner-nanog-outgoing@merit.edu


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




home help back first fref pref prev next nref lref last post