Hi all,
I've been doing some testing with OpenBGPD to possibly replace quagga/
zebra on some of our host based routers. One problem I have found
is that when it is connecting to a peer over a tun device (we use
openvpn), the bgp daemon gets the proper nexthop information but when
it is added to the routing table, it installs the local address as
the nexthop to the routes it received. I can't decide if this is an
undocumented function or a bug, but I can replicate it over both
FreeBSD (our main platform) and OpenBSD and using all versions of
openbgpd I could find. For example, I have a machine at 10.8.1.248
connecting to 10.8.1.2:
tun0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1500
inet 10.8.1.248 --> 10.8.1.2 netmask 0xffffffff
Opened by PID 49178
The connection is working fine and quagga<->quagga connections work
normally (10.8.1.2 is a FreeBSD 6.1 machine) with a translated but
identical functionality configuration.
10.8.1.2 has all the interesting routes I want to see from
10.8.1.248, but the daemon is installing 10.8.1.248 as the nexthop to
those routes, for example:
gw0# bgpctl sho ip bgp | grep 10.3.116.33/32
10.3.116.33/32 10.8.1.2 100 0 64820 65502
64830 64910 i
gw0# netstat -nrf inet | grep 10.3.116.33/32
10.3.116.33/32 10.8.1.248 UG1 0 0 fxp0.1
It's baffling me as bgpd is reporting the nexthop as 10.8.1.2, but is
actually installing 10.8.1.248, which makes no sense to me. This is
a pretty cut and dry ebgp session, nothing fancy going on.
bgpd.conf:
AS 65530
router-id 10.8.1.248
log updates
fib-update yes
network 10.12.0.0/16
neighbor 10.8.1.2 {
remote-as 64820
descr 'at-br1.sv'
}
From the other side of the connection, the 10.12/16 network is
advertised normally and that route is propagated. I also tried
(without luck) to set the nexthop to 10.8.1.2 to force it to use the
correct IP, but only get repeated messages of:
nexthop 10.8.1.2 now valid: via 10.8.1.248
nexthop 10.8.1.2 now invalid
I looked through the openbgpd source but it quickly went over my
head. Any ideas?
-casey
