Possibility to treat /32 and /128 non-gateway routes as onlink on BSD?

[Stefan Haller]

Hi,

first of all thanks for your reply. It became clear that there were some
misunderstandings on my side.

On Mon, Apr 19, 2021 at 09:41:33PM +0200, Ondrej Zajicek wrote:
> On Sun, Apr 18, 2021 at 08:55:12PM +0200, Stefan Haller wrote:
> > In a recent change in the FreeBSD Wireguard kernel module the
> > POINTTOPOINT interface flag is dropped for wg interfaces[1]. This
> > behaviour will probably not change, because Wireguard is not
> > peer-to-peer or a broadcast domain, but peer-to-multipoint. Hence my
> > previous configuration of setting peer addresses on the interface is not
> > working anymore:
> > 
> >   ifconfig wg0 inet 192.168.0.10/32 192.168.0.4
> 
> Hi
> 
> Just to be sure, Wireguard is really PtMP (some peers on the iface may
> not be able to communicate between themselves directly) and not NBMA?
> In that case this network setup makes sense.

That is true, yes. For example, one could build something like this
here:

   A ----- B
   |     / |
   |   /   |
   | /     |
   C ----- D

A and D can not communicate directly. This happens in my case, for
example, because A and D sit at different dormitory home connections and
can not talk to each other directly (easily).

> > Note that this actually models the real world better, because Wireguard
> > is not point-to-point but point-to-multipoint. So multiple peers can be
> > done in the following way:
> > 
> >   ifconfig wg0 192.168.0.10/32
> >   route add 192.168.0.4 -iface wg0
> >   route add 192.168.0.8 -iface wg0
> > 
> > However, this does not work with bird 2.0.8: bird will not recognize the
> > p2p peer addresses as gateways and it will log on kernel table rescan:
> 
> Yes, the main issue is that (sans onlink flag) BIRD validates next-hops
> against interface ranges and not against direct (non-gateway) routes. In
> most cases it does not matter but with PtMP it would require manually
> configuring multiple PtP address pairs for an iface.

I see. I think I cleared up my confusion. So on Linux, if I have wg0 with
192.168.0.10/32 configured and I issue:

  ip route add 192.168.0.4 dev wg0

The equivalent of calling `neigh_find(..., "192.168.0.4", "wg0", ...)`
will _not_ find the neighbor. I misread the netlink code and thought the
goal of it was to enable this neighbor to be found. Thanks for your
explanation. That's why I wanted to replicate it on BSD.

> [...]
> 
> The proper solution (on Linux) is that the second route (for
> 192.168.42.0/24) also has onlink flag, so it does not depend on
> existence of route for 192.168.0.4/32. Babel in BIRD generates
> routes with onlink flag.

This configuration is working now with Babel + BIRD 2.0.8 on Linux (I
was still on 2.0.7 when testing it on Linux previously). Looks like that
it would not work with e.g. OSPF.

What I still don't get exactly is the following mismatch:

(i) If the route is read from the kernel, BIRD checks if the next-hop is
reachable by any interface network (= stricter check than kernel).

(ii) However, if BIRD sends the route to the kernel it will not check if
the gateway is reachable. If BIRD thinks the gateway is unreachable and
the route still gets installed (because it in fact is), BIRD will never
be able to correctly read the route back in.

Shouldn't there be a check in (ii) too?

> [...]
> 
> I see the problem as BIRD internally support onlink flag, but BSD kernel
> does not support that flag, so onlink routes exported to BSD kernel are
> not read back properly. Seems to me that there is a simple woraround:
> 
> When i read a route (from kernel on BSD) that has gateway on iface, which
> has only /32 or /128 IP address(es), so no proper iface range, then i would
> assume onlink flag for the route (its nexthops).

I will continue working in this direction.


Kind regards,
Stefan