[j-nsp] BGP session is not coming up

[Matthias Gelbhardt]

Hi!

We have a problem with a BGP session. The session is not coming up,
and I dont know why. It is a eBGP session:

Log:

Jul 22 08:30:08 muenster /kernel: tcp_auth_ok: Packet from x.x.x.x:
179 missing MD5 digest

tracelog:

Jul 22 08:50:16.426122 bgp_connect_complete: error connecting to
x.x.x.x (External AS x): Socket is not connected

tcpdump;

08:49:07.632649 Out IP x.x.x.x.60582 > x.x.x.x.179: S
594093001:594093001(0) win 16384 <mss 1460,nop,wscale
0,nop,nop,timestamp[|tcp]>

config:

group external {
type external;
neighbor xx {
description uplink_;
local-address xx;
import import_bgp_;
inactive: authentication-key "$9$u-xxx"; ## SECRET-DATA
export [ export_prepend export_bgp_external ];
peer-as xx;
}
}

Any ideas?

Leaving the MD5 does not work, I even have restartet the routing
process with no luck.

Matthias

_______________________________________________
juniper-nsp mailing list junip...@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[Matthias Gelbhardt]

Hi!

After deleting the local-address (and testing with multihop) I get

Jul 22 09:13:41.322465 advertising receiving-speaker only capabilty to
neighbor x.x.x.x (External AS xx)
Jul 22 09:13:41.323342 bgp_send: sending 59 bytes to x.x.x.x (External
AS xx)
Jul 22 09:13:41.323954
Jul 22 09:13:41.323954 BGP SEND x.x.x.x+52277 -> x.x.x.x+179
Jul 22 09:13:41.325172 BGP SEND message type 1 (Open) length 59
Jul 22 09:13:41.327835
Jul 22 09:13:41.327835 BGP RECV x.x.x.x+179 -> x.x.x.x+52277
Jul 22 09:13:41.329110 BGP RECV message type 1 (Open) length 29
Jul 22 09:13:41.329866
Jul 22 09:13:41.329866 BGP RECV x.x.x.x+179 -> x.x.x.x+52277
Jul 22 09:13:41.331374 BGP RECV message type 3 (Notification) length 21

The strange thing: That has stopped working out of the blue. As this
is a provider, we are unable to get the other side.

Matthias

Am 22.07.2009 um 09:04 schrieb Muhammad Aamir:

> Dear matthias,
>
> Have u tried this with "multihop", Because you have used local-
> address in your ebgp config. If local address is your loopback
> interface then you need to configure multihop. Also please share the
> remote end config as well if possible.
>
> Regards.
>
> Aamir

[Truman Boyes]

You might want to turn on more traceoptions. You are receiving a
notification message which should indicate the problem. The
notification code and subcode will help to find out the issue.

Truman Boyes

[Nalkhande Tarique Abbas]

Hey Mathhias,

Any filter on the interface? Config of interface pls?

As Truman also pointed out,

Can you pls share,
show log messages | match NOTIFICATION

This would help to identify the BGP Notification code/subcode.

Thanks & Regards,
Tarique A. Nalkhande

[Hendrik Kahmann]

Hello Matthias,

the log tells me, that there is a missing md5 key for this connection. In
your config this part is "inactive". Maybe you should compare the
eBGP-Config on both machines to check if md5 authentication is needed on one
side. Why did you deactivate the authentication key in here? Did you
specifiy your local AS in the config?

Kind regards from Oldenburg,

Hendrik

-----Ursprüngliche Nachricht-----
Von: juniper-n...@puck.nether.net
[mailto:juniper-n...@puck.nether.net] Im Auftrag von Matthias
Gelbhardt
Gesendet: Mittwoch, 22. Juli 2009 08:56
An: juniper-nsp
Betreff: [j-nsp] BGP session is not coming up

[Matthias Gelbhardt]

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.

Regards,

Matthias

[Truman Boyes]

I think you will need to ask the provider to renter the key or remove
it to verify that the session will come up. Possibly they changed it
on their end.

[Alex]

Matthias,
Check if netmask on the peer-facing interface covers the peer IP address. I
once configured wrong netmask (/32) on Ethernet interface connected to a
peer and got exactly the same BGP error message. If that's the case, you
should get more BGP-related messages in syslog, saying "interface/group not
found" or similar to that matter. Strange thing was that I could ping the
peer IP just fine.
When I reconfigured the netmask, BGP session went up immediately.
Rgds
Alex

[Richard A Steenbergen]

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 <r...@e-gerbil.net> http://www.e-gerbil.net/ras
GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)