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/a39cd2cc0b0c64235457c07e2b618318bbd... 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@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."