October 2026 - Bird-users

BIRD 3.3.3, 3.2.4, 3.1.9, 2.19.3, 2.18.4, 2.17.7 released
by Maria Matejka 05 Oct '26

05 Oct '26

Dear BIRD users, we're releasing patch versions for all the supported branches. Downloads are possible at <https://bird.nic.cz/get-bird/> and in our upstream repositories. Apart from a bit of hardening, nothing is really security-relevant here. We have fixed a bunch of bugs. There are still more bugs to fix. The selection of what is fixed has no particular rule. Mostly, somebody in the team just picked up *something* and fixed it. We are fixing: - several bugs in BMP in BIRD 3 - interface handling with EVPN/Bridge and a BIRD 3 crash in MPLS reconfiguration - a bunch of corner cases in OSPF, RPKI, RAdv, and the common core If your bug report has been reported as fixed, we would love if you confirmed that from your side. If not, it will most probably get fixed in the next patch release. Officially supported versions are now: - 3.3.x and 2.19.x 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 services, so that you can get help with configuration, priority access to critical bug information and fixes, and better influence the overall development directions. It's the users paying for these services, who keep the development running, so thank you to all who is already doing so! 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

[PATCH 0/2] A few small improvements to RAdv
by LEdoian 01 Oct '26

01 Oct '26

Hello, I'm sending a few small patches that really mostly scratch my itch. First one is just a small clarification in docs of behaviour I found surprising, second makes the built-in defaults for prefix option parameters (L and A bits, lifetimes) configurable in radv protocol instance. This is my first patch, so I'm open for comments (but if this looks alright, feel free to use as is :-) ). I didn't yet figure out what would be the best approach to test this in the test suite (BIRD is not a great RA client), so I would appreciate some guidance/hints on that. Also, I'm not entirely sure whether this feels “BIRDy” enough (I have some thoughts on that, but for now I'll skip the extensive deliberation here). I've been running this code for about a week now on my router (my networks don't use SLAAC, which was my itch), it feels stable, but I have no hard data on that. Apart from the patches heere, I have uploaded the code to <https://gitea.ledoian.cz/LEdoian/bird> (the web interface to the commits won't work, feel free to clone that). LEdoian (2): Docs: Add note about when RAdv keeps prefix RAdv: Make default prefix options configurable doc/bird.sgml | 15 ++++++++++++++- proto/radv/config.Y | 20 +++++++++++++++----- proto/radv/radv.c | 14 ++++++-------- proto/radv/radv.h | 1 + 4 files changed, 36 insertions(+), 14 deletions(-) -- 2.55.0

1 2

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