nanog mailing list archives

Re: BGP neighbor/configuration testing


From: Eric A Louie <elouie () yahoo com>
Date: Tue, 26 Nov 2013 05:05:05 -0800 (PST)

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









Current thread: