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 <jab...@hopcount.ca> >To: Eric A Louie <elo...@yahoo.com> >Cc: "nanog@nanog.org" <nanog@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 <elo...@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 > > >
