April 2026 - Bird-users - Mailing Lists

Several assertion failures in 3.2.0
by Matt Corallo 02 May '26

02 May '26

Figured I'd give 3.2.0 a whirl, but sadly it still seems quite assertion-failure-prone. It seems to hit quite a few assertions, sadly, so not sure if the underlying issue isn't something less than deterministic. I have core dumps that I can provide against the debian forky 3.2.0 package. I saw at least the following: (gdb) bt #0 __pthread_kill_implementation (threadid=<optimized out>, signo=signo@entry=6, no_tid=no_tid@entry=0) at ./nptl/pthread_kill.c:44 #1 0x00007fa1b85289ff in __pthread_kill_internal (threadid=<optimized out>, signo=6) at ./nptl/pthread_kill.c:89 #2 0x00007fa1b84d3cc2 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26 #3 0x00007fa1b84bc4ac in __GI_abort () at ./stdlib/abort.c:77 #4 0x0000555dddb0a1bc in bug (msg=msg@entry=0x555dddb1ace8 "Assertion '%s' failed at %s:%d") at sysdep/unix/log.c:412 #5 0x0000555ddda7ad4c in proto_announce_state_locked (ts=0x555dddb9a260 <proto_state_table_pub>, p=0x555e06438c70, new_state=0x7fa111f18208) at nest/proto.c:3069 #6 proto_announce_state (p=0x555e06438c70, attr=0x7fa111f18208) at nest/proto.c:3129 #7 0x0000555ddda58cb6 in defer_execute (_ld=<optimized out>) at lib/defer.c:22 #8 0x0000555ddda590a6 in ev_run_list_limited (l=l@entry=0x555dddb94578 <main_birdloop+216>, limit=4294967294, limit@entry=0) at lib/event.c:336 #9 0x0000555dddb007a4 in io_loop () at sysdep/unix/io.c:2648 #10 0x0000555ddda1632e in main (argc=<optimized out>, argv=<optimized out>) at sysdep/unix/main.c:1106 and this twice: (gdb) bt #0 __pthread_kill_implementation (threadid=<optimized out>, signo=signo@entry=6, no_tid=no_tid@entry=0) at ./nptl/pthread_kill.c:44 #1 0x00007facbfb6c9ff in __pthread_kill_internal (threadid=<optimized out>, signo=6) at ./nptl/pthread_kill.c:89 #2 0x00007facbfb17cc2 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26 #3 0x00007facbfb004ac in __GI_abort () at ./stdlib/abort.c:77 #4 0x0000557b139b21bc in bug (msg=msg@entry=0x557b139c2ce8 "Assertion '%s' failed at %s:%d") at sysdep/unix/log.c:412 #5 0x0000557b13934353 in rt_notify_basic (c=c@entry=0x557b1d7e2e10, new=<optimized out>, new@entry=0x7fac024adfb8, old=old@entry=0x7fac8828a938) at nest/rt-table.c:1192 #6 0x0000557b139385cb in channel_notify_basic (_channel=0x557b1d7e2e10) at nest/rt-table.c:1627 #7 0x0000557b139010a6 in ev_run_list_limited (l=l@entry=0x557b1d7e37d8, limit=4294967294, limit@entry=4294967295) at lib/event.c:336 #8 0x0000557b139af4ff in birdloop_run (_loop=0x557b1d7e3700) at sysdep/unix/io-loop.c:1836 #9 0x0000557b139010a6 in ev_run_list_limited (l=0x557b1d898fb8, limit=4294967294, limit@entry=4294967295) at lib/event.c:336 #10 0x0000557b139ad392 in bird_thread_main (arg=0x557b1d899210) at sysdep/unix/io-loop.c:952 #11 0x00007facbfb6ab7b in start_thread (arg=<optimized out>) at ./nptl/pthread_create.c:448 #12 0x00007facbfbe87b8 in __GI___clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:78 I also got a Assertion '!new || rte_is_valid(new)' failed at nest/rt-table.c:1416 once but don't have a coredump for that one.

1 2

Heads up on Linux kernel supported TCP-AO algorithms
by Dmitry Safonov 27 Apr '26

27 Apr '26

