January 2026 - Bird-users

bird 3.1.5 crashes after adding "-R" to BIRD_ARGS
by Christoph 16 Mar '26

16 Mar '26

Hello, last night we made two changes to our BIRD config: * enabled ASPA validation (logging only) * added "-R" to BIRD_ARGS (/etc/bird/envvars) after that we run "configure" on birdcl. After that bird started to crash in a loop. We decided to rollback the ASPA configuration change to restore a working setup. This did not help. Then we decided to remove "-R" from BIRD_ARGS and that helped. For this reason we did not include the ASPA config changes in this email since they appear to be not relevant for the crashes. We assume "-R" causes the crashes. Is this a known bug that is solved in 3.2.0? We would like to have graceful restart support but we are a bit hesitant with "-R" now ;-) Logs: 2026-01-05 01:15:31.820 [0001] <INFO> Reconfiguring 2026-01-05 01:15:31.822 [0001] <INFO> Cannot add channel r3k.aspa 2026-01-05 01:15:31.822 [0001] <INFO> Restarting protocol r3k 2026-01-05 01:15:38.339 [0001] <INFO> Reloading channel anexia_v4.ipv4 2026-01-05 01:15:38.339 [0001] <INFO> Reloading channel anexia_v6.ipv6 2026-01-05 01:15:38.366 [0001] <INFO> Reloading channel nextlayer_v4.ipv4 2026-01-05 01:15:38.367 [0001] <INFO> Reloading channel nextlayer_v6.ipv6 2026-01-05 01:15:38.367 [0001] <INFO> Reconfigured 2026-01-05 01:15:42.397 [0002] <BUG> Assertion 'r->cur' failed at lib/lockfree.c:229 Jan 05 01:15:42 bird.service: Main process exited, code=killed, status=6/ABRT Jan 05 01:15:42 bird.service: Failed with result 'signal'. Jan 05 01:15:42 bird.service: Consumed 1d 39min 31.457s CPU time, 1.6G memory peak. Jan 05 01:15:42 bird.service: Scheduled restart job, restart counter is at 2. lots of crashes: journalctl ..|grep 'bird.service: Main process exited,' Jan 05 01:15:42 bird.service: Main process exited, code=killed, status=6/ABRT Jan 05 01:17:16 bird.service: Main process exited, code=killed, status=6/ABRT Jan 05 01:18:45 bird.service: Main process exited, code=killed, status=6/ABRT Jan 05 01:20:13 bird.service: Main process exited, code=killed, status=6/ABRT Jan 05 01:21:28 bird.service: Main process exited, code=killed, status=6/ABRT Jan 05 01:21:41 bird.service: Main process exited, code=killed, status=11/SEGV Jan 05 01:22:42 bird.service: Main process exited, code=killed, status=6/ABRT Jan 05 01:22:56 bird.service: Main process exited, code=killed, status=11/SEGV Jan 05 01:24:22 bird.service: Main process exited, code=killed, status=6/ABRT Jan 05 01:24:36 bird.service: Main process exited, code=killed, status=11/SEGV Jan 05 01:25:30 bird.service: Main process exited, code=killed, status=6/ABRT Jan 05 01:27:02 bird.service: Main process exited, code=killed, status=6/ABRT Jan 05 01:27:16 bird.service: Main process exited, code=killed, status=11/SEGV Jan 05 01:28:10 bird.service: Main process exited, code=killed, status=6/ABRT Jan 05 01:29:37 bird.service: Main process exited, code=killed, status=6/ABRT Jan 05 01:29:51 bird.service: Main process exited, code=killed, status=11/SEGV Jan 05 01:30:52 bird.service: Main process exited, code=killed, status=6/ABRT Jan 05 01:30:59 bird.service: Main process exited, code=killed, status=11/SEGV Jan 05 01:32:10 bird.service: Main process exited, code=killed, status=6/ABRT Jan 05 01:32:20 bird.service: Main process exited, code=killed, status=11/SEGV Jan 05 01:36:04 bird.service: Main process exited, code=killed, status=6/ABRT Jan 05 01:36:18 bird.service: Main process exited, code=killed, status=11/SEGV Jan 05 01:36:33 bird.service: Main process exited, code=killed, status=11/SEGV Jan 05 01:36:47 bird.service: Main process exited, code=killed, status=11/SEGV Jan 05 01:37:02 bird.service: Main process exited, code=killed, status=11/SEGV Jan 05 01:37:16 bird.service: Main process exited, code=killed, status=11/SEGV Jan 05 01:38:36 bird.service: Main process exited, code=killed, status=6/ABRT Jan 05 01:38:51 bird.service: Main process exited, code=killed, status=11/SEGV Jan 05 01:39:05 bird.service: Main process exited, code=killed, status=11/SEGV Jan 05 01:39:20 bird.service: Main process exited, code=killed, status=11/SEGV Jan 05 01:39:34 bird.service: Main process exited, code=killed, status=11/SEGV Jan 05 01:39:49 bird.service: Main process exited, code=killed, status=11/SEGV Jan 05 01:41:26 bird.service: Main process exited, code=killed, status=11/SEGV Jan 05 01:41:40 bird.service: Main process exited, code=killed, status=11/SEGV Jan 05 01:41:55 bird.service: Main process exited, code=killed, status=11/SEGV Jan 05 01:42:10 bird.service: Main process exited, code=killed, status=11/SEGV Bird version (dpkg -l bird): ii bird3 3.1.5-cznic.1~trixie amd64 Internet Routing Daemon best regards, Christoph

