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: [email protected]) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."