Hi Bird devs, I'm writing because I see your supported algorithms definition for TCP-AO is : static const char * const tcp_ao_alg_names[] = { : [ALG_CMAC_AES128_AO] = "cmac(aes128)", : [ALG_HMAC_MD5] = "hmac(md5)", : [ALG_HMAC_SHA1] = "hmac(sha1)", : [ALG_HMAC_SHA224] = "hmac(sha224)", : [ALG_HMAC_SHA256] = "hmac(sha256)", : [ALG_HMAC_SHA384] = "hmac(sha384)", : [ALG_HMAC_SHA512] = "hmac(sha512)", : }; There is currently a discussion in the Linux kernel mailing list about removing the support of algorithms, leaving only cmac(aes128), hmac(sha1) and hmac(sha256) [1]. If you have users who depend on any but these, please let us know on the mailing list. Otherwise, please make sure to depricate it before Linux v7.2 gets released without them. [1] https://lore.kernel.org/lkml/20260427172727.9310-1-ebiggers@kernel.org/ Thanks, Dmitry

1 0

KIF: Received address message for unknown interface
by Kiran Katabathena 27 Apr '26

27 Apr '26

When doing a churn test we see bird speaker logs overwhelmed with below messages and we hit high CPU. 2026-04-20 08:19:06.304 [0001] <WARN> I/O loop cycle took 61075.339 ms for 1 events 2026-04-20 08:19:47.863 [0001] <ERR> KIF: Received address message for unknown interface 513817 Version used: v3.0.2 Source : https://github.com/CZ-NIC/bird We see similar issues in calico bird being fixed Remove interfaces that are flagged as shutdown. by axel7born · Pull Request #111 · projectcalico/bird <https://github.com/projectcalico/bird/pull/111/changes/b32135cb60855b8a73cf…> Could someone one check and let me know if we have fix or work around this issue? >

2 1

[PATCH] filter: Add bgp_next_hop_global and bgp_next_hop_ll for independent IPv6 next hop access
by KSKB SHI 23 Apr '26

23 Apr '26

Hi, The current bgp_next_hop filter attribute only accesses nh[0] (the global address) of the BA_NEXT_HOP eattr. The link-local address stored in nh[1] is completely invisible to filters. see this image: https://upload.cc/i1/2026/04/22/0Nj4E8.png Worse, set bgp_next_hop allocates a new 16-byte adata, silently discarding any existing link-local next hop. This makes it impossible to: - Inspect the link-local next hop in a filter - Modify only the global next hop while preserving the link-local - Set a link-local next hop independently This patch adds two new filter attributes, bgp_next_hop_global and bgp_next_hop_ll, which provide independent read/write access to nh[0] and nh[1] of the BGP next hop. Setting one does not affect other. The existing bgp_next_hop behavior is completely unchanged. Implementation: Both new attributes map to the same BA_NEXT_HOP ea_code, differentiated by the bit field of struct f_dynamic_attr (which was previously unused for EAF_TYPE_IP_ADDRESS): - bgp_next_hop — bit=0, original behavior (default from zero-init) - bgp_next_hop_global — bit=1, reads/writes nh[0] - bgp_next_hop_ll — bit=2, reads/writes nh[1] GET (FI_EA_GET): - bit=2: returns nh[1] if adata->length >= 32, otherwise IPA_NONE - bit=0,1: returns nh[0] (same as before) SET (FI_EA_SET): - bit=0: allocates new 16-byte adata with only the assigned IP (original behavior, nh[1] is lost) - bit=1,2: read-modify-write — reads the existing BA_NEXT_HOP from eattrs, updates only the target slot, preserves the other. If nh[1] is zero after the update, length is set to 16; otherwise 32. Usage example: # Read print bgp_next_hop_global; # 2404:f4c0:f70e:1980::202:881 print bgp_next_hop_ll; # fe80::ff:fe20:2881 # Modify global only, link-local preserved bgp_next_hop_global = 2001:db8::1; # Modify link-local only, global preserved bgp_next_hop_ll = fe80::99; Files changed: https://github.com/KusakabeShi/bird/commit/b5af9bc2eefbcc9e6f96432dd43fc642… - proto/bgp/config.Y — new keywords and dynamic_attr rules - filter/f-inst.c — GET/SET handling for partial next hop access The patch applies against the v2.18 release branch. Feedback welcome. Thanks, KusakabeShi

