BGP neighbor/configuration testing

Mon Nov 25 18:48:15 UTC 2013

The turn-up was unsuccessful.  The provider and I could not get an Established BGP session.  Here's the log results from my router:

Nov 25 06:28:34.837 pacific: %BGP-3-NOTIFICATION: received from neighbor xxx.118.92.149 2/5 (authentication failure) 0 bytes
Nov 25 06:29:09.690 pacific: %BGP-5-ADJCHANGE: neighbor xxx.118.92.149 Up
Nov 25 06:29:10.562 pacific: %BGP-3-NOTIFICATION: received from neighbor xxx.118.92.149 6/1 (cease) 7 bytes 00010100 000320
Nov 25 06:29:10.562 pacific: %BGP-5-ADJCHANGE: neighbor xxx.118.92.149 Down BGP Notification received

My interface is at xxx.118.92.150.  They scrubbed their (Juniper) configuration and said all looks good.  I scrubbed my (Cisco) configuration - all I had was "neighbor xxx.118.92.149 remote-as xx9" and couldn't get the neighbor established.

Pings to xxx.118.92.149 are successful.  I have the output of "sh tcp brief all" and "sh tcp" - we are not getting the TCP connection to stay up.

Has anyone seen this series of messages on a Cisco/Juniper BGP session?  Any resolution?

>________________________________
> From: Joe Abley <jabley at hopcount.ca>
>To: Eric A Louie <elouie at yahoo.com> 
>Cc: "nanog at nanog.org" <nanog at nanog.org> 
>Sent: Wednesday, November 20, 2013 12:01 PM
>Subject: Re: BGP neighbor/configuration testing
> 
>
>
>On 2013-11-20, at 14:53, Eric A Louie <elouie at 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.
>> 
>>  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
>> 
>> A. Does that order make sense or does it need some tweaking, additions, or "other"?
>> 
>> 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
>
>
>