[166929] in North American Network Operators' Group
Re: BGP neighbor/configuration testing
daemon@ATHENA.MIT.EDU (Joe Abley)
Wed Nov 20 15:02:23 2013
From: Joe Abley <jabley@hopcount.ca>
In-Reply-To: <1384977234.24290.YahooMailNeo@web181604.mail.ne1.yahoo.com>
Date: Wed, 20 Nov 2013 15:01:33 -0500
To: Eric A Louie <elouie@yahoo.com>
Cc: "nanog@nanog.org" <nanog@nanog.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
--Apple-Mail=_5EEA776B-4238-4B69-AFDB-1D20EBFAB023
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=iso-8859-1
On 2013-11-20, at 14:53, Eric A Louie <elouie@yahoo.com> wrote:
> Scenario: a regional ISP preparing to cutover to a new upstream BGP =
provider 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 =
their side is already configured and ready)
Leave the adjacency up, and just deny all inbound and outbound on the =
corresponding route filter. You never want a maintenance's success to =
depend on "no neigh x.x.x.x shut" working smoothly; much better to be =
able to confirm that the session is up before you start and just change =
the import/export policy.
> 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 =
server and check route advertisements, sign in to looking glass and/or =
route servers from other providers to see if my routes from the new ISP =
are being advertised, and I'm open to any other tests)
You could insert "wait N days" here, with a rollback plan (e.g. in case =
of customer-enraging congestion or packet loss) that restores the =
original configuration by shutting down the new adjacency.
> 5. Turn down the old connection (neighbor shutdown)
> 6. Watch the old connection get removed from route servers/looking =
glasses from step 4
>=20
> 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 =
configuration end to put up the BGP configuration, establish a neighbor =
connection, and NOT actually pass any traffic through it? After putting =
my configuration up, I'd like to do a show bgp nei 1.1.1.1 =
advertised-routes to ensure my routes are going out, and then shut the =
neighbor down until the cutover.
Bring the session up with deny all in both directions, and use the =
appropriate show commands (show neigh ... received-routes since you're =
talking cisco) to show what routes were received upstream of the filter. =
You are presumably already testing your export policy on your live =
session; if the configuration on the new session is the same, then =
you're really just talking about making sure that the internal route set =
visible on the router with the new session is right.
Joe
--Apple-Mail=_5EEA776B-4238-4B69-AFDB-1D20EBFAB023
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename=signature.asc
Content-Type: application/pgp-signature;
name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org
iEYEARECAAYFAlKNFR0ACgkQNI8MvYZSOizVNACgimdFVTkMqybHYEvz/e2xhAbQ
QpMAoMC0AdF7gCA5GtCUKqyXv1rXeaT8
=gt2N
-----END PGP SIGNATURE-----
--Apple-Mail=_5EEA776B-4238-4B69-AFDB-1D20EBFAB023--
