[166930] in North American Network Operators' Group
Re: BGP neighbor/configuration testing
daemon@ATHENA.MIT.EDU (joel jaeggli)
Wed Nov 20 15:07:35 2013
Date: Wed, 20 Nov 2013 12:07:00 -0800
From: joel jaeggli <joelja@bogus.com>
To: Eric A Louie <elouie@yahoo.com>, "nanog@nanog.org" <nanog@nanog.org>
In-Reply-To: <1384977234.24290.YahooMailNeo@web181604.mail.ne1.yahoo.com>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--pfdjCITKR96AghWbkq7aPBLMwRcI6QXxA
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On 11/20/13, 11:53 AM, Eric A Louie wrote:
> Scenario: a regional ISP preparing to cutover to a new upstream BGP pro=
vider at one of my POPs. Want minimal or no network disruption, and want=
to ensure everything is ready to go prior to the cutover.
>=20
> I'm planning to use the following order of operations:
> 1. Establish IP connectivity to the new ISP (already done)
> 2. Configure my BGP router and shutdown the new neighbor (ISP says thei=
r side is already configured and ready)
normally you just bring up the session with restrictive import/export
e.g. reject all and see what they send you. that was you can verify
what's copacetic before you employ it.
> 3. During the maintenance window for this change, activate the new BGP =
connection (remove neighbor shutdown)
> 4. Do the appropriate tests (sh bgp nei, login to my upstream's route s=
erver and check route advertisements, sign in to looking glass and/or rou=
te servers from other providers to see if my routes from the new ISP are =
being advertised, and I'm open to any other tests)
Apply the export policy associated with sending your prefix to them.
assume they're using rpf and they'll blackhole any traffic from you
until they receive a prefix that it's coming from and install it in
their fib
If they're sending you a full table (and you also have a full table from
your other provider), then alter the import policy to accept routes from
them.
> 5. Turn down the old connection (neighbor shutdown)
once the above has been stable for a while...
apply new import export policy (e.g. reject all) and clear soft in out
the session.
once there's no traffic on it and everything else hasn't caught fire
shut down the bgp session
> 6. Watch the old connection get removed from route servers/looking glas=
ses from step 4
> A. Does that order make sense or does it need some tweaking, additions,=
or "other"?
>=20
> B. I'd like to test the new upstream BGP configuration without passing =
traffic to and through it. What can I do (if anything) on my configurati=
on end to put up the BGP configuration, establish a neighbor connection, =
and NOT actually pass any traffic through it? After putting my configura=
tion up, I'd like to do a show bgp nei 1.1.1.1 advertised-routes to ensur=
e my routes are going out, and then shut the neighbor down until the cuto=
ver.
>=20
>=20
>=20
> thanks for your input
> Eric
>=20
>=20
--pfdjCITKR96AghWbkq7aPBLMwRcI6QXxA
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlKNFmUACgkQ8AA1q7Z/VrJWTwCeNK4RGp3i9l0SQeydhPX5/9+a
gxUAni79sHDShal4vx+pBIMwzfCrA7X+
=sHAu
-----END PGP SIGNATURE-----
--pfdjCITKR96AghWbkq7aPBLMwRcI6QXxA--
