[PATCH] Netlink on FreeBSD support
Dear bird developers, Netlink support was added to FreeBSD recently [1]. It’s not as “full-featured” as its Linux counterpart yet, however the added subset is enough to make a routing daemon work. Specifically, it supports multiple tables, multipath, nexthops and nexthops groups. No MPLS support yet. It aims to be compatible (whenever possible) to minimise the netlink users adoption efforts. The first FreeBSD releases to have netlink support will be 14.0 and 13.2. Both are planned to be released in ~Q1 2023. The attached change adds 'bsd-netlink’ sysconf target, allowing to build both netlink & rtsock versions on FreeBSD. Example output: bird> show status BIRD 2.0.10-124-g8e63db05 Router ID is 10.0.0.4 Hostname is devel2.ipfw.ru Current server time is 2022-12-01 13:40:08.960 Last reboot on 2022-12-01 13:35:39.293 Last reconfiguration on 2022-12-01 13:37:20.593 Daemon is up and running bird> show interfaces vtnet0 up (index=1) MultiAccess Broadcast Multicast AdminUp LinkUp MTU=1500 10.0.0.4/24 (Preferred, scope site) fe80::5054:ff:fe14:e319/64 (Preferred, scope link) 2a01:4f9:3a:fa00:5054:ff:fe14:e319/64 (Preferred, scope univ) lo0 up (index=2) MultiAccess Multicast AdminUp LinkUp Loopback Ignored MTU=16384 127.0.0.1/8 (Preferred, scope host) ::1/128 (Preferred, scope host) fe80::1/64 (Preferred, scope link) vtnet0.2 up (index=3) MultiAccess Broadcast Multicast AdminUp LinkUp MTU=1500 fe80::5054:ff:fe14:e319/64 (Preferred, scope link) bird> show route protocol ospf2 Table master4: 7.7.7.0/24 unicast [ospf2 13:39:41.717] * E2 (150/10/10000) [10.0.0.157] via 10.0.0.2 on vtnet0 10.0.0.0/24 unicast [ospf2 13:37:26.734] I (150/10) [10.0.0.4] dev vtnet0 bird> show route protocol static2 Table master4: 10.1.0.0/24 unicast [static2 13:46:16.543] * (200) via 10.0.0.6 on vtnet0 weight 4 via 10.0.0.5 on vtnet0 weight 3 [1] https://github.com/freebsd/freebsd-src/commit/7e5bf68495cc0a8c9793a338a8a020...
On Thu, Dec 01, 2022 at 01:48:16PM +0000, Alexander V. Chernikov via Bird-users wrote:
Dear bird developers,
Netlink support was added to FreeBSD recently [1]. It’s not as “full-featured” as its Linux counterpart yet, however the added subset is enough to make a routing daemon work. Specifically, it supports multiple tables, multipath, nexthops and nexthops groups. No MPLS support yet. It aims to be compatible (whenever possible) to minimise the netlink users adoption efforts. The first FreeBSD releases to have netlink support will be 14.0 and 13.2. Both are planned to be released in ~Q1 2023.
The attached change adds 'bsd-netlink’ sysconf target, allowing to build both netlink & rtsock versions on FreeBSD.
Hi That looks interesting. It does not interefere with working code for Linux or BSD, so we can merge it immediately without much issues. Are there any significant differenences between Netlink model and BSD kernel? Like Linux keep (and Netlink API assumes) multiple routes with different metric, and keeps source protocol. -- 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."
On 2 Dec 2022, at 03:19, Ondrej Zajicek via Bird-users <bird-users@trubka.network.cz> wrote:
On Thu, Dec 01, 2022 at 01:48:16PM +0000, Alexander V. Chernikov via Bird-users wrote:
Dear bird developers,
Netlink support was added to FreeBSD recently [1]. It’s not as “full-featured” as its Linux counterpart yet, however the added subset is enough to make a routing daemon work. Specifically, it supports multiple tables, multipath, nexthops and nexthops groups. No MPLS support yet. It aims to be compatible (whenever possible) to minimise the netlink users adoption efforts. The first FreeBSD releases to have netlink support will be 14.0 and 13.2. Both are planned to be released in ~Q1 2023.
The attached change adds 'bsd-netlink’ sysconf target, allowing to build both netlink & rtsock versions on FreeBSD.
Hi
That looks interesting. It does not interefere with working code for Linux or BSD, so we can merge it immediately without much issues. Are there any significant differenences between Netlink model and BSD kernel? It depends on what’s deemed significant. Core concepts maps nicely. There are some implementation nuances, of course. The biggest I can name is the routing table IDs mismatch. In FreeBSD, the default routing table is #0 and there are no special 25X tables. Some attributes (like RTA_PREFSRC) are not supported. Interface address flags are not fully mapped yet & there might be some unsupported stuff w.r.t IPv6 prefixes lifetime. “Prohibit” nexthops are not supported yet (as the kernel only provides blackhole / reject ATM). Resilient nexthop groups are not supported yet as well.
I may be missing something, but I’m pretty sure that the implementation is close to supporting all of the current bird features (except mpls).
Like Linux keep (and Netlink API assumes) multiple routes with different metric, and keeps source protocol. Yes, metrics & source protocol works.
Also, speaking of features - FreeBSD netlink implementation is optimised for batching & there is significant performance difference between batched-and non-batched. Specifically, current bird code does ~80k routes/sec w/o netlink batching, ~180k routes/sec w/ rtsock and ~240k routes/sec w/ netlink batching (sz=16) on the same system. Would you be open to adopting a not-too-invasive netlink batching patch enabled conditionally under CONFIG_NETLINK_BATCHING ?
-- 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."
On Fri, Dec 02, 2022 at 09:21:17PM +0000, Alexander V. Chernikov wrote:
On 2 Dec 2022, at 03:19, Ondrej Zajicek via Bird-users <bird-users@trubka.network.cz> wrote:
On Thu, Dec 01, 2022 at 01:48:16PM +0000, Alexander V. Chernikov via Bird-users wrote:
Dear bird developers,
Netlink support was added to FreeBSD recently [1]. It’s not as “full-featured” as its Linux counterpart yet, however the added subset is enough to make a routing daemon work. Specifically, it supports multiple tables, multipath, nexthops and nexthops groups. No MPLS support yet. It aims to be compatible (whenever possible) to minimise the netlink users adoption efforts. The first FreeBSD releases to have netlink support will be 14.0 and 13.2. Both are planned to be released in ~Q1 2023.
The attached change adds 'bsd-netlink’ sysconf target, allowing to build both netlink & rtsock versions on FreeBSD.
Hi Merged: https://gitlab.nic.cz/labs/bird/-/commit/a80cd4707464cedb526eb72e7704b097af2...
In FreeBSD, the default routing table is #0 and there are no special 25X tables. Some attributes (like RTA_PREFSRC) are not supported. Interface address flags are not fully mapped yet & there might be some unsupported stuff w.r.t IPv6 prefixes lifetime. “Prohibit” nexthops are not supported yet (as the kernel only provides blackhole / reject ATM). Resilient nexthop groups are not supported yet as well.
I may be missing something, but I’m pretty sure that the implementation is close to supporting all of the current bird features (except mpls).
Like Linux keep (and Netlink API assumes) multiple routes with different metric, and keeps source protocol. Yes, metrics & source protocol works.
Does source protocol also works with the native API (krt socket)?
Also, speaking of features - FreeBSD netlink implementation is optimised for batching & there is significant performance difference between batched-and non-batched. Specifically, current bird code does ~80k routes/sec w/o netlink batching, ~180k routes/sec w/ rtsock and ~240k routes/sec w/ netlink batching (sz=16) on the same system. Would you be open to adopting a not-too-invasive netlink batching patch enabled conditionally under CONFIG_NETLINK_BATCHING ?
That seems like a good idea. -- 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."
On 9 Dec 2022, at 16:48, Ondrej Zajicek <santiago@crfreenet.org> wrote:
On Fri, Dec 02, 2022 at 09:21:17PM +0000, Alexander V. Chernikov wrote:
On 2 Dec 2022, at 03:19, Ondrej Zajicek via Bird-users <bird-users@trubka.network.cz> wrote:
On Thu, Dec 01, 2022 at 01:48:16PM +0000, Alexander V. Chernikov via Bird-users wrote:
Dear bird developers,
Netlink support was added to FreeBSD recently [1]. It’s not as “full-featured” as its Linux counterpart yet, however the added subset is enough to make a routing daemon work. Specifically, it supports multiple tables, multipath, nexthops and nexthops groups. No MPLS support yet. It aims to be compatible (whenever possible) to minimise the netlink users adoption efforts. The first FreeBSD releases to have netlink support will be 14.0 and 13.2. Both are planned to be released in ~Q1 2023.
The attached change adds 'bsd-netlink’ sysconf target, allowing to build both netlink & rtsock versions on FreeBSD.
Hi
Merged: https://gitlab.nic.cz/labs/bird/-/commit/a80cd4707464cedb526eb72e7704b097af2... Thank you!
In FreeBSD, the default routing table is #0 and there are no special 25X tables. Some attributes (like RTA_PREFSRC) are not supported. Interface address flags are not fully mapped yet & there might be some unsupported stuff w.r.t IPv6 prefixes lifetime. “Prohibit” nexthops are not supported yet (as the kernel only provides blackhole / reject ATM). Resilient nexthop groups are not supported yet as well.
I may be missing something, but I’m pretty sure that the implementation is close to supporting all of the current bird features (except mpls).
Like Linux keep (and Netlink API assumes) multiple routes with different metric, and keeps source protocol. Yes, metrics & source protocol works.
Does source protocol also works with the native API (krt socket)? No. The data is in the kernel but there are no properties in the protocol to propagate it. There are some spare fields in the rt_metrics structure that can be used for that purpose, but I’d prefer not to extend rtsock anymore. Additionally, there is no such feature in OpenBSD / NetBSD.
Also, speaking of features - FreeBSD netlink implementation is optimised for batching & there is significant performance difference between batched-and non-batched. Specifically, current bird code does ~80k routes/sec w/o netlink batching, ~180k routes/sec w/ rtsock and ~240k routes/sec w/ netlink batching (sz=16) on the same system. Would you be open to adopting a not-too-invasive netlink batching patch enabled conditionally under CONFIG_NETLINK_BATCHING ?
That seems like a good idea. Ack. Will send a patch them (probably, somewhere next week).
-- Elen sila lumenn' omentielvo
Ondrej 'Santiago' Zajicek (email: santiago@crfreenet.org <mailto:santiago@crfreenet.org>) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net <http://wwwkeys.pgp.net/>) "To err is human -- to blame it on a computer is even more so."
On Sat, Dec 10, 2022 at 04:54:52PM +0000, Alexander Chernikov wrote:
In FreeBSD, the default routing table is #0 and there are no special 25X tables. Some attributes (like RTA_PREFSRC) are not supported. Interface address flags are not fully mapped yet & there might be some unsupported stuff w.r.t IPv6 prefixes lifetime. “Prohibit” nexthops are not supported yet (as the kernel only provides blackhole / reject ATM). Resilient nexthop groups are not supported yet as well.
I may be missing something, but I’m pretty sure that the implementation is close to supporting all of the current bird features (except mpls).
Like Linux keep (and Netlink API assumes) multiple routes with different metric, and keeps source protocol. Yes, metrics & source protocol works.
Does source protocol also works with the native API (krt socket)?
No. The data is in the kernel but there are no properties in the protocol to propagate it. There are some spare fields in the rt_metrics structure that can be used for that purpose, but I’d prefer not to extend rtsock anymore.
Additionally, there is no such feature in OpenBSD / NetBSD.
What about multiple routes with different metrics / priorities? Is that supported on FreeBSD through rtsock API? That one seems to work in OpenBSD. BTW, do you have some suggestions how to improve BIRD rtsock BSD interface in BIRD? Especially one sore point that is collisions with kernel provided direct routes. In recent FreeBSD, these routes seems to be non-overwritable / non-overridable, which is safe, but causes plenty of error messages in logs. In recent OpenBSD, our routes are added with a different priority (RTP_*), which is done by default, but we sometimes overwrite/remove the kernel provided direct routes (probably because we do not use explicit priority in add/remove operations, and remove operation defaults to removing the kernel one, but that looks like something that could be easily fixed). I have no idea how this works in NetBSD. -- 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."
On 12 Dec 2022, at 15:17, Ondrej Zajicek via Bird-users <bird-users@trubka.network.cz> wrote:
On Sat, Dec 10, 2022 at 04:54:52PM +0000, Alexander Chernikov wrote:
In FreeBSD, the default routing table is #0 and there are no special 25X tables. Some attributes (like RTA_PREFSRC) are not supported. Interface address flags are not fully mapped yet & there might be some unsupported stuff w.r.t IPv6 prefixes lifetime. “Prohibit” nexthops are not supported yet (as the kernel only provides blackhole / reject ATM). Resilient nexthop groups are not supported yet as well.
I may be missing something, but I’m pretty sure that the implementation is close to supporting all of the current bird features (except mpls).
Like Linux keep (and Netlink API assumes) multiple routes with different metric, and keeps source protocol. Yes, metrics & source protocol works.
Does source protocol also works with the native API (krt socket)?
No. The data is in the kernel but there are no properties in the protocol to propagate it. There are some spare fields in the rt_metrics structure that can be used for that purpose, but I’d prefer not to extend rtsock anymore.
Additionally, there is no such feature in OpenBSD / NetBSD.
What about multiple routes with different metrics / priorities? Is that supported on FreeBSD through rtsock API? That one seems to work in OpenBSD. It is, but there is no way get all of the paths from a single message - one has to implement buffering similar to netlink IPv6 code bird [used to] have IIRC.
BTW, do you have some suggestions how to improve BIRD rtsock BSD interface in BIRD? Especially one sore point that is collisions with kernel provided direct routes. In recent FreeBSD, these routes seems to be non-overwritable / non-overridable, which is safe, but causes plenty of error messages in logs. It may be a big one :-) In the current [Free]BSD networking model, there is no specific treatment of interface routes - they reside in the same routing table and that route table is the master source of truth w.r.t routing decisions. Bird model is slightly different - krt ignores all directly-connected routes and re-generates them IFF the appropriate direct protocol is configured. Not all installations configure the direct protocol. Additionally, there are other corner cases like multiple interfaces with the same network prefix or just the static interface routes where direct protocol may behave differently from the routing table. Personally, I tend to think that addressing this “impedance mismatch” would help with the specified and related problems - for the rtsock world. What do you think?
Speaking of the immutability - it happened for a reason. For example, there is a situation when you have an active-passive router configuration, sharing the state via OSPF/bgp and you need to migrate certain network/interface from one router to another. As minimal downtime is desired, it can happen that bird override the newly-added interface route with the remote route. When withdraw message propagates, bird will remove this route, leaving the interface w/o the directly connected route. There is still a way to remove such routes by specifying RTF_PINNED flag in the delete message if so desired.
In recent OpenBSD, our routes are added with a different priority (RTP_*), which is done by default, but we sometimes overwrite/remove the kernel
I’d love to introduce variation of route priorities in the kernel, so the interface routes and backup routes are treated differently. The problem is that it would be a disrupting rtsock change, requiring changes of all existing customers. Problems like this and stuff like multipath inefficiencies turned me to netlink. I’m now focused on improving general netlink kernel support and making bird working with netlink flawlessly. I’d love be able to eventually switch bird to netlink as the default protocol on new FreeBSD versions provided that it works correctly and there is no objection from you & other persons on the team.
provided direct routes (probably because we do not use explicit priority in add/remove operations, and remove operation defaults to removing the kernel one, but that looks like something that could be easily fixed).
I have no idea how this works in NetBSD.
-- 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."
On Wed, Dec 14, 2022 at 01:17:05PM +0000, Alexander Chernikov wrote:
On 12 Dec 2022, at 15:17, Ondrej Zajicek via Bird-users <bird-users@trubka.network.cz> wrote:
BTW, do you have some suggestions how to improve BIRD rtsock BSD interface in BIRD? Especially one sore point that is collisions with kernel provided direct routes. In recent FreeBSD, these routes seems to be non-overwritable / non-overridable, which is safe, but causes plenty of error messages in logs.
It may be a big one :-)
In the current [Free]BSD networking model, there is no specific treatment of interface routes - they reside in the same routing table and that route table is the master source of truth w.r.t routing decisions.
Bird model is slightly different - krt ignores all directly-connected routes and re-generates them IFF the appropriate direct protocol is configured. Not all installations configure the direct protocol. Additionally, there are other corner cases like multiple interfaces with the same network prefix or just the static interface routes where direct protocol may behave differently from the routing table.
Personally, I tend to think that addressing this “impedance mismatch” would help with the specified and related problems - for the rtsock world.
What do you think?
Definitely. In ideal world, BIRD routing tables should be complete and equal to kernel tables, perhaps by BIRD having the full responsibility for managing the tables (i.e. being the single source of truth about routing). In practice, there are several complications: 1) In all supported systems, kernel crates its own direct routes anyways. 2) Sometimes, direct routes require some magic OS-specific handing, that would be hard to get right (like RTF_CLONING in OpenBSD). 3) We should keep OS usable even after BIRD is stopped, so we should remove BIRD-specific routes but keep direct routes, even if they were temporarily overriden. 4) There are also third-party alien routes that we should take into account. So in practice, we just trying to not destroy kernel-provided direct routes in kernel table, but we would like to be able to safely override them (e.g. if OSPF decides that some indirect path should be more preferred than the direct one). But we still keep the idea that BIRD is the single/master source of truth about routing, so we just close eyes about the fact that direct routes in the kernel routing table are provided by kernel and not by us. That is why krt ignores kernel-provided routes (as it is supposed to provide only third-party alien routes) and why direct routes are instead generated by the direct protocol. It also ensures that we have consistent internal behavior between systems, and not import say cloned host routes on systems that use them. (I would ignore the fact that some installations do not configure the direct protocol, that is just a result of limited usefulness of direct routes inside BIRD, due to some hacks related to next hop resolution, so in some cases they are not useful, or they are provided by OSPF anyways. But conceptually, i think there should be direct routes in BIRD tables and we should resolve next hops through them.) One thing that reasonably works is Linux-style routing table with priorities, esp. when kernel-provided routes have lower priority (like in IPv6 case, where default kernel priority is 256, but it can be set as kernel option for IPv4 case). In such case we can just export our routes as higher priority ones, but still keep kernel ones.
Speaking of the immutability - it happened for a reason. For example, there is a situation when you have an active-passive router configuration, sharing the state via OSPF/bgp and you need to migrate certain network/interface from one router to another. As minimal downtime is desired, it can happen that bird override the newly-added interface route with the remote route. When withdraw message propagates, bird will remove this route, leaving the interface w/o the directly connected route. There is still a way to remove such routes by specifying RTF_PINNED flag in the delete message if so desired.
One backwards-compatible solution would be to consider RTF_PINNED as 'shadow priority level', one could just overwrite the route without using RTF_PINNED, but the kernel route is just shadowed and reappear when the overwriting route is removed. While add/remove/replace with RTF_PINNED specified would modify directly the kernel route. -- 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."
   A bit more patches (some bundled in net/bird already [1]). * 0001-FreeBSD-fix-netlink-build.patch adds missed bsd-netlink Makefile, that actually builds the target * 0002-FreeBSD-use-interface-index-instead-of-IP-address-wh.patch switches multicast interface specification from ip address to interface index. That allows to avoid iface->sysdep value, which is not filled by netlink. * 0003-netlink-move-OS-specific-headers-and-defines-to-sysd.patch introduces netlink OS-specific header to put all defines/includes/inlines [1]: https://cgit.freebsd.org/ports/commit/?id=af97566029883a46fc4d58cf5e066f25cd...
On 2 Dec 2022, at 03:19, Ondrej Zajicek via Bird-users <bird-users@trubka.network.cz> wrote:
On Thu, Dec 01, 2022 at 01:48:16PM +0000, Alexander V. Chernikov via Bird-users wrote:
Dear bird developers,
Netlink support was added to FreeBSD recently [1]. It’s not as “full-featured” as its Linux counterpart yet, however the added subset is enough to make a routing daemon work. Specifically, it supports multiple tables, multipath, nexthops and nexthops groups. No MPLS support yet. It aims to be compatible (whenever possible) to minimise the netlink users adoption efforts. The first FreeBSD releases to have netlink support will be 14.0 and 13.2. Both are planned to be released in ~Q1 2023.
The attached change adds 'bsd-netlink’ sysconf target, allowing to build both netlink & rtsock versions on FreeBSD.
Hi
That looks interesting. It does not interefere with working code for Linux or BSD, so we can merge it immediately without much issues. Are there any significant differenences between Netlink model and BSD kernel? Like Linux keep (and Netlink API assumes) multiple routes with different metric, and keeps source protocol.
-- 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."
   A bit more patches (some bundled in net/bird already [1]). * 0001-FreeBSD-fix-netlink-build.patch adds missed bsd-netlink Makefile, that actually builds the target * 0002-FreeBSD-use-interface-index-instead-of-IP-address-wh.patch switches multicast interface specification from ip address to interface index. That allows to avoid iface->sysdep value, which is not filled by netlink. * 0003-netlink-move-OS-specific-headers-and-defines-to-sysd.patch introduces netlink OS-specific header to put all defines/includes/inlines [1]: https://cgit.freebsd.org/ports/commit/?id=af97566029883a46fc4d58cf5e066f25cd...
On 2 Dec 2022, at 03:19, Ondrej Zajicek via Bird-users <bird-users@trubka.network.cz> wrote:
On Thu, Dec 01, 2022 at 01:48:16PM +0000, Alexander V. Chernikov via Bird-users wrote:
Dear bird developers,
Netlink support was added to FreeBSD recently [1]. It’s not as “full-featured” as its Linux counterpart yet, however the added subset is enough to make a routing daemon work. Specifically, it supports multiple tables, multipath, nexthops and nexthops groups. No MPLS support yet. It aims to be compatible (whenever possible) to minimise the netlink users adoption efforts. The first FreeBSD releases to have netlink support will be 14.0 and 13.2. Both are planned to be released in ~Q1 2023.
The attached change adds 'bsd-netlink’ sysconf target, allowing to build both netlink & rtsock versions on FreeBSD.
Hi
That looks interesting. It does not interefere with working code for Linux or BSD, so we can merge it immediately without much issues. Are there any significant differenences between Netlink model and BSD kernel? Like Linux keep (and Netlink API assumes) multiple routes with different metric, and keeps source protocol.
-- 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."
On Thu, Dec 15, 2022 at 08:22:02PM +0000, Alexander Chernikov wrote:
A bit more patches (some bundled in net/bird already [1]). * 0001-FreeBSD-fix-netlink-build.patch adds missed bsd-netlink Makefile, that actually builds the target
Hmm, seems like i forgot to add the Makefile from your previous patch, but it didn't work properly anyways. I do not like to redefine make rules like in this Makefile, seems to me that the simplest solution is to put symlinks referencing linux/netlink* to sysdep/bsd-netlink dir. See https://gitlab.nic.cz/labs/bird/-/commit/7b6c9649775b288653b0d61df6004d79f0d...
* 0002-FreeBSD-use-interface-index-instead-of-IP-address-wh.patch switches multicast interface specification from ip address to interface index. That allows to avoid iface->sysdep value, which is not filled by netlink.
Nice. Is this supported since long ago, or does it require some recent BSD version? Do you know whether it is supported also in other BSD flavors? I just modified it to use feature-specific #define. See https://gitlab.nic.cz/labs/bird/-/commit/6825f94570b05f933f09ae1bd7e520954d9...
* 0003-netlink-move-OS-specific-headers-and-defines-to-sysd.patch introduces netlink OS-specific header to put all defines/includes/inlines
OK, moved netlink-sys.h to sysdep/bsd-netlink, that makes more sense to me. If we later merge bsd-netlink to bsd under one target, we can move it back. Also removed netlink-nosup.h, it is not included anyways. See https://gitlab.nic.cz/labs/bird/-/commit/176fc68aed32a5675aa643e3b7c6f65ff9a... Hopefully these changes are okay for you. BTW, are BSD Netlink constants (e.g. RTA_*) the same as Linux ones? Or it is just compatible on C macro/enum name level? -- 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."
On 16 Dec 2022, at 18:59, Ondrej Zajicek via Bird-users <bird-users@trubka.network.cz> wrote:
On Thu, Dec 15, 2022 at 08:22:02PM +0000, Alexander Chernikov wrote:
A bit more patches (some bundled in net/bird already [1]). * 0001-FreeBSD-fix-netlink-build.patch adds missed bsd-netlink Makefile, that actually builds the target
Hmm, seems like i forgot to add the Makefile from your previous patch, but it didn't work properly anyways.
I do not like to redefine make rules like in this Makefile, seems to me I didn’t like it either, symlink indeed looks cleaner. that the simplest solution is to put symlinks referencing linux/netlink* to sysdep/bsd-netlink dir.
See https://gitlab.nic.cz/labs/bird/-/commit/7b6c9649775b288653b0d61df6004d79f0d... Works for me!
* 0002-FreeBSD-use-interface-index-instead-of-IP-address-wh.patch switches multicast interface specification from ip address to interface index. That allows to avoid iface->sysdep value, which is not filled by netlink.
Nice. Is this supported since long ago, or does it require some recent BSD version? Do you know whether it is supported also in other BSD flavors? It’s a bit complicated :-)
FreeBSD: IP_MULTICAST_IF - ip_mreqn support was added in [1] @ 2007. IP_<ADD|DEL>_MEMBERSHIP - ip_mreqn support was added in [2] @ 2019 / FreeBSD 12.1. All currently supported FreeBSD versions have this functionality in place OpenBSD: IP_MULTICAST_IF - ip_mreqn support was added in [3] @ 2021 IP_<ADD|DEL>_MEMBERSHIP - ip_mreqn support was added in [4] @ 2021 NetBSD: IP_MULTICAST_IF, IP_<ADD|DEL>_MEMBERSHIP uses old API hack, treating 0/8 IPv4 addresses as ifindex. It was added in [5] @ 2001
I just modified it to use feature-specific #define.
Yep, it looks better, thank you!
See https://gitlab.nic.cz/labs/bird/-/commit/6825f94570b05f933f09ae1bd7e520954d9...
* 0003-netlink-move-OS-specific-headers-and-defines-to-sysd.patch introduces netlink OS-specific header to put all defines/includes/inlines
OK, moved netlink-sys.h to sysdep/bsd-netlink, that makes more sense to me. If we later merge bsd-netlink to bsd under one target, we can move it back.
Also removed netlink-nosup.h, it is not included anyways.
See https://gitlab.nic.cz/labs/bird/-/commit/176fc68aed32a5675aa643e3b7c6f65ff9a...
Looks good.
Hopefully these changes are okay for you.
Of course!
BTW, are BSD Netlink constants (e.g. RTA_*) the same as Linux ones? Or it is just compatible on C macro/enum name level?
They are the same and the intent is to keep having them the same.
-- 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.”
[1] [Import rewrite of IPv4 socket multicast layer to support source-specific · freebsd/freebsd-src@71498f3 · GitHub] https://github.com/freebsd/freebsd-src/commit/71498f308b2324dbd94e94fd8c4ae4... [2] [Support struct ip_mreqn as argument for IP_ADD_MEMBERSHIP. Legacy sup… · freebsd/freebsd-src@0dfc145 · GitHub] https://github.com/freebsd/freebsd-src/commit/0dfc145abe244443bb38ee81617462... [3] [Extend IP_MULTICAST_IF to take either an address (struct in_addr), a · openbsd/src@7f4b9fd · GitHub] https://github.com/openbsd/src/commit/7f4b9fd65d60b886b9f4ba05f8da3bd613db05... [4] [Extend IP_ADD_MEMBERSHIP to also support struct ip_mreqn. · openbsd/src@c0ba2d2 · GitHub] https://github.com/openbsd/src/commit/c0ba2d2f58a32a98b4fcfb612bda013f1d51bd... [5] [allow IP_MULTICAST_IF and IP_ADD/DROP_MEMBERSHIP to specify interface · NetBSD/src@42bede7 · GitHub] https://github.com/NetBSD/src/commit/42bede79daa3e7cf4f0902d2bf96e1f548b6a01...
On Sat, Dec 17, 2022 at 01:27:23PM +0000, Alexander Chernikov wrote:
* 0002-FreeBSD-use-interface-index-instead-of-IP-address-wh.patch switches multicast interface specification from ip address to interface index. That allows to avoid iface->sysdep value, which is not filled by netlink.
Nice. Is this supported since long ago, or does it require some recent BSD version? Do you know whether it is supported also in other BSD flavors?
It’s a bit complicated :-)
FreeBSD: IP_MULTICAST_IF - ip_mreqn support was added in [1] @ 2007. IP_<ADD|DEL>_MEMBERSHIP - ip_mreqn support was added in [2] @ 2019 / FreeBSD 12.1. All currently supported FreeBSD versions have this functionality in place
OpenBSD: IP_MULTICAST_IF - ip_mreqn support was added in [3] @ 2021 IP_<ADD|DEL>_MEMBERSHIP - ip_mreqn support was added in [4] @ 2021
NetBSD: IP_MULTICAST_IF, IP_<ADD|DEL>_MEMBERSHIP uses old API hack, treating 0/8 IPv4 addresses as ifindex. It was added in [5] @ 2001
Thanks for the overview! So we can assume that the ip_mreqn API is available since FreeBSD 12.1 and OpenBSD 6.9 and enable CONFIG_USE_IP_MREQN based on __FreeBSD_version and OpenBSD version macros? I generally prefer to keep old system compatibility code for ~ 5 years, although it makes more sense on Linux, where are some LTS distributions with similar long-term commitments, than on BSD. -- 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."
On 17 Dec 2022, at 16:06, Ondrej Zajicek <santiago@crfreenet.org> wrote:
On Sat, Dec 17, 2022 at 01:27:23PM +0000, Alexander Chernikov wrote:
* 0002-FreeBSD-use-interface-index-instead-of-IP-address-wh.patch switches multicast interface specification from ip address to interface index. That allows to avoid iface->sysdep value, which is not filled by netlink.
Nice. Is this supported since long ago, or does it require some recent BSD version? Do you know whether it is supported also in other BSD flavors?
It’s a bit complicated :-)
FreeBSD: IP_MULTICAST_IF - ip_mreqn support was added in [1] @ 2007. IP_<ADD|DEL>_MEMBERSHIP - ip_mreqn support was added in [2] @ 2019 / FreeBSD 12.1. All currently supported FreeBSD versions have this functionality in place
OpenBSD: IP_MULTICAST_IF - ip_mreqn support was added in [3] @ 2021 IP_<ADD|DEL>_MEMBERSHIP - ip_mreqn support was added in [4] @ 2021
NetBSD: IP_MULTICAST_IF, IP_<ADD|DEL>_MEMBERSHIP uses old API hack, treating 0/8 IPv4 addresses as ifindex. It was added in [5] @ 2001
Thanks for the overview!
So we can assume that the ip_mreqn API is available since FreeBSD 12.1 and OpenBSD 6.9 and enable CONFIG_USE_IP_MREQN based on __FreeBSD_version It’s certainly correct for FreeBSD (_FreeBSD_version >= 1201000) and OpenBSD version macros? Probably.
I generally prefer to keep old system compatibility code for ~ 5 years, although it makes more sense on Linux, where are some LTS distributions with similar long-term commitments, than on BSD.
Yep, that makes great sense.
-- 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."
participants (4)
-
Alexander Chernikov -
Alexander Chernikov
-
Alexander V. Chernikov -
Ondrej Zajicek