[j-nsp] BGP session is not coming up

Richard A Steenbergen ras at e-gerbil.net
Thu Jul 23 10:36:03 EDT 2009


On Wed, Jul 22, 2009 at 03:58:54PM +0200, Matthias Gelbhardt wrote:
> Hi!
> 
> I get an error message:
> 
> Jul 22 14:53:48.164226 BGP RECV Notification code 2 (Open Message  
> Error) subcode 5 (authentication failure)
> 
> And I think that explains itself. I have reconfigured the box so many  
> times now, that I am certain, that the problem is not on our side. The  
> MD5 key is the one, we have agreed upon. On the other side is a  
> provider, so we are unable to get a hold on the remote side.

The problem can't be an MD5 mismatch (assuming the routers have a
functioning tcp md5 implementation, which I'm going to assume is the
case since clearly one side is a Juniper). If there was a mismatch the
TCP session wouldn't be able to form in the first place, since BGP MD5 
protects the entire TCP session not just the BGP session.

Your neighbor is dropping you for some other reason as soon as it hears
who you are. There are basically two common causes of something like
this, the first is when the other side is running a router (typically a
very crappy and easy to DoS one, i.e. last I looked Force10 did this,
etc) which isn't capable of restricting the TCP session establishment to
only configured neighbors. It will allow you to connect, you'll exchange
your BGP Open message, and then it will say "we don't have a session for
you, go away". Since you claim to have a negotiated MD5 key with your
neighbor this seems unlikely, again assuming that they have a working
tcp md5 implementation (some crappy/software routers don't, they may
signal it but they don't actually enforce it). The other common cause is
when your session is being held in an idle state for some reason, such
as after you've tripped a max prefix limit for example. Some router
vendors implement this idle state as a virtual "your neighbor does not
exist" state, which causes the other side to return an authentication
failure.

The other side should be able to look at their logs and determine the 
reason easily enough. If it takes them longer than 30 secs, you need to 
find yourself a new provider.

-- 
Richard A Steenbergen <ras at e-gerbil.net>       http://www.e-gerbil.net/ras
GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)


More information about the juniper-nsp mailing list