(4.8) OpenBGPd sometimes does not send the routes to the peer.

Discussion:

Patrick Lamaiziere

2010-11-03 14:29:37 UTC

(4.8/amd64)

Hello,

I'm doing some tests with OpenBGPd and sometimes (but often), when I
restart bgpd it does not send anymore the routes to the peer.
The routes are static and configured into bgpd.conf

How to repeat:
# bgpd -d -v
wait until the routes are sent to the peer.
^D
shoot again

After few tests (around 5), bgpd does not send the routes :

# bgpctl sh rib out nei RenaterV4
flags: * = Valid, > = Selected, I = via IBGP, A = Announced
origin: i = IGP, e = EGP, ? = Incomplete

flags destination gateway lpref med aspath origin
-----

But it gets the incoming routes from the peer

# bgpctl sh rib in nei RenaterV4
flags: * = Valid, > = Selected, I = via IBGP, A = Announced
origin: i = IGP, e = EGP, ? = Incomplete

flags destination gateway lpref med aspath origin
* 192.168.1.0/24 193.51.184.26 100 0 2200 i

# bgpctl sh nei
BGP neighbor is 193.51.184.26, remote AS 2200
Description: RenaterV4
BGP version 4, remote router-id 193.51.184.26
BGP state = Established, up for 00:20:14
Last read 00:00:13, holdtime 90s, keepalive interval 30s
Neighbor capabilities:
Multiprotocol extensions: IPv4 unicast
Route Refresh
4-byte AS numbers

Message statistics:
Sent Received
Opens 5 1
Notifications 0 0
Updates 0 1
Keepalives 41 41
Route Refresh 0 0
Total 46 43

Update statistics:
Sent Received
Updates 0 1
Withdraws 0 0

Local host: 193.51.184.25, Local port: 42098
Remote host: 193.51.184.26, Remote port: 179

(same for the "renaterV6" peer)

--------------

log:
http://user.lamaiziere.net/patrick/obgpd/log-bgpd.txt

bgpd.conf
http://user.lamaiziere.net/patrick/obgpd/bgpd.conf.txt

Any help will be nice. Thanks regards.

Claudio Jeker

2010-11-08 15:07:06 UTC

Permalink

Post by Patrick Lamaiziere
(4.8/amd64)
Hello,
I'm doing some tests with OpenBGPd and sometimes (but often), when I
restart bgpd it does not send anymore the routes to the peer.
The routes are static and configured into bgpd.conf
# bgpd -d -v
wait until the routes are sent to the peer.
^D
shoot again

Hmm ^D^H does not kill bgpd, but I guess a simple ^C does it as well.

Post by Patrick Lamaiziere
# bgpctl sh rib out nei RenaterV4
flags: * = Valid, > = Selected, I = via IBGP, A = Announced
origin: i = IGP, e = EGP, ? = Incomplete
flags destination gateway lpref med aspath origin
-----

Have you checked if the networks were actaully added to the RIB?
It would help massivly to know if this is the case. I have the feeling
there could be a race condition when starting up.

I will try to reproduce.

--
:wq Claudio

Patrick Lamaiziere

2010-11-08 16:18:50 UTC

Permalink

Le Mon, 8 Nov 2010 16:07:06 +0100,

Post by Claudio Jeker
Have you checked if the networks were actaully added to the RIB?

Do you mean bgpctl show rib ? No.
Well, it takes some time but I'm able to reproduce this:

# bgpctl show rib
flags: * = Valid, > = Selected, I = via IBGP, A = Announced
origin: i = IGP, e = EGP, ? = Incomplete

flags destination gateway lpref med aspath origin
AI* 129.20.0.0/16 0.0.0.0 100 0 i
AI* 148.60.0.0/16 0.0.0.0 100 0 i
* 192.168.1.0/24 193.51.184.26 100 0 2200 i
AI* 193.52.12.0/24 0.0.0.0 100 0 i
AI* 193.52.37.0/24 0.0.0.0 100 0 i
AI* 193.52.56.0/24 0.0.0.0 100 0 i
AI* 193.52.60.0/24 0.0.0.0 100 0 i
AI* 195.220.94.0/24 0.0.0.0 100 0 i
AI* 2001:660:7307::/48 :: 100 0 i
* 2001:660:7310:10::/80 2001:660:7300:1005:0:38:0:2200 100 0
2200 i
------

And there is nothing announced in show rib out neig <PEER>

Ok for incomming routes :
# bgpctl show rib in neig RenaterV4
flags: * = Valid, > = Selected, I = via IBGP, A = Announced
origin: i = IGP, e = EGP, ? = Incomplete

flags destination gateway lpref med aspath origin
* 192.168.1.0/24 193.51.184.26 100 0 2200 i

The peer (running OpenBGPd but on FreeBSD) does not receive any route

I keep the BGP session up if you need more informations.

Thanks, regards.

Claudio Jeker

2010-11-08 17:24:48 UTC

Permalink

Post by Patrick Lamaiziere
Le Mon, 8 Nov 2010 16:07:06 +0100,

Post by Claudio Jeker
Have you checked if the networks were actaully added to the RIB?

