Christopher J. Umina wrote:
Hello,
I'm hoping Claudio or someone can take a quick look at this:
I'm testing a simple hub/spoke VPN configuration using vtun (tun
interfaces) for 'last mile' between sites. Over the tunnels, I would
like to run EBGP sessions using OpenBGPd (on FreeBSD 9.1) on both
ends, but I'm running into some trouble. I'm trying to do this as an
extremely cheap solution to use in a very small scale, so bgpd will be
listening on the tunnel interface local address rather than a loopback
address. This is true at both ends of the configuration.
The tunnel interfaces are configured as such and work properly with
the hub router IP 10.1.254.1 and the spoke router IP 10.1.254.2 able
to ping each other and all that.
The BGP configuration is fairly standard, I can include it if needed
later, but I think it's probably irrelevant. The hub router is running
AS 64598 and the spoke running AS 64593 and each are listening on
their tunnel IPs, the sessions come up and everything is fine on the
spoke router.
After the session comes up, the hub router logs:
May 22 18:13:06 ar01 bgpd[792]: nexthop 10.1.254.2 now invalid:
directly connected
FreeBSD != OpenBSD, there are huge differences in the way the routing
table works, including the lack of priorities and interface route
protection.
The routes show up in the RIB, but never make it to the FIB, I assume
because of the previous message. To add to the confusion the following
output is from the hub router:
# bgpctl show nexthop
Flags: * = nexthop valid
Nexthop Route Prio Gateway Iface
10.1.254.1
10.1.254.2 10.1.254.2/32 48 connected tun100 (DOWN, active)
Is that "DOWN" indicating the link state of the tunnel interface? The
tunnel interface is up and operating.
tun has no link state, use tap.
Is this intended behavior? It appears bgpd is invalidating all routes
due to a 'directly connected' nexthop. If so, would it make sense to
have an option to allow directly connected nexthops?
This isn't an appropriate place to ask really, post to freebsd-net.
Thank you,
--
Christopher J. Umina
ch...@uminac.com
