[43735] in North American Network Operators' Group
Re: BGP advice: Customer converting from static ISP connection to BGP
daemon@ATHENA.MIT.EDU (Jason Legate)
Thu Oct 25 19:20:51 2001
Date: Thu, 25 Oct 2001 16:23:28 -0700
From: Jason Legate <jlegate@evine.com>
To: "Christopher A. Woodfield" <rekoil@semihuman.com>
Cc: CONWAY@pjm.com, nanog@merit.edu
Message-ID: <20011025162327.A87234@vineyard.evine.com>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-md5;
protocol="application/pgp-signature"; boundary="LQksG6bCIzRHxTLp"
Content-Disposition: inline
In-Reply-To: <20011025182148.B16909@semihuman.com>; from rekoil@semihuman.com on Thu, Oct 25, 2001 at 06:21:48PM -0400
Errors-To: owner-nanog-outgoing@merit.edu
--LQksG6bCIzRHxTLp
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
He said that the customer would be announcing a more specific from the ISP's
larger prefix. There should be no blackhole period, regardless, since the =
less
specific announcement would be used if the more specific isn't there yet.
Unless if I misread the OP's question?
-j
On Thu, Oct 25, 2001 at 06:21:48PM -0400, Christopher A. Woodfield wrote:
> Date: Thu, 25 Oct 2001 18:21:48 -0400
> To: CONWAY@pjm.com
> Cc: nanog@merit.edu
> Subject: Re: BGP advice: Customer converting from static ISP connection t=
o BGP
> From: "Christopher A. Woodfield" <rekoil@semihuman.com>
>=20
>=20
> There really won't be a "blackhole" period if you do it right - if it's=
=20
> the same network that's currently being statically routed, the easy thing=
=20
> to do is to keep that static route until the BGP connection is up. There=
=20
> shouldn't be any routing interruption during the time that both are activ=
e=20
> - there will just be two announcements with different origin ASes.=20
>=20
> The hard part is ensuring that the BGP prefix has propagated to the=20
> internet as a whole before you pull the static route and as a result the=
=20
> ISP-sourced prefix - the best thing to do is to check looking glasses=20
> (make sure you check several - some networks will not forward the "new"=
=20
> route if the old one has a better metric) to ensure propagation of the ne=
w=20
> route before you pull the static route.
>=20
> BGP routes typically take a few minutes to propagate globally, but this i=
s=20
> a case where as long as the previous origin AS - the ISP - properly=20
> forwards traffic to the destination after the static route is pulled=20
> (which it should, if the new BGP peering is active), there shouldn't be=
=20
> any problems; at worst there will be some odd traceroutes for a few=20
> minutes.
>=20
> -Chris
>=20
> On Thu, Oct 25, 2001 at 04:38:48PM -0400, CONWAY@pjm.com wrote:
> >=20
> >=20
> > I'm looking for some independent confirmation from someone experienced =
in
> > converting from a static routed ISP connection with the customer's netb=
lock
> > announced under the ISP's ASN to a BGP config where the customer has th=
eir own
> > ASN and netblock. We're the customer, and we're getting conflicting in=
fo on
> > what to expect during the conversion. =20
> >=20
> > Specifically, we're hearing conflicting things about how long it will t=
ake for
> > the "world" to recognize our routes, whether or not there may be areas =
of the
> > net "blackholed" from us for a while until things stabilize, etc. =20
> >=20
> > I realize this is probably off-topic for this list, so please direct an=
y replies
> > directly to me. If there is interest, I'm willing to summarize to the =
list.
> >=20
> > Chuck Conway
> > conway@pjm.com
>=20
> --=20
> ---------------------------
> Christopher A. Woodfield rekoil@semihuman.com
>=20
> PGP Public Key: http://pgp.mit.edu:11371/pks/lookup?op=3Dget&search=3D0xB=
887618B
---end quoted text---
--=20
Jason Legate
Sr. Net/Sys Admin, eVine, Inc.
work- jlegate@evine.com | home- jlegate@alienchick.com
Key Fingerprint: 4FB4 2228 DE63 3BBA 7B72 40DD 13D5 2547 821D 2909
--LQksG6bCIzRHxTLp
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (FreeBSD)
Comment: For info see http://www.gnupg.org
iD8DBQE72J7vE9UlR4IdKQkRAorDAJ4q8rTFmPzJkqW8by9tVUYqMAGZGQCglNZn
r58G5KRuSjK/S8wSosjkM9Y=
=IjJ+
-----END PGP SIGNATURE-----
--LQksG6bCIzRHxTLp--
