On Sat, Oct 05, 2013 at 01:05:11PM -0500, Thomas Johnson wrote:

I am having some difficulty getting my OSPF configuration to play nicely with OpenVPN tunnels on FreeBSD. I have a number of point-to-point tunnels between sites, with a BIRD instance running on each tunnel endpoint. Endpoint addresses for a tunnel use a logical /31. Initially, the BIRD instances would talk to each other, but the endpoint addresses were not advertised by OSPF, making them unreachable.

Yes, for several reasons, ptp addresses of non-stub ifaces are not advertised by OSPF and have to be explicitly configured by stubnet option.

I remedied this by adding stubnet declarations (/32) for each of the tunnel endpoints.

You added as stubnet local /32, remote /32 or both? Personally, i would add just local /32.

This has the effect of making all of my endpoint addresses reachable, but causes another issue. In this configuration, if I restart one of my OpenVPN tunnels, it fails to set addressing on the tunnel, because the host route already exists in the routing table (due to the stubnet).

Because OSPF does not generate routes for local networks (including local stubnets), i guess that the problem was caused by /32 stubnets propagated through OSPF, which would generate some indirect /32 route that is exported to kernel and would collide with the direct route. This problem is not really specific to stubnet option, it could happen even if these addresses would be advertised automatically, but it would be a race condition between OSPF convergence and OpenVPN reestablishment. It is a general problem of collisions between kernel device routes and BIRD routes. On Linux, using separate kernel table (or perhaps a different krt_metric) for BIRD routes should ultimately help. I am not sure if there is such simple way to avoid it on BSD. Perhaps the problem could be avoided if you configure both local and remote /32s as stubnets. In that case local stubnets always win, so no indirect route is found. Or setup a stubnet for whole /31. Another solution would be to have an import filter which explicitly rejects any /32 route that should be directly reachable by OpenVPN: filter ospf_in { if net ~ [ 1.2.3.4/31+, 1.2.3.10/31+ ] then reject; else accept; } protocol ospf { import filter ospf_in; ... } But both suggestions are not optimal and have some problem. I would have another suggestion - do not propagate these as independent /32s. Either consider them as a kind of 'link-local' IP, or use IPs for them from some wider pool (either some local ethernet stub network or some designated pool of ptp endpoint IPs for given router), which is propagated as a whole. -- Elen sila lumenn' omentielvo Ondrej 'SanTiago' Zajicek (email: santiago@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."