2 4

[PATCH 0/4] BGP unnumbered automatic peering based on IPv6 ND
by Matteo Perin 02 Mar '26

02 Mar '26

Dear BIRD dev-team and community, This is a patch proposal spawned from the discussion in a previous mailing list thread [0], regarding how to achieve automatic BGP peering establishment using the IPv6 Neighbor Discovery mechanism. Over the last few weeks, I worked on implementing the feature with the outline Maria Matejka kindly provided. As expected, it proved to be quite challenging, especially when it came to integrate the peer discovery approach with the current dynamic BGP implementation. To briefly summarize the implemented automatic peering mechanism and added capabilites: - The ability for the RAdv protocol to receive and read incoming ICMPv6 RAs was added. - Route-like objects, containing RAs data are created, based on advertisments detections. These are stored in a new kind of routing table. - Lifetime of the objects in the table is determined by the ICMPv6 RA Router Lifetime field. RA expiration will remove the object from the table. - The discovery process is enabled only if a new neighbor discovery option is enabled in the RAdv protocol configuration. - A new channel was added to the BGP protocol called peers. - When present in the BGP configuration, an export to this BGP channel (allowed only in dynamic BGP) will trigger the spawn of a new session. - Withdrawal the object from the peers routing table will trigger the corresponding BGP session shutdown. - An automatic BGP session can be made permanent via configuration with a persist option in the peers channel. To test the main functionality of this feature it I used multiple VMs linked by a bridge with BIRD setup on all of them. BGP session establishment is successful between all routers even with a very minimal configuration. I will provide an example, so you can also see the new configuration parameters in action: protocol device { } peer table nd_peers; protocol radv radv1 { peer { table nd_peers; }; interface "enp5s0" { max ra interval 60; min ra interval 20; # Enable neighbor discovery on this interface # When enabled, BIRD will parse incoming RAs and store router info neighbor discovery yes; }; } protocol bgp bgp1 { dynamic name "bgp_peer"; dynamic name digits 3; local as 65000; neighbor range fe80::/12 external; # Link-local range for BGP unnumbered # Peers channel for importing peer discoveries and spawning sessions peers { # Interface for BGP session establishment from "enp5s0"; # Persist sessions on route withdrawal persist yes; table nd_peers; import all; export all; }; ipv4 { import all; export all; }; ipv6 { import all; export all; }; } Of course, I have some concerns about some design choices and code optimization, I tried to find the best solution that did not involve major refactorings or moving code around and some comments on how to improve rough edges from people more experienced on the current codebase would be really appreciated. Mostly, the two main points I am not entirely happy about are: - How I handled the RAs staleness mechanism based on router lifetime. I looked for it but there does not seem to be a per-route staleness mechanism already in place, so I resorted to adding a check for expired entries when the RAdv protocol timer is triggerd, which is not ideal. - The mechanism to avoid spawning multiple sessions when both dynamic BGP and this new feature are both configured. For now, I try looking for BGP session with the same remote peer address and give precedence to the ones spawned by the dynamic BGP mechanism, but I am quite sure it is possible to find a better solution for this. I tried to make the commit messages both informative and concise, but please ask if something is unclear or missing. I am still working on adding documentation and automated testing, but since I think the discussion about the implemetation is more useful with actual code in hand, I decided to send the main bulk of the patch right now and amend this later along with changes addressing incoming reviews. I hope you will appreciate the work done. Best Regards, Matteo [0] https://bird.network.cz/pipermail/bird-users/2025-November/018482.html Matteo Perin (4): Nest: Add net_peer route type to track discovered peers RAdv: Add neighbor discovery based on incoming RAs to RAdv proto BGP: Move postponed socket reloop logic from start to start_locked to achieve locking requirements BGP: Add peers channel and sessions spawn on export to achieve automatic peering lib/net.c | 16 ++++ lib/net.h | 31 ++++++- nest/config.Y | 3 +- nest/proto.c | 2 +- proto/bgp/attrs.c | 57 +++++++++++++ proto/bgp/bgp.c | 187 +++++++++++++++++++++++++++++++++++++++---- proto/bgp/bgp.h | 28 ++++++- proto/bgp/config.Y | 15 +++- proto/bgp/packets.c | 11 +++ proto/radv/config.Y | 3 +- proto/radv/packets.c | 41 +++++++++- proto/radv/radv.c | 163 ++++++++++++++++++++++++++++++++++++- proto/radv/radv.h | 4 + 13 files changed, 533 insertions(+), 28 deletions(-) -- 2.43.0

2 15

BMP Adj-RIB-Out post-policy support
by admin＠nxthdr.dev 26 Feb '26

26 Feb '26

Hello, Currently, the (preliminary) BMP protocol implementation in BIRD does not support ADJ-RIB-Out monitoring. Only ADJ-RIB-In pre- and post-policy are supported at the moment. I have implemented support for ADJ-RIB-Out post-policy monitoring, which is relatively straightforward to add. The proposed implementation is available here: https://github.com/CZ-NIC/bird/compare/master...matthieugouel:bird:bmp-adj-… I have not implemented ADJ-RIB-Out pre-policy yet, as this would require more intrusive changes related to export tables. I would be interested to know whether this is something you would consider merging. More generally, is there interest in extending BMP support in BIRD with additional features? I know that BMP is still marked as preliminary and not production-ready, but it is a protocol I personally rely on quite heavily. Best,Matthieu.

4 4

How to work with ASPA efficiently?
by Ondřej Caletka 05 Feb '26

05 Feb '26

Hello! I am trying to troubleshoot some ASPA validation failures in BIRD 3.2.0. I wonder whether there is a way how to see a ASPA table entry for particular customer AS number. Something like: bird> show route table aspas all for 2121 syntax error, unexpected NUM, expecting IP4 or IP6 or VPN_RD or CF_SYM_KNOWN I also wonder whether it is possible to filter the data based on the contents of the aspa_provider sets like: bird> show route table aspas all where 3333 ~ aspa_providers Table aspas: Regarding the validation itself, a random trivial example where aspa_check_downstream fails and I don't know why is this: 80.254.230.0/24 bgp_path: 3333 12859 42695 (My ASN is 2121 and there is an ASPA stating that 3333 is provider for 2121) There is no ASPA for 3333 There is ASPA for 12859 not stating 42695 as provider There is ASPA for 42695 not stating 12859 as provider So the up ramp should be 42695 and the down ramp should be 2121 3333 12859 I don't see any valleys here yet it is rejected. Am I doing it wrong? -- Best regards, Ondřej Caletka

2 2

iBGP config.
by Mike Neo 29 Jan '26

29 Jan '26

Hi, I have one operator with a full BGP table (one BGP session) and one IX (two BGP sessions, one BGP session each, to two different ISP routers). I need to configure two BGP routers based on Ubuntu + Bird 2/3 with iBGP. Could someone share this configuration and point out what to watch out for when traffic is ~1-2 Gbps? Thanks in advance.

4 5

BIRD at FOSDEM 2026
by Maria Matejka 18 Jan '26

18 Jan '26

Dear BIRD Users, in two weeks, there is FOSDEM 2026, and you are all welcome to meet us at our stand there, chat with us, ask your technical questions or fetch some branded items. Our stand is shared with Turris, and we expect to be in the building K, somewhere nearby WireShark and OpenTofu. Please check the official maps when they are released. If you're thinking about throwing some money on the project in exchange for some support services or feature development, our stand is a perfect place to consult that. You may also message me privately in advance to get a time slot reserved. Looking forward to meeting you all! Maria et al. -- Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.

1 0

Not receiving OSPF Hello even though tcpdump shows it's received
by Lukas Haase 15 Jan '26

15 Jan '26

2 2

draft-ietf-idr-linklocal-capability
by Donatas Abraitis 15 Jan '26

15 Jan '26

Hello! Is this the right place to ask for implementing [1]draft-ietf-idr-linklocal-capability capability? [1] - https://datatracker.ietf.org/doc/html/draft-ietf-idr-linklocal-capability? -- Donatas

2 2

BIRD 3.2.0 and 2.18 released
by Maria Matejka 15 Jan '26

15 Jan '26

Dear BIRD users, we are releasing BIRD versions 3.2.0 and 2.18. We have implemented BGP dynamic onlink/unnumbered and link-local connection scenarios and fixed various behavior bugs in reconfiguration. Also, AS Sets in AS Paths are now considered malformed by default. For BIRD 3.2.0, we have split back the `igp_metric` attribute so that now you may find also `local_metric` where applicable. There was a confusion in BIRD 3.0 and 3.1 arising from two distinct attributes in BIRD 2 named the same in the code, and me not understanding what Santiago was telling me about that. More on that in updated 3.2 documentation. We have done various minor updates, e.g. flags in RAdv (both versions), fixed a RIP non-determinism (v3) and additional CLI configuration bugs. There have been some more core reworks, removing some more performance chokepoints. Both versions also include all relevant fixes applied for 3.1.5 and 2.17.3. Considering unfinished work, we also have several Babel patches pending which we failed again to review in time to merge into 2.18. We'll do them as soon as possible. Also, in BIRD 3.x, the "show route for" displays all covering routes instead of just the longest prefix match. We're working on a fix but it's quite a can of worms. Officially supported versions are now: - 3.2.0 and 2.18 until 6 months after 3.3.0 and 2.19 get released - LTS 3.1.x and 2.17.x, expected to track Debian Trixie The DEB packages in pkg.labs.nic.cz are already there, and RPMs will come soon. Please note that the upstream DEBs weren't built directly from the tagged commit but from the `release-v2.18` and `release-v3.2` branch because of our current CI limitations. We'll fix that for later versions. Happy new year! Maria and the BIRD Team -- Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.

5 8

Safeguarding BGP advertisments
by Lukasz Jarosz 13 Jan '26

13 Jan '26

Hello, I am currently working on handling edge cases of BGP advertisements malfunctions in my network. I am writing to this mailing list to confirm that I haven’t missed BIRD native solution. Issue in question is when BGP router loses its connectivity to rest of the internal mesh and still advertise routes to upstreams (I use manual aggregates, because my internal routes have very long prefixes and address space is non continuous). AFAIK (these were my ideas how to implement safeguards): - I can’t use BFD to guard advertisement of static blackhole route, - I can’t use BFD to guard pipe protocol. As I understand my only solutions are to use external monitoring tooling to disable advertisements to upstreams or restructure BGP configuration in a way that externally advertised prefixes come to BIRD routers through channel that is dependent on connection to internal mesh. Have I missed something? Best regards, Lukasz Jarosz

3 3