On Wed, May 22, 2013 at 08:31:15PM +0100, Joe Holden wrote:
> 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.
While this is true the main problem is that on OpenBSD bgpd gets more
help from the kernel. But the "directly connected" is not an error it is
just the indication that the nexthop can be reached directly (over the
tunnel) instead of using a gateway (or a link local route).
> >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.
At least on OpenBSD that is not true. Every interface has a link state and
in some cases it will be unknown. IIRC tun(4) is considered DOWN when the
device node was not opened. Is it possible that bgpd missed the UP event?
ifconfig(8) should show the link state:
# ifconfig tun1
tun1: flags=11<UP,POINTOPOINT> mtu 1500
priority: 0
groups: tun
status: down
> >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.
I think this should work on OpenBSD maybe talk to the OpenBGPD port
maintainer.
--
:wq Claudio
