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

Ondrej Zajicek santiago at crfreenet.org
Mon Dec 27 21:27:57 CET 2021


On Wed, Dec 15, 2021 at 10:01:57PM +0100, Stefan Haller wrote:
> Hi,
> 
> I am replying to this older email thread, because the context might be
> appreciated. Hope that this is acceptable.
> 
> Thread in archive: <https://bird.network.cz/pipermail/bird-users/2021-April/015419.html>
> 
> Short summary: On FreeBSD bird will export onlink routes, but the kernel
> does not support an onlink flag. So when bird is reading back the routes
> from the kernel table there is some confusion, the route is dismissed
> and bird tries to re-export the route again and again.
> ...
> For some time now I am using a local patch (on top of bird 2.0.8) that
> essentially implements the suggestion that was emerging from the
> discussion:
> 
> On Mon, Apr 19, 2021 at 09:41:33PM +0200, Ondrej Zajicek wrote:
> > 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).
> 
> My proposed patch is attached to end of the mail. What it does is that
> for any route received by the kernel it checks if the iface only has /32
> or /128 addresses configured. If this is the case, the RNF_ONLINK flag
> will be set for this route. If any other address is found, the behaviour
> is not changed. The neigh_find call was adapted in a way to mimic the
> call in sysdep/linux/netlink.c.

Hi

Thanks for the patch. I merged it with some modifications [*]. Mainly
replacing check for address length with check for host address flag (so
it does not apply on ifaces with regular ptp addresses, which are /32 but
not host-only due to peer range), also your patch just skipped whole
neigh_find() in case of host-only iface instead of just assuming the
onlink flag.

[*] https://gitlab.nic.cz/labs/bird/-/commit/a39cd2cc0b0c64235457c07e2b618318bbdfcacd

It would be great if you could test it for you case, but i tested it
on BSD with some simple setups and it seems to work correctly.

> Another way would be store an 'assume_onlink_routes' flag per interface
> on interface discovery.  Would probably touch more places in the code
> base. One could also move the iface-addr check after the neigh_find
> check, so it will only fire in rare corner cases before bailing out.

Thought about that, but there are pleny of list walking in the
krt_read_route() (e.g. in if_find_by_index()), so likey it does
not matter.

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


More information about the Bird-users mailing list