[166990] in North American Network Operators' Group
Re: BGP neighbor/configuration testing
daemon@ATHENA.MIT.EDU (Eric A Louie)
Mon Nov 25 13:48:28 2013
Date: Mon, 25 Nov 2013 10:48:15 -0800 (PST)
From: Eric A Louie <elouie@yahoo.com>
To: Joe Abley <jabley@hopcount.ca>
In-Reply-To: <CAB5C992-2932-4D7D-979C-65B408C31257@hopcount.ca>
Cc: "nanog@nanog.org" <nanog@nanog.org>
Reply-To: Eric A Louie <elouie@yahoo.com>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
The turn-up was unsuccessful.=A0 The provider and I could not get an Establ=
ished BGP session.=A0 Here's the log results from my router:=0A=0ANov 25 06=
:28:34.837 pacific: %BGP-3-NOTIFICATION: received from neighbor xxx.118.92.=
149 2/5 (authentication failure) 0 bytes=0ANov 25 06:29:09.690 pacific: %BG=
P-5-ADJCHANGE: neighbor xxx.118.92.149 Up=0ANov 25 06:29:10.562 pacific: %B=
GP-3-NOTIFICATION: received from neighbor xxx.118.92.149 6/1 (cease) 7 byte=
s 00010100 000320=0ANov 25 06:29:10.562 pacific: %BGP-5-ADJCHANGE: neighbor=
xxx.118.92.149 Down BGP Notification received=0A=0AMy interface is at xxx.=
118.92.150.=A0 They scrubbed their (Juniper) configuration and said all loo=
ks good.=A0 I scrubbed my (Cisco) configuration - all I had was "neighbor x=
xx.118.92.149 remote-as xx9" and couldn't get the neighbor established.=0A=
=0APings to xxx.118.92.149 are successful.=A0 I have the output of "sh tcp =
brief all" and "sh tcp" - we are not getting the TCP connection to stay up.=
=0A=0AHas anyone seen this series of messages on a Cisco/Juniper BGP sessio=
n?=A0 Any resolution?=0A=0A=0A=0A=0A=0A=0A>________________________________=
=0A> From: Joe Abley <jabley@hopcount.ca>=0A>To: Eric A Louie <elouie@yahoo=
.com> =0A>Cc: "nanog@nanog.org" <nanog@nanog.org> =0A>Sent: Wednesday, Nove=
mber 20, 2013 12:01 PM=0A>Subject: Re: BGP neighbor/configuration testing=
=0A> =0A>=0A>=0A>On 2013-11-20, at 14:53, Eric A Louie <elouie@yahoo.com> w=
rote:=0A>=0A>> Scenario: a regional ISP preparing to cutover to a new upstr=
eam BGP provider at one of my POPs.=A0 Want minimal or no network disruptio=
n, and want to ensure everything is ready to go prior to the cutover.=0A>> =
=0A>>=A0 I'm planning to use the following order of operations:=0A>> 1. Est=
ablish IP connectivity to the new ISP (already done)=0A>> 2. Configure my B=
GP router and shutdown the new neighbor (ISP says their side is already con=
figured and ready)=0A>=0A>Leave the adjacency up, and just deny all inbound=
and outbound on the corresponding route filter. You never want a maintenan=
ce's success to depend on "no neigh x.x.x.x shut" working smoothly; much be=
tter to be able to confirm that the session is up before you start and just=
change the import/export policy.=0A>=0A>> 3. During the maintenance window=
for this change, activate the new BGP connection (remove neighbor shutdown=
)=0A>> 4. Do the appropriate tests (sh bgp nei, login to my upstream's rout=
e server and check route advertisements, sign in to looking glass and/or ro=
ute servers from other providers to see if my routes from the new ISP are b=
eing advertised, and I'm open to any other tests)=0A>=0A>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 shut=
ting down the new adjacency.=0A>=0A>> 5. Turn down the old connection (neig=
hbor shutdown)=0A>> 6. Watch the old connection get removed from route serv=
ers/looking glasses from step 4=0A>> =0A>> A. Does that order make sense or=
does it need some tweaking, additions, or "other"?=0A>> =0A>> B. I'd like =
to test the new upstream BGP configuration without passing traffic to and t=
hrough it.=A0 What can I do (if anything) on my configuration end to put up=
the BGP configuration, establish a neighbor connection, and NOT actually p=
ass any traffic through it?=A0 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 goin=
g out, and then shut the neighbor down until the cutover.=0A>=0A>Bring the =
session up with deny all in both directions, and use the appropriate show c=
ommands (show neigh ... received-routes since you're talking cisco) to show=
what routes were received upstream of the filter. You are presumably alrea=
dy 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.=0A>=0A>=0A>Joe=0A>=0A>=0A>