Do you mean bgpctl show rib ? No.
# bgpctl show rib
flags: * = Valid, > = Selected, I = via IBGP, A = Announced
origin: i = IGP, e = EGP, ? = Incomplete
flags destination gateway lpref med aspath origin
AI* 129.20.0.0/16 0.0.0.0 100 0 i
AI* 148.60.0.0/16 0.0.0.0 100 0 i
* 192.168.1.0/24 193.51.184.26 100 0 2200 i
AI* 193.52.12.0/24 0.0.0.0 100 0 i
AI* 193.52.37.0/24 0.0.0.0 100 0 i
AI* 193.52.56.0/24 0.0.0.0 100 0 i
AI* 193.52.60.0/24 0.0.0.0 100 0 i
AI* 195.220.94.0/24 0.0.0.0 100 0 i
AI* 2001:660:7307::/48 :: 100 0 i
* 2001:660:7310:10::/80 2001:660:7300:1005:0:38:0:2200 100 0
2200 i
------
And there is nothing announced in show rib out neig <PEER>
# bgpctl show rib in neig RenaterV4
flags: * = Valid, > = Selected, I = via IBGP, A = Announced
origin: i = IGP, e = EGP, ? = Incomplete
flags destination gateway lpref med aspath origin
* 192.168.1.0/24 193.51.184.26 100 0 2200 i
The peer (running OpenBGPd but on FreeBSD) does not receive any route
I keep the BGP session up if you need more informations.

Can you run a "bgpctl show rib detail 129.20.0.0/16" and a "bgpctl show
table". For some reason none of the above routes got selected and so
nothing is redistributed. It looks like the decision process is turned
off. So it is not what I first thought the problem is.

--
:wq Claudio

Claudio Jeker

2010-11-08 19:03:11 UTC

Permalink

Post by Claudio Jeker

Post by Patrick Lamaiziere
Le Mon, 8 Nov 2010 16:07:06 +0100,

Post by Claudio Jeker
Have you checked if the networks were actaully added to the RIB?

Doh! I should read the log more carefully, the hint is there:

new ktable rdomain_0 for rtableid 0
listening on 0.0.0.0
change to/from route-collector mode ignored
RDE reconfigured

In other words the daemon came up in route-collector mode and so no pathes
are validated. Figured it out at the airport by just looking at the code
and swearing.

Diff is untested but I guess everyone agrees that a bit more memory
inizialisation could help.
--
:wq Claudio

Index: rde.c
===================================================================
RCS file: /cvs/src/usr.sbin/bgpd/rde.c,v
retrieving revision 1.299
diff -u -p -r1.299 rde.c
--- rde.c 15 Oct 2010 07:43:02 -0000 1.299
+++ rde.c 8 Nov 2010 18:43:16 -0000
@@ -227,7 +227,7 @@ rde_main(int pipe_m2r[2], int pipe_s2r[2
if (rdomains_l == NULL)
fatal(NULL);
SIMPLEQ_INIT(rdomains_l);
- if ((conf = malloc(sizeof(struct bgpd_config))) == NULL)
+ if ((conf = calloc(1, sizeof(struct bgpd_config))) == NULL)
fatal(NULL);
log_info("route decision engine ready");

Index: session.c
===================================================================
RCS file: /cvs/src/usr.sbin/bgpd/session.c,v
retrieving revision 1.312
diff -u -p -r1.312 session.c
--- session.c 15 Oct 2010 07:45:32 -0000 1.312
+++ session.c 8 Nov 2010 18:25:09 -0000
@@ -247,7 +247,7 @@ session_main(int pipe_m2s[2], int pipe_s
peer_cnt = 0;
ctl_cnt = 0;

- if ((conf = malloc(sizeof(struct bgpd_config))) == NULL)
+ if ((conf = calloc(1, sizeof(struct bgpd_config))) == NULL)
fatal(NULL);
if ((conf->listen_addrs = calloc(1, sizeof(struct listen_addrs))) ==
NULL)

Patrick Lamaiziere

2010-11-09 10:01:21 UTC

Permalink

Le Mon, 8 Nov 2010 20:03:11 +0100,

Post by Claudio Jeker

Post by Claudio Jeker
Can you run a "bgpctl show rib detail 129.20.0.0/16" and a "bgpctl
show table". For some reason none of the above routes got selected
and so nothing is redistributed. It looks like the decision process
is turned off. So it is not what I first thought the problem is.

Just in case:
# bgpctl show rib detail 129.20.0.0/16

BGP routing table entry for 129.20.0.0/16
Nexthop 0.0.0.0 (via 0.0.0.0) from LOCAL (193.51.184.25)
Origin IGP, metric 0, localpref 100, internal, valid, announced
Last update: 15:37:39 ago

Post by Claudio Jeker
new ktable rdomain_0 for rtableid 0
listening on 0.0.0.0
change to/from route-collector mode ignored
RDE reconfigured
In other words the daemon came up in route-collector mode and so no
pathes are validated. Figured it out at the airport by just looking
at the code and swearing.
Diff is untested but I guess everyone agrees that a bit more memory
inizialisation could help.

It looks better, I'm not able to reproduce the problem with this patch
(applied on 4.8 src).

Thanks a lot!
Regards.