BGP neighbor/configuration testing

Tue Nov 26 13:05:05 UTC 2013

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 at yahoo.com>
>To: "nanog at nanog.org" <nanog at 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 at WPI.EDU>
>>To: nanog at 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 at WPI.EDU>
>>> >To: nanog at 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
>>
>>
>>
>>
>
>
>