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
On 2013-11-20, at 14:53, Eric A Louie <elouie@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
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@hopcount.ca> To: Eric A Louie <elouie@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 <elouie@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
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
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 jstuppi@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:drohan@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
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.ht...
________________________________ From: Daniel Rohan <drohan@gmail.com> To: Eric A Louie <elouie@yahoo.com> Cc: Joe Abley <jabley@hopcount.ca>; "nanog@nanog.org" <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
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.ht...
________________________________ From: Daniel Rohan <drohan@gmail.com> To: Eric A Louie <elouie@yahoo.com> Cc: Joe Abley <jabley@hopcount.ca>; "nanog@nanog.org" <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
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 <cra@WPI.EDU> 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.ht...
________________________________ From: Daniel Rohan <drohan@gmail.com> To: Eric A Louie <elouie@yahoo.com> Cc: Joe Abley <jabley@hopcount.ca>; "nanog@nanog.org" <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
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.h... you prefer). HTH On 25 November 2013 23:07, Eric A Louie <elouie@yahoo.com> 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 <cra@WPI.EDU> 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.ht...
________________________________ From: Daniel Rohan <drohan@gmail.com> To: Eric A Louie <elouie@yahoo.com> Cc: Joe Abley <jabley@hopcount.ca>; "nanog@nanog.org" <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
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 <cra@WPI.EDU> 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
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 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF 0032 0200 0000 1940 0101 0040 0204 0201 6A39 4003 040A FAFE FE80 0404 0000 0000 0802
________________________________ From: Chuck Anderson <cra@WPI.EDU> 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 <cra@WPI.EDU> 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
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 <elouie@yahoo.com> To: "nanog@nanog.org" <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 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF 0032 0200 0000 1940 0101 0040 0204 0201 6A39 4003 040A FAFE FE80 0404 0000 0000 0802
________________________________ From: Chuck Anderson <cra@WPI.EDU> 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 <cra@WPI.EDU> 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 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
participants (7)
-
Chuck Anderson -
Daniel Rohan -
Eric A Louie -
Joe Abley -
joel jaeggli -
John Stuppi (jstuppi) -
Pedro Cavaca