May 2026 - Bird-users - Mailing Lists

misleading documentation for the "direct" protocol
by Lexi Winter 02 Jun '26

02 Jun '26

hello, the BIRD documentation says for the "direct" protocol[0]: > The question is whether it is a good idea to have such device routes > in BIRD routing table. OS kernel usually handles device routes for > directly connected networks by itself so we don't need (and don't > want) to export these routes to the kernel protocol. OSPF protocol > creates device routes for its interfaces itself and BGP protocol is > usually used for exporting aggregate routes. But the Direct protocol > is necessary for distance-vector protocols like RIP or Babel to > announce local networks. [0] https://bird.network.cz/?get_doc&v=30&f=bird-6.html#ss6.7 as i read this, it is suggesting that if BIRD is only running OSPF, then the "direct" protocol is not needed. however, i've tested this and i'm not sure it's true. without direct, and with a basic OSPF configuration with no peers, BIRD will flag the OSPF interface routes with '!': root@witch:/usr/local/etc # birdc show route BIRD 3.2.0 ready. Table master4: 81.2.96.160/28 unicast [core4 22:45:00.630] ! I (150/10) [198.18.2.4] dev genet0 Table master6: 2001:8b0:aab5:c401::/64 unicast [core6 22:45:00.630] ! I (150/10) [198.18.2.4] dev genet0 it will also log very much some netlink errors: May 31 22:51:04 witch bird[31390]: Netlink: File exists May 31 22:51:04 witch syslogd: last message repeated 1 times May 31 22:52:04 witch bird[31390]: Netlink: Address already in use May 31 22:52:04 witch bird[31390]: Netlink: File exists May 31 22:52:04 witch syslogd: last message repeated 1 times after configuring BIRD with: protocol direct { ipv4; ipv6; }; the OSPF interface routes are correctly installed (or rather, not installed, since the kernel already installed them): root@witch:/usr/local/etc # birdc show route BIRD 3.2.0 ready. Table master4: 81.2.96.160/28 unicast [direct1 22:53:29.436] * (240) dev genet0 unicast [core4 22:53:29.529] I (150/10) [198.18.2.4] dev genet0 Table master6: 2001:8b0:aab5:c401::/64 unicast [direct1 22:53:29.436] * (240) dev genet0 unicast [core6 22:53:29.529] I (150/10) [198.18.2.4] dev genet0 and BIRD does not log anymore the netlink-related errors. i tested this on FreeBSD 15.0, so possibly this is a FreeBSD-specific behaviour that isn't present on Linux; i don't have any Linux systems to test with. but, i think the documentation of the "direct" protocol could be changed to indicate that configuring it may be necessary in at least some situations.

2 2

Setting bgp_next_hop in EVPN resets VNI
by André Grüneberg 28 May '26

28 May '26

Hi all, Yesterday I was partying that I was able to inject static MAC-IP routes into EVPN on Bird 3.3.0 with the correct VNI using the mpls_label attribute. The joy was disturbed today, when I tried to set a different bgp_next_hop than the local host. As soon as I set the bgp_next_hop this forces the VNI/mpls_label to be encoded as 0. While the local export table shows the configured mpls_label, the remote side receives VNI=0. >From reading the code, I suspect that https://gitlab.nic.cz/labs/bird/-/blob/v3.3.0/proto/bgp/packets.c#L1321 is triggering this behaviour. I have no real clue how to get values into nhloc->labels (statically). I found a workaround in explicitly setting next hop address in the BGP protocol's evpn channel. Yet my expectation would be that explicitly setting bgp_next_hop does not have any influence on treating the VNI/mpls_label. Abbreviated config: evpn table t_evpn; protocol static { evpn { table t_evpn; }; route evpn mac 172.25.110.202:100 0 c0:12:34:56:78:9a 2001:db8::1 drop; } filter export_evpn { if ( net.evpn_type = NET_EVPN_MAC ) then { bgp_ext_community.add((generic, 0x30c0000, 0x8)); bgp_ext_community.add((rt, 10, my_vlan)); bgp_ext_community.add((generic, 0x6000000, 0x0)); mpls_label = 100100; bgp_next_hop = 10.49.0.0; } accept; } protocol bgp core01 { local as my_asn; evpn { table t_evpn; import none; export filter export_evpn; next hop address 10.49.0.0; }; neighbor 172.25.110.201 as my_asn; } With this configuration the VNI in outbound UPDATE is set to 0. Without bgp_next_hop in the filter the BGP UPDATE contains VNI 100100. Best wishes, André -- André Grüneberg, Managing Director andre.grueneberg(a)bcix.de +49 30 2332195 42 BCIX Management GmbH Albrechtstr. 110 12103 Berlin Germany Geschäftsführer/Managing Directors: Jens Lietzmann, André Grüneberg Handelsregister: Amtsgericht Charlottenburg, HRB 143581 B

2 2

EVPN static IMET route on Bird 3.3.0
by André Grüneberg 28 May '26

28 May '26

Hi bird users, I am currently experimenting with Bird 3.3.0 and EVPN. I do not need/want a local termination, but want to inject static EVPN routes only. Despite missing documentation (hint!), I found the necessary syntax to define mac-ip and imet routes. I also managed to manually set the required ext communities (tunnel type, MAC mobility, RT) as well as the VNI (mpls_label) in the filter. What remains open is the bgp_pmsi_tunnel attribute. According to the documentation it's not available in filters. Is there any alternative way to statically set it? Maybe a custom attribute and a binary string? Thanks, André -- André Grüneberg, Managing Director andre.grueneberg(a)bcix.de +49 30 2332195 42 BCIX Management GmbH Albrechtstr. 110 12103 Berlin Germany Geschäftsführer/Managing Directors: Jens Lietzmann, André Grüneberg Handelsregister: Amtsgericht Charlottenburg, HRB 143581 B

3 5

[PATCH v2 0/4] Modernize Netlink code
by Asbjørn Sloth Tønnesen 27 May '26

27 May '26

These patches tweaks the netlink code, bringing it closer to best practice. Signed-off-by: Asbjørn Sloth Tønnesen <ast(a)2e8.dk> --- v2: - Rework patch 4 to handle conflict with commit e3ee1a97f2c6 ("Bridge: Linux bridge interface - preliminary support") v1: https://trubka.network.cz/pipermail/bird-users/2026-February/018618.html Asbjørn Sloth Tønnesen (4): Netlink: Enable strict checking on nl_req Netlink: Skip request payload in acknowledgements Netlink: Enable and decode extended acknowledgements Netlink: Skip stats in device dumps sysdep/linux/netlink.c | 101 ++++++++++++++++++++++++++++++++--------- 1 file changed, 79 insertions(+), 22 deletions(-) base-commit: 1d7f3e564e257d4fd345129b26af4dd9a1dd8bb1 -- 2.53.0

3 3

BIRD 3.3.0 and 2.19.0 released
by Maria Matejka 25 May '26

25 May '26

Dear BIRD users, we are releasing BIRD versions 3.3.0 and 2.19.0. Both versions include all relevant fixes applied in versions 3.2.1, 3.1.6, 2.18.1 and 2.17.4. Downloads are possible at <https://bird.nic.cz/get-bird/> and in our upstream repositories. We have merged BGP autospawn based on received router advertisements. Also, we changed the disabled BGP protocol behavior in 3.3.0 to align with BIRD 2, so that disabled protocol actively blocks incoming connections for that peer. These versions contain BGP/EVPN/VXLAN support. Please check, and if you find anything weird, please tell us. We also did an EVPN tutorial at RIPE 92: <https://ripe92.ripe.net/programme/meeting-plan/sessions/59/7JB8K9/> We have reworked BGP export tables in BIRD 3, so that they eat significantly less memory. We have fixed `show route for` in BIRD 3 to do the longest prefix match again. There are also some more minor changes and fixes. There are some outstanding bugs (in all versions) reported, and we're working on fixing them. Some of these involve crashes in corner cases, and therefore, in filters, we recommend to sanity-check lengths of the data you are working with before running more complex operations. This applies mostly to community lists and bgp paths, and it's a good practice anyway to drop routes with enormously long paths or community lists. Officially supported versions are now: - 3.3.0 and 2.19.0 until 6 months after 3.4.0 and 2.20.0 get released - 3.2.x and 2.18.x until end of November 2026 - LTS 3.1.x and 2.17.x tracking Debian Trixie Also, on commercial note, we offer BIRD Support, so that you can get help with configuration, priority access to critical bug fixes, and better influence the overall development directions. It's the users paying for these services, who keep the development running. More on that at our website: <https://bird.nic.cz/commercial-services/> Happy routing! Maria and the BIRD Team -- Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.

1 0

Custom thread group for BFD causes error - <FATAL> Express thread group not configured and "express" not found
by Justin Cattle 21 May '26

21 May '26

Hi, I've been testing migrating to bird3. I preferred to redefine the default threading configs so that everything is explicit, rather than implicit. But, when I defined the ¬eress" group, I got the following warning logged: <WARN> Symbol 'express' overrides existing keyword Rather than create create needless log lines, I though I would fix that by creating my own custom thread group instead, and use that for BFD. I created: thread group responsive { threads 1; max latency 10 ms; min time 1 ms; max time 10 ms; wakeup time 60 s; } protocol bfd { thread group responsive; interface "net0" { interval 1000 ms; multiplier 4; }; interface "net1" { interval 1000 ms; multiplier 4; }; } However, the config validation then throws the following error: <FATAL> Express thread group not configured and "express" not found Is this a bug, or something I'm doing wrong ? Thanks! Cheers, Just -- Notice: This email is confidential and may contain copyright material of members of the Ocado Group. Opinions and views expressed in this message may not necessarily reflect the opinions and views of the members of the Ocado Group. If you are not the intended recipient, please notify us immediately and delete all copies of this message. Please note that it is your responsibility to scan this message for viruses. References to the "Ocado Group" are to Ocado Group plc (registered in England and Wales with number 7098618) and its subsidiary undertakings (as that expression is defined in the Companies Act 2006) from time to time. The registered office of Ocado Group plc is Buildings One & Two, Trident Place, Mosquito Way, Hatfield, Hertfordshire, AL10 9UL. Ocado Polska Sp. z o.o. posiada status dużego przedsiębiorcy w rozumieniu ustawy o przeciwdziałaniu nadmiernym opóźnieniom w transakcjach handlowych. / Ocado Polska Sp. z o.o. holds the status of a large enterprise under the Act on Counteracting Excessive Delays in Commercial Transactions.

2 5

[PATCH v2 4/4] Netlink: Skip stats in device dumps
by Asbjørn Sloth Tønnesen 18 May '26

18 May '26

Gathering interface statistics can be a relatively expensive operation on certain systems as it requires iterating over all the cpus. This patch instructs the kernel to omit device statistics, when scanning devices, as the statistics aren't used by BIRD. Kernel-side support for this was added in Linux v4.4 in commit d5566fd72ec1 ("rtnetlink: RTEXT_FILTER_SKIP_STATS support to avoid dumping inet/inet6 stats"), this saves 368 bytes of statistics. In the Linux v6.19 commit 105bae321862 ("rtnetlink: honor RTEXT_FILTER_SKIP_STATS in IFLA_STATS"), it is expanded to skip more statistics bringing the savings to 800 bytes per device. Signed-off-by: Asbjørn Sloth Tønnesen <ast(a)2e8.dk> --- sysdep/linux/netlink.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/sysdep/linux/netlink.c b/sysdep/linux/netlink.c index 02efa0f6d..5b437b0e6 100644 --- a/sysdep/linux/netlink.c +++ b/sysdep/linux/netlink.c @@ -1412,7 +1412,7 @@ kif_do_scan(struct kif_proto *p UNUSED) if_start_update(); - nl_request_dump_link(AF_UNSPEC, 0); + nl_request_dump_link(AF_UNSPEC, RTEXT_FILTER_SKIP_STATS); while (h = nl_get_scan()) if (h->nlmsg_type == RTM_NEWLINK || h->nlmsg_type == RTM_DELLINK) nl_parse_link(h, 1); @@ -2557,7 +2557,8 @@ kbr_do_vlan_scan(struct kbr_proto *p) struct nlmsghdr *h; - nl_request_dump_link(AF_BRIDGE, RTEXT_FILTER_BRVLAN); + nl_request_dump_link(AF_BRIDGE, RTEXT_FILTER_BRVLAN | + RTEXT_FILTER_SKIP_STATS); while (h = nl_get_scan()) { if (h->nlmsg_type == RTM_NEWLINK || h->nlmsg_type == RTM_DELLINK) -- 2.53.0

1 0

[PATCH v2 2/4] Netlink: Skip request payload in acknowledgements
by Asbjørn Sloth Tønnesen 18 May '26

18 May '26

Set NETLINK_CAP_ACK, as we don't need a full copy of the request payload, so it's "rather wasteful"[1] to not set NETLINK_CAP_ACK. We don't check the return value of setsockopt(), as any capped message will have NLM_F_CAPPED set in nlmsg_flags. NETLINK_CAP_ACK was introduced in Linux v4.3 commit 0a6a3a23ea6e ("netlink: add NETLINK_CAP_ACK socket option"), and so AFAICT it doesn't need to be added to netlink-sys.h. [1] https://docs.kernel.org/userspace-api/netlink/intro.html Signed-off-by: Asbjørn Sloth Tønnesen <ast(a)2e8.dk> --- sysdep/linux/netlink.c | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/sysdep/linux/netlink.c b/sysdep/linux/netlink.c index 9c519adb6..68f075fc0 100644 --- a/sysdep/linux/netlink.c +++ b/sysdep/linux/netlink.c @@ -70,6 +70,14 @@ static linpool *nl_linpool; static struct nl_sock nl_scan = {.fd = -1}; /* Netlink socket for synchronous scan */ static struct nl_sock nl_req = {.fd = -1}; /* Netlink socket for requests */ +static void +nl_set_cap_ack(struct nl_sock *nl UNUSED, int val UNUSED) +{ +#ifdef SOL_NETLINK + setsockopt(nl->fd, SOL_NETLINK, NETLINK_CAP_ACK, &val, sizeof(val)); +#endif +} + static void nl_open_sock(struct nl_sock *nl) { @@ -82,6 +90,8 @@ nl_open_sock(struct nl_sock *nl) nl->rx_buffer = xmalloc(NL_RX_SIZE); nl->last_hdr = NULL; nl->last_size = 0; + + nl_set_cap_ack(nl, 1); } } -- 2.53.0

1 0

[PATCH v2 1/4] Netlink: Enable strict checking on nl_req
by Asbjørn Sloth Tønnesen 18 May '26

18 May '26

Enable strict checking of netlink messages on the nl_req connection, so it is enabled on both connections. Also rename the function to remove "_dump" suffix, as it's a generic option. Strict checking was originally called NETLINK_DUMP_STRICT_CHK, but was renamed to NETLINK_GET_STRICT_CHK, as it should apply to all calls, not only dumps (Linux commmit d3e8869ec826). When set on nl_req, we don't need to check the return code, as it will fail on nl_scan as well, and so one log message should be enough and unlike nl_scan, we don't need to alter the mode of operation. Signed-off-by: Asbjørn Sloth Tønnesen <ast(a)2e8.dk> --- sysdep/linux/netlink.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/sysdep/linux/netlink.c b/sysdep/linux/netlink.c index 00b21fc97..9c519adb6 100644 --- a/sysdep/linux/netlink.c +++ b/sysdep/linux/netlink.c @@ -86,7 +86,7 @@ nl_open_sock(struct nl_sock *nl) } static int -nl_set_strict_dump(struct nl_sock *nl UNUSED, int strict UNUSED) +nl_set_strict_chk(struct nl_sock *nl UNUSED, int strict UNUSED) { #ifdef SOL_NETLINK return setsockopt(nl->fd, SOL_NETLINK, NETLINK_GET_STRICT_CHK, &strict, sizeof(strict)); @@ -125,7 +125,8 @@ nl_open(void) nl_open_sock(&nl_scan); nl_open_sock(&nl_req); - if (nl_set_strict_dump(&nl_scan, 1) < 0) + nl_set_strict_chk(&nl_req, 1); + if (nl_set_strict_chk(&nl_scan, 1) < 0) { log(L_WARN "KRT: Netlink strict checking failed, will scan all tables at once"); krt_use_shared_scan(); -- 2.53.0

1 0

Re: iBGP and redundancy problem.
by Jeroen Massar 18 May '26

18 May '26

> On 18 May 2026, at 09:21, Mike Neo <neomikemac(a)gmail.com> wrote: > > I think there's a problem with knowing how to access clients/internet via iBGP. When the ISP on R1 goes down, I can't even access the internet from R1 via iBGP. Perhaps there's some routing missing in this area. I would suggest providing configuration and routing table excerpts if you want anybody on the list to help you out. Regards, Jeroen > > niedz., 17 maj 2026 o 23:43 Jeroen Massar <jeroen(a)massar.ch> napisał(a): > > > > On 17 May 2026, at 20:44, Mike Neo <neomikemac(a)gmail.com> wrote: > > > > Are you BGP exchanging routes between R1 and R2? > > Yes. > > > > Does R1 pull/removes the routes from the upstream when they are down. > > Yes. > > > > Are R2 routes visible, likely less preferred, on R1? > > Yes, via iBGP. > > Then, what is the post-failover state that apparently fails? > Check routing tables on R1 and R2, both bird and the kernel routing tables. > > Also do a traceroute from a client to see where things go, or if possible log in to each and use similar to 'ip ro get <remote-ip>' to see where the next hop leads. But also be sure to do that all the way from R2. > > Does R2 how to get to R1 to get to the clients? > > > And just in case, if NAT or even normal connection tracking is involved that might cause issues primarily due to the missing state on R2 where those packets are not expected. > > Also this is all assuming that both R1 and R2 are announcing the same prefixes and that upstream keeps on sending packets. > > Regars, > Jeroen >

1 0