May 2026 - Bird-users - Mailing Lists

BMP: no monitoring messages when enabled after BGP sessions (BIRD 3.2.1)
by Thomas Holterbach 01 Oct '26

01 Oct '26

Dear BIRD community, I am running a BMP collector and encountering an issue where no monitoring messages are exported over BMP, even though I am using the latest BIRD version (3.2.1), which should include the fix for the previous route export bug: https://gitlab.nic.cz/labs/bird/-/commit/2500b450b404ab41eeff3b2d92ba943d01… We tested this both in our lab and with a network operator, and consistently observe the following behavior: If the BMP session is activated before the BGP sessions, everything works as expected, and monitoring messages are exported. If the BGP sessions are established before enabling BMP, then BMP does not export monitoring messages at all. This suggests that BMP does not correctly pick up already-established BGP sessions. Below is a minimal configuration example. The behavior depends solely on the order in which the sessions are established : debug protocols all; router id 192.168.222.54; protocol kernel { ipv4 { export all; }; } protocol device { scan time 10; } filter ALLOW_ALL { accept; } protocol bmp { station address ip 192.168.222.1 port 4567; monitoring rib in pre_policy; tx buffer limit 1024; } protocol bgp peer_asn_10 { local 192.168.222.54 as 11; neighbor 192.168.222.52 as 10; multihop 255; ipv4 { import all; export all; next hop self; import table on; }; ipv6 { import all; export all; next hop self; import table on; }; } protocol bgp peer_asn_12 { local 192.168.222.54 as 11; neighbor 192.168.222.53 as 12; multihop 255; ipv4 { import all; export all; next hop self; }; ipv6 { import all; export all; next hop self; }; } Has anyone else experienced similar behavior? Could this be another bug related to BMP? Thanks in advance for your help. Best regards, Thomas

3 6

Example configuration for ASPA with rpki-client?
by Robert Scheck 26 Jun '26

26 Jun '26

Hello, does somebody have an example configuration snippet for ASPA in BIRD with rpki-client? I've read https://bird.network.cz/?get_doc&v=20&f=bird-6.html but I'm still not sure how the configuration in BIRD for an AS with two transit providers (just upstreams, no downstreams) would look like... Regards, Robert

6 11

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