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
signature.asc
Description: Message signed with OpenPGP using GPGMail
