Re: BGP neighbor/configuration testing
Update. Turned up session with provider. They had to increase max-prefixes when I "no shutdown" my BGP session in order to Establish it, then decreased it to their standard customer value. Why it didn't come right up out of "no shutdown" and required the increase in max-prefix is still unknown. Subsequent resets of the BGP session brought the session down and back up. Shutdown/no shutdown will be tested tomorrow. It has been an excellent lesson in establishing a 2nd upstream provider on the same router. Something I'll be doing 2 more times next month. > > From: Eric A Louie >To: "nanog@nanog.org" >Sent: Monday, November 25, 2013 5:21 PM >Subject: Re: BGP neighbor/configuration testing > > >No logged error with mismatched neighbor IP address - neither router had an >entry. Session did not establish nor go active, I could wait forever and >neither would happen. Point is, an error message is not generated on the >downstream router so it's probably not the cause for the error message. > >I asked my upstream to check if the "local interface" command was being used >(that would cause the multihop, but I did put in 2 or 3 as the ebgp-multihop >value and still didn't get the session up. > >Your last comment about max-prefix is probably the problem and the solution. >Right now, the entire configuration is in the router with a "neighbor >shutdown". When we bring it up tomorrow, the filters will all be there so >that only 13 of my prefixes are advertised, hopefully keeping the BGP session >up and closing this saga. (the router already has another upstream connected, >so when I turned up the neighbor without a filter, I flooded the upstream's >router with routes, but it took us this long to figure that out.) > > > > >On a Cisco to Cisco when the max-prefixes is exceeded and there's a restart >specified, the error (on the offender) is not quite the same as the error I'm >seeing: >*Apr 9 02:41:39.827: %BGP-3-NOTIFICATION: received from neighbor >10.250.254.253 3/1 (update malformed) 0 bytes >*Apr 9 02:41:39.827: %BGP-5-ADJCHANGE: neighbor 10.250.254.253 Down BGP >Notification received > >On the upstream (where the max-prefix was configured), > >*Nov 26 04:10:02.108: %BGP-4-MAXPFX: No. of prefix received from >10.250.254.254 (afi 0) reaches 2, max 2 >*Nov 26 04:10:02.108: %BGP-3-MAXPFXEXCEED: No. of prefix received from >10.250.254.254 (afi 0): 3 exceed limit 2 >*Nov 26 04:10:02.108: %BGP-5-ADJCHANGE: neighbor 10.250.254.254 Down BGP >Notification sent >*Nov 26 04:10:02.108: %BGP-3-NOTIFICATION: sent to neighbor 10.250.254.254 3/1 >(update malformed) 0 bytes 0032 0200 >0000 1940 0101 0040 0204 0201 6A39 4003 040A FAFE FE80 0404 0802 > > > > > >> >> From: Chuck Anderson >>To: nanog@nanog.org >>Sent: Monday, November 25, 2013 3:37 PM >>Subject: Re: BGP neighbor/configuration testing >> >> >>When you say "no logged error" with mismatched neighbor IP address, >>what do you mean? Did the session just not establish at all? How >>long did you wait for it to attempt to establish? >> >>On Juniper, if it sees a BGP connection come from an IP address that >>doesn't match a local "neighbor" statement, it will send a BGP >>Notification, code 2 (Open Message Error), subcode 5 (authentication >>failure), which is exactly what you are seeing. >> >>If one side is using a loopback IP instead of a physical IP for the >>local-address, that would cause both a multihop/TTL issue and a >>neighbor IP mismatch. >> >>Another possibility is if you have exceeded the max prefix limit for >>the session. One side will get stuck in Idle state which may cause >>the other side to send the same "authentication failure" notification. >> >>On Mon, Nov 25, 2013 at 03:07:28PM -0800, Eric A Louie wrote: >>> All Cisco/Cisco, I don't have a Juniper here to test with >>> >>> mismatch AS >>> *Apr 9 00:31:47.691: %BGP-3-NOTIFICATION: received from neighbor >>> 10.250.254.253 2/2 (peer in wrong AS) 2 bytes 6A39 >>> >>> mismatch neighbor IP address >>> no logged error >>> >>> MTU mismatch >>> no logged error, session remained up >>> >>> Subnet mask mismatch >>> session remained up, no logged error >>> >>> I haven't created the multihop scenario to see the error messages. >>> >>> >>> None of these issues caused the (authentication failure). >>> >>> >>> >>> >>> >>> > >>> > From: Chuck Anderson >>> >To: nanog@nanog.org >>> >Sent: Monday, November 25, 2013 11:10 AM >>> >Subject: Re: BGP neighbor/configuration testing >>> > >>> > >>> >Authentication failure might mean (without knowing for sure which on >>> >Cisco): >>> > >>> >- mismatch AS numbers >>> >- mismatch neighbor IP addresses >>> >- multihop/TTL issues >>> >- MTU issues >> >> >> >> > > >
Re: BGP neighbor/configuration testing
No logged error with mismatched neighbor IP address - neither router had an entry. Session did not establish nor go active, I could wait forever and neither would happen. Point is, an error message is not generated on the downstream router so it's probably not the cause for the error message. I asked my upstream to check if the "local interface" command was being used (that would cause the multihop, but I did put in 2 or 3 as the ebgp-multihop value and still didn't get the session up. Your last comment about max-prefix is probably the problem and the solution. Right now, the entire configuration is in the router with a "neighbor shutdown". When we bring it up tomorrow, the filters will all be there so that only 13 of my prefixes are advertised, hopefully keeping the BGP session up and closing this saga. (the router already has another upstream connected, so when I turned up the neighbor without a filter, I flooded the upstream's router with routes, but it took us this long to figure that out.) On a Cisco to Cisco when the max-prefixes is exceeded and there's a restart specified, the error (on the offender) is not quite the same as the error I'm seeing: *Apr 9 02:41:39.827: %BGP-3-NOTIFICATION: received from neighbor 10.250.254.253 3/1 (update malformed) 0 bytes *Apr 9 02:41:39.827: %BGP-5-ADJCHANGE: neighbor 10.250.254.253 Down BGP Notification received On the upstream (where the max-prefix was configured), *Nov 26 04:10:02.108: %BGP-4-MAXPFX: No. of prefix received from 10.250.254.254 (afi 0) reaches 2, max 2 *Nov 26 04:10:02.108: %BGP-3-MAXPFXEXCEED: No. of prefix received from 10.250.254.254 (afi 0): 3 exceed limit 2 *Nov 26 04:10:02.108: %BGP-5-ADJCHANGE: neighbor 10.250.254.254 Down BGP Notification sent *Nov 26 04:10:02.108: %BGP-3-NOTIFICATION: sent to neighbor 10.250.254.254 3/1 (update malformed) 0 bytes 0032 0200 1940 0101 0040 0204 0201 6A39 4003 040A FAFE FE80 0404 0802 > > From: Chuck Anderson >To: nanog@nanog.org >Sent: Monday, November 25, 2013 3:37 PM >Subject: Re: BGP neighbor/configuration testing > > >When you say "no logged error" with mismatched neighbor IP address, >what do you mean? Did the session just not establish at all? How >long did you wait for it to attempt to establish? > >On Juniper, if it sees a BGP connection come from an IP address that >doesn't match a local "neighbor" statement, it will send a BGP >Notification, code 2 (Open Message Error), subcode 5 (authentication >failure), which is exactly what you are seeing. > >If one side is using a loopback IP instead of a physical IP for the >local-address, that would cause both a multihop/TTL issue and a >neighbor IP mismatch. > >Another possibility is if you have exceeded the max prefix limit for >the session. One side will get stuck in Idle state which may cause >the other side to send the same "authentication failure" notification. > >On Mon, Nov 25, 2013 at 03:07:28PM -0800, Eric A Louie wrote: >> All Cisco/Cisco, I don't have a Juniper here to test with >> >> mismatch AS >> *Apr 9 00:31:47.691: %BGP-3-NOTIFICATION: received from neighbor >> 10.250.254.253 2/2 (peer in wrong AS) 2 bytes 6A39 >> >> mismatch neighbor IP address >> no logged error >> >> MTU mismatch >> no logged error, session remained up >> >> Subnet mask mismatch >> session remained up, no logged error >> >> I haven't created the multihop scenario to see the error messages. >> >> >> None of these issues caused the (authentication failure). >> >> >> >> >> >> > >> > From: Chuck Anderson >> >To: nanog@nanog.org >> >Sent: Monday, November 25, 2013 11:10 AM >> >Subject: Re: BGP neighbor/configuration testing >> > >> > >> >Authentication failure might mean (without knowing for sure which on >> >Cisco): >> > >> >- mismatch AS numbers >> >- mismatch neighbor IP addresses >> >- multihop/TTL issues >> >- MTU issues > > > >
Re: BGP neighbor/configuration testing
When you say "no logged error" with mismatched neighbor IP address, what do you mean? Did the session just not establish at all? How long did you wait for it to attempt to establish? On Juniper, if it sees a BGP connection come from an IP address that doesn't match a local "neighbor" statement, it will send a BGP Notification, code 2 (Open Message Error), subcode 5 (authentication failure), which is exactly what you are seeing. If one side is using a loopback IP instead of a physical IP for the local-address, that would cause both a multihop/TTL issue and a neighbor IP mismatch. Another possibility is if you have exceeded the max prefix limit for the session. One side will get stuck in Idle state which may cause the other side to send the same "authentication failure" notification. On Mon, Nov 25, 2013 at 03:07:28PM -0800, Eric A Louie wrote: > All Cisco/Cisco, I don't have a Juniper here to test with > > mismatch AS > *Apr 9 00:31:47.691: %BGP-3-NOTIFICATION: received from neighbor > 10.250.254.253 2/2 (peer in wrong AS) 2 bytes 6A39 > > mismatch neighbor IP address > no logged error > > MTU mismatch > no logged error, session remained up > > Subnet mask mismatch > session remained up, no logged error > > I haven't created the multihop scenario to see the error messages. > > > None of these issues caused the (authentication failure). > > > > > > >____ > > From: Chuck Anderson > >To: nanog@nanog.org > >Sent: Monday, November 25, 2013 11:10 AM > >Subject: Re: BGP neighbor/configuration testing > > > > > >Authentication failure might mean (without knowing for sure which on > >Cisco): > > > >- mismatch AS numbers > >- mismatch neighbor IP addresses > >- multihop/TTL issues > >- MTU issues
Re: BGP neighbor/configuration testing
The auth error was transient, forget about it. Now you're getting 6/1 - maximum number of prefixes reached. http://tools.ietf.org/html/rfc4486 (or http://backupsalmanaja.blogspot.ie/2009/12/bgp-cease-notification-messages.htmlif you prefer). HTH On 25 November 2013 23:07, Eric A Louie wrote: > All Cisco/Cisco, I don't have a Juniper here to test with > > mismatch AS > *Apr 9 00:31:47.691: %BGP-3-NOTIFICATION: received from neighbor > 10.250.254.253 2/2 (peer in wrong AS) 2 bytes 6A39 > > mismatch neighbor IP address > no logged error > > MTU mismatch > no logged error, session remained up > > Subnet mask mismatch > session remained up, no logged error > > I haven't created the multihop scenario to see the error messages. > > > None of these issues caused the (authentication failure). > > > > > > > > > From: Chuck Anderson > >To: nanog@nanog.org > >Sent: Monday, November 25, 2013 11:10 AM > >Subject: Re: BGP neighbor/configuration testing > > > > > >Authentication failure might mean (without knowing for sure which on > >Cisco): > > > >- mismatch AS numbers > >- mismatch neighbor IP addresses > >- multihop/TTL issues > >- MTU issues > > > >On Mon, Nov 25, 2013 at 11:06:33AM -0800, Eric A Louie wrote: > >> That's a natural first impression but there are no passwords configured > on the BGP session on either router. I know it looks like an > authentication error but it's a "misnomer" (at least from the searches I > did on the error message). From the sequence of messages, we get > Established and 2 seconds later the session Closes. The reason for the > Close may lead us to the solution. > >> > >> I'm reluctant to turn on debug bgp because this is a live production > router, and if I hose it, there will be a lot of 'splainin to do [1] > >> > >> [1] > http://www.quotecounterquote.com/2011/05/lucy-you-got-some-splainin-to-do.html > >> > >> > >> > >> > >> > >> > > >> > From: Daniel Rohan > >> >To: Eric A Louie > >> >Cc: Joe Abley ; "nanog@nanog.org" > > >> >Sent: Monday, November 25, 2013 10:55 AM > >> >Subject: Re: BGP neighbor/configuration testing > >> > > >> > > >> > > >> >Seems like: > >> > > >> >Nov 25 06:28:34.837 pacific: %BGP-3-NOTIFICATION: received from > neighbor xxx.118.92.149 2/5 (authentication failure) 0 bytes > >> >> > >> >should be a good starting place. I'm assuming you've already discussed > auth keys with your provider and if everyone is putting that in correctly, > I'd suggest turning on debugging to see what exactly that message is all > about. > >> > > >> > > >> >Dan > > > > > > > > >
Re: BGP neighbor/configuration testing
All Cisco/Cisco, I don't have a Juniper here to test with mismatch AS *Apr 9 00:31:47.691: %BGP-3-NOTIFICATION: received from neighbor 10.250.254.253 2/2 (peer in wrong AS) 2 bytes 6A39 mismatch neighbor IP address no logged error MTU mismatch no logged error, session remained up Subnet mask mismatch session remained up, no logged error I haven't created the multihop scenario to see the error messages. None of these issues caused the (authentication failure). > > From: Chuck Anderson >To: nanog@nanog.org >Sent: Monday, November 25, 2013 11:10 AM >Subject: Re: BGP neighbor/configuration testing > > >Authentication failure might mean (without knowing for sure which on >Cisco): > >- mismatch AS numbers >- mismatch neighbor IP addresses >- multihop/TTL issues >- MTU issues > >On Mon, Nov 25, 2013 at 11:06:33AM -0800, Eric A Louie wrote: >> That's a natural first impression but there are no passwords configured on >> the BGP session on either router. I know it looks like an authentication >> error but it's a "misnomer" (at least from the searches I did on the error >> message). From the sequence of messages, we get Established and 2 seconds >> later the session Closes. The reason for the Close may lead us to the >> solution. >> >> I'm reluctant to turn on debug bgp because this is a live production router, >> and if I hose it, there will be a lot of 'splainin to do [1] >> >> [1] >> http://www.quotecounterquote.com/2011/05/lucy-you-got-some-splainin-to-do.html >> >> >> >> >> >> >________ >> > From: Daniel Rohan >> >To: Eric A Louie >> >Cc: Joe Abley ; "nanog@nanog.org" >> >Sent: Monday, November 25, 2013 10:55 AM >> >Subject: Re: BGP neighbor/configuration testing >> > >> > >> > >> >Seems like: >> > >> >Nov 25 06:28:34.837 pacific: %BGP-3-NOTIFICATION: received from neighbor >> >xxx.118.92.149 2/5 (authentication failure) 0 bytes >> >> >> >should be a good starting place. I'm assuming you've already discussed auth >> >keys with your provider and if everyone is putting that in correctly, I'd >> >suggest turning on debugging to see what exactly that message is all about. >> > >> > >> >Dan > > > >
Re: BGP neighbor/configuration testing
Authentication failure might mean (without knowing for sure which on Cisco): - mismatch AS numbers - mismatch neighbor IP addresses - multihop/TTL issues - MTU issues On Mon, Nov 25, 2013 at 11:06:33AM -0800, Eric A Louie wrote: > That's a natural first impression but there are no passwords configured on > the BGP session on either router. I know it looks like an authentication > error but it's a "misnomer" (at least from the searches I did on the error > message). From the sequence of messages, we get Established and 2 seconds > later the session Closes. The reason for the Close may lead us to the > solution. > > I'm reluctant to turn on debug bgp because this is a live production router, > and if I hose it, there will be a lot of 'splainin to do [1] > > [1] > http://www.quotecounterquote.com/2011/05/lucy-you-got-some-splainin-to-do.html > > > > > > > > > From: Daniel Rohan > >To: Eric A Louie > >Cc: Joe Abley ; "nanog@nanog.org" > >Sent: Monday, November 25, 2013 10:55 AM > >Subject: Re: BGP neighbor/configuration testing > > > > > > > >Seems like: > > > >Nov 25 06:28:34.837 pacific: %BGP-3-NOTIFICATION: received from neighbor > >xxx.118.92.149 2/5 (authentication failure) 0 bytes > >> > >should be a good starting place. I'm assuming you've already discussed auth > >keys with your provider and if everyone is putting that in correctly, I'd > >suggest turning on debugging to see what exactly that message is all about. > > > > > >Dan
Re: BGP neighbor/configuration testing
That's a natural first impression but there are no passwords configured on the BGP session on either router. I know it looks like an authentication error but it's a "misnomer" (at least from the searches I did on the error message). From the sequence of messages, we get Established and 2 seconds later the session Closes. The reason for the Close may lead us to the solution. I'm reluctant to turn on debug bgp because this is a live production router, and if I hose it, there will be a lot of 'splainin to do [1] [1] http://www.quotecounterquote.com/2011/05/lucy-you-got-some-splainin-to-do.html > > From: Daniel Rohan >To: Eric A Louie >Cc: Joe Abley ; "nanog@nanog.org" >Sent: Monday, November 25, 2013 10:55 AM >Subject: Re: BGP neighbor/configuration testing > > > >Seems like: > >Nov 25 06:28:34.837 pacific: %BGP-3-NOTIFICATION: received from neighbor >xxx.118.92.149 2/5 (authentication failure) 0 bytes >> >should be a good starting place. I'm assuming you've already discussed auth >keys with your provider and if everyone is putting that in correctly, I'd >suggest turning on debugging to see what exactly that message is all about. > > >Dan > >
RE: BGP neighbor/configuration testing
Here are a couple of examples of syslog messages that could be seen depending on the configuration of the MD5 passwords on each side: Troubleshooting Examples If BGP neighbor authentication is incorrectly configured (for example, it is either configured on only one peer or the MD5 shared secret (password) does not match on both peers), the following types of syslog messages will be generated: No Password Set on Remote Peer Dec 3 15:01:52: %TCP-6-BADAUTH: No MD5 digest from 192.0.2.2(179) to 192.0.2.1(51954) Incorrect Password Set on Remote Peer Dec 3 15:01:57: %TCP-6-BADAUTH: Invalid MD5 digest from 192.0.2.2(22285) to 192.0.2.1(179) Thanks, John "We can't help everyone, but everyone can help someone." John Stuppi, CISSP Technical Leader Strategic Security Research jstu...@cisco.com Phone: +1 732 516 5994 Mobile: 732 319 3886 CCIE, Security - 11154 Cisco Systems Mail Stop INJ01/2/ 111 Wood Avenue South Iselin, New Jersey 08830 United States Cisco.com Think before you print. This email may contain confidential and privileged material for the sole use of the intended recipient. Any review, use, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender by reply email and delete all copies of this message. For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html -Original Message- From: Daniel Rohan [mailto:dro...@gmail.com] Sent: Monday, November 25, 2013 1:56 PM To: Eric A Louie Cc: nanog@nanog.org Subject: Re: BGP neighbor/configuration testing Seems like: > Nov 25 06:28:34.837 pacific: %BGP-3-NOTIFICATION: received from > neighbor > xxx.118.92.149 2/5 (authentication failure) 0 bytes > should be a good starting place. I'm assuming you've already discussed auth keys with your provider and if everyone is putting that in correctly, I'd suggest turning on debugging to see what exactly that message is all about. Dan
Re: BGP neighbor/configuration testing
Seems like: > Nov 25 06:28:34.837 pacific: %BGP-3-NOTIFICATION: received from neighbor > xxx.118.92.149 2/5 (authentication failure) 0 bytes > should be a good starting place. I'm assuming you've already discussed auth keys with your provider and if everyone is putting that in correctly, I'd suggest turning on debugging to see what exactly that message is all about. Dan
Re: BGP neighbor/configuration testing
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 >To: Eric A Louie >Cc: "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 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 > > >
Re: BGP neighbor/configuration testing
On 11/20/13, 11:53 AM, Eric A Louie 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) normally you just bring up the session with restrictive import/export e.g. reject all and see what they send you. that was you can verify what's copacetic before you employ it. > 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) Apply the export policy associated with sending your prefix to them. assume they're using rpf and they'll blackhole any traffic from you until they receive a prefix that it's coming from and install it in their fib If they're sending you a full table (and you also have a full table from your other provider), then alter the import policy to accept routes from them. > 5. Turn down the old connection (neighbor shutdown) once the above has been stable for a while... apply new import export policy (e.g. reject all) and clear soft in out the session. once there's no traffic on it and everything else hasn't caught fire shut down the bgp session > 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. > > > > thanks for your input > Eric > > signature.asc Description: OpenPGP digital signature
Re: BGP neighbor/configuration testing
On 2013-11-20, at 14:53, Eric A Louie 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
BGP neighbor/configuration testing
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) 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) 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. thanks for your input Eric