2 2

[PATCH] filter: Add bgp_next_hop_global and bgp_next_hop_ll for independent IPv6 next hop access
by Shi Kusakabe 21 Apr '26

21 Apr '26

1 0

BIRD 3.2.1, 3.1.6, 2.18.1, and 2.17.4 released
by Maria Matejka 21 Apr '26

21 Apr '26

Dear BIRD Users, it's been quite a while but we have released BIRD versions 3.2.1, 3.1.6, 2.18.1, and 2.17.4. Yes, all of these. We got a lot of bugreports, not only through the users list but also privately. Thank you all so much for them. The download link is, as always: https://bird.nic.cz/get-bird/ There is the ASPA fix you are waiting for, fixing broken downstream validation. Thanks for reporting and contributing; that was a stupid mistake. More on that hopefully at RIPE 92 in Edinburgh. Also in all released versions, there are: - bugfixes for `krt_congctl` attribute handling - logrotate file size limit lower bound (16k) - a bunch of CI updates For LTS 3.1.6 and 2.17.4, we also included fixes of BGP reconfiguration which are already in 3.2.x and 2.18.x. And then there is much more fixed in BIRD 3 alone: - logrotate crash fix - ROA check crash fix (strangely manifesting mostly when manipulating ASPA checks in filters) - graceful recovery fix (now it doesn't crash when recovery is done) - BGP route refresh request fix (now it works even after session flap) - BMP (now it actually sends routes) - rare pipe collision bug - BGP dynamic instance crash fix (3.2.1 only) - keyword redefinition allowed again (3.2.1 only) We did what we could to keep track of everything. If you reported something between 3.2 and 2.18 was released, and March 31, 2026, it should be included in this release. Yet, we may have missed something, and also while we did our best to cover all reported bugs by automatic tests, we would still love if you found some time to check that on your side and report both positive and negative outcomes. Also it looks like there are already some new bugreports. We'll try to pick them up as soon as possible. In parallel, we are also preparing a next minor (feature) release. Although the only merged feature is now RAdv neighbor discovery with BGP autoconnect, we also expect to include the `oz-evpn` branch (for both BIRD 2 and 3) and a bunch of BGP export memory optimization updates for BIRD 3. Thank you all again for all your reports, contributions, patience and efforts. Happy routing! Maria and the BIRD Team -- Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.

5 5

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

17 Apr '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

2 1

Setting BGP Aggregator Attribute in Filters
by Pavel Trefný 15 Apr '26

15 Apr '26

Hi, I have a question regarding BIRD. Is it possible to set the BGP aggregator attribute for a prefix using filters? This would be useful in our anycast setup, where it can be difficult to determine the origin of a prefix. Using communities is unfortunately not a viable option for us — some of our hardware does not support extended communities, and upstream networks often filter them. To clarify, I am not looking for route aggregation itself, but specifically a way to set the aggregator attribute. Thank you for any insights. Best regards, Pavel Trefny

2 2

IPv4 transit not routed into Wireguard tunnel (IPv6 works)
by VS 12 Apr '26

12 Apr '26

Good afternoon, need to state I am no routing expert, so bear with me if this is a dumb fault on my side. I am running bird 2.17.1 on Trixie (myASN), announcing a IPv6/48 and a IPv4/24 to upstream ASN via myASN. MyASN is running on a VPS which has a Wireguard tunnel to me here. On this side is a Pfsense with FRR announcing my 1.2.3.0/25 on vtnet6 (128 IPs should be here) through the Wireguard Tunnel to myASN. On myASN the the IPv6 Traffic works fine. Coming in from Upstream and is routed into the tunnel and traffic coming through the tunnel is routed out to the internet. In the case of IPv4 with stopped bird, I can ping e.g. 1.2.3.10 through the tunnel, which is setup using 172.16.150.8/30 using .9 and .10 on the tunnel ends. I also can ping the internet using the default gateway and the eth0 IP. When I start bird the IPv4/24 is announced to upstream and traffic comes in via eth0. Also if the 1.2.3.10 host behind the Pfsense pings e.g. 8.8.8.8, the traffic comes up to myASN through the tunnel. But the the package is lost, not routed out to the Internet, nor is incoming traffic routed into the tunnel. I already set multihop 3 on IBGP definition because 1.2.3.0/25 is not directly connected to myASN and traffic needs to use the route into the tunnel. birdc show routes and other commands show the route are there and also ip route get shows the routes are in the kernel table master4 after bird starts. No firewall active so nothing blocks any traffic on this level. I am sure I am blind, but sitting since days searching for a solution. An link to a cool tutorial for a kinda transit traffic setup (I checked lots of them) or any hint for a possible problem in my setup would be greatly appreciated. Thank you very much!

2 1

sorted route advertisements from bird bgp session.
by gautham devalapalli 08 Apr '26

08 Apr '26

Hello, When advertising the routes from BGP to an nxos switch, we are noticing the routes come in random order instead of sequential order. I tried using `sorted` option but doesnt seem to work. Using bird 2.0.8 version. Is there a way to force an order of routes like how Ixia traffic generator does this. ipv4 table ebgp1 sorted;; protocol bgp ebgp_1_node01 { local 10.0.0.2 as 65000; neighbor 10.0.0.1 as 100; ipv4 { table ebgp1; import none; export where source = RTS_STATIC; }; } protocol static v4static{ ipv4 { table ebgp1; }; route 50.0.1.1/32 via 10.0.0.2; route 50.0.1.2/32 via 10.0.0.2; route 50.0.1.3/32 via 10.0.0.2; route 50.0.1.4/32 via 10.0.0.2; route 50.0.1.5/32 via 10.0.0.2; route 50.0.1.6/32 via 10.0.0.2; } E_DEBUG [L3:TRACE l3_route.cpp: :hal_sone_l3_route_update_internal:4466] Received route add for VRF 0x1, pfx 50.0.1.1/32, route_flags 0x0 src_lif 0x0(Lo: 'FALSE') ecmp_id 0x0 adj_id: 0x40000 myip 0 attr_cnt 1 mpls_ppfx 0 vrf_redir: 0 E_DEBUG [L3:TRACE l3_route.cpp: :hal_sone_l3_route_update_internal:4466] Received route add for VRF 0x1, pfx 50.0.1.5/32, route_flags 0x0 src_lif 0x0(Lo: 'FALSE') ecmp_id 0x0 adj_id: 0x40000 myip 0 attr_cnt 1 mpls_ppfx 0 vrf_redir: 0 E_DEBUG [L3:TRACE l3_route.cpp: :hal_sone_l3_route_update_internal:4466] Received route add for VRF 0x1, pfx 50.0.1.2/32, route_flags 0x0 src_lif 0x0(Lo: 'FALSE') ecmp_id 0x0 adj_id: 0x40000 myip 0 attr_cnt 1 mpls_ppfx 0 vrf_redir: 0 E_DEBUG [L3:TRACE l3_route.cpp: :hal_sone_l3_route_update_internal:4466] Received route add for VRF 0x1, pfx 50.0.1.6/32, route_flags 0x0 src_lif 0x0(Lo: 'FALSE') ecmp_id 0x0 adj_id: 0x40000 myip 0 attr_cnt 1 mpls_ppfx 0 vrf_redir: 0 E_DEBUG [L3:TRACE l3_route.cpp: :hal_sone_l3_route_update_internal:4466] Received route add for VRF 0x1, pfx 50.0.1.3/32, route_flags 0x0 src_lif 0x0(Lo: 'FALSE') ecmp_id 0x0 adj_id: 0x40000 myip 0 attr_cnt 1 mpls_ppfx 0 vrf_redir: 0 E_DEBUG [L3:TRACE l3_route.cpp: :hal_sone_l3_route_update_internal:4466] Received route add for VRF 0x1, pfx 50.0.1.4/32, route_flags 0x0 src_lif 0x0(Lo: 'FALSE') ecmp_id 0x0 adj_id: 0x40000 myip 0 attr_cnt 1 mpls_ppfx 0 vrf_redir: 0 Sincerely Gautham

2 3