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

[Ondrej Zajicek]

On Fri, Apr 23, 2021 at 05:06:11PM +0200, Stefan Haller wrote:
> Hi,
> 
> first of all thanks for your reply. It became clear that there were some
> misunderstandings on my side.

Hi

Glad to help you.


> > 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.

Yes.


> > [...]
> > 
> > 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?

Routes (and their gateways) are checked when imported from protocols
to (BIRD) tables. Routes in tables are assumed to be valid.

BIRD (like Linux kernel) uses optional 'onlink' flag on gateways. This
is used recently by Babel. Gateway with this flag is considered valid
regardless of network range. When route is sent to kernel on Linux, this
flag is translated to Linux 'onlink' flag, so it is ok when it is read
back. But on BSD such kernel flag does not exist, so it is just forgotten
when sent to kernel, and check failed when the route is read back.

-- 
Elen sila lumenn' omentielvo

Ondrej 'Santiago' Zajicek (email: santiago at 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."