- Bird-users - Mailing Lists

OSPF unexpectedly adds /128 interface route
by Lexi Winter 11 May '26

11 May '26

hello, i have an interface with a /64 address configured: # ifconfig bridge0.500 bridge0.500: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500 options=0 ether 58:9c:fc:10:8d:b4 inet6 fe80::1%bridge0.500/64 scopeid 0x1c inet6 fd13:480d:2ffa:3::1/64 groups: vlan vlan: 500 vlanproto: 802.1q vlanpcp: 0 parent interface: bridge0 nd6 options=1<PERFORMNUD> this is configured as an OSPF stub interface in BIRD: protocol ospf v3 core { area 0 { interface "bridge0.500" { stub yes; }; ... however, BIRD only adds a /128 route into the OSPF database: # birdc show route in fd13:480d:2ffa:3::/64 BIRD 3.2.0 ready. Table master6: fd13:480d:2ffa:3::1/128 unicast [core 13:25:02.965] ! I (150/0) [176.126.243.164] dev bridge0.500 fd13:480d:2ffa:3::/64 unicast [direct1 13:38:01.578] * (240) dev bridge0.500 i would have expected it to add the /64 route instead. filtering the /64 route in the direct protocol does not make any difference, except that the direct route disappears from 'show route'. am i doing something wrong? the entire configuration is here: https://www.le-fay.org/tmp/30d/bird.conf using BIRD 3.2.0 on FreeBSD 15.0.

2 3

unexpected missing enforce-first-as check in ASPA implementation
by Martin Tonusoo 07 May '26

07 May '26

Hi. According the current ASPA draft the AS_PATH should be categorized as invalid if it's empty, contains an AS_SET or most recently added AS in the AS_PATH does not match the neighbor AS except if the AS performing the ASPA check is a route-server client. aspa_check() in nest/rt-table.c returns ASPA_INVALID for empty AS_PATH and for AS_PATH containing AS_SET. However, the enforce-first-as check is not performed. I briefly tried to understand how such check could be added to aspa_check() in nest/rt-table.c, but there does not seem to be a simple and clean solution. However, I could be wrong here. It's trivial to get the leftmost AS number with as_path_get_first(), but the filter module does not seem to have access to peer AS number and doesn't know whether it's a route-server client. As a workaround, one could use a function in filters and pass this information as function arguments, e.g: function bgp_in(int peer_as; bool route_server_client) -> bool { if ! route_server_client && bgp_path.first != peer_as then reject "Invalid left-most ASN ", bgp_path.first, ". Reject ", net; ... }; .. but perhaps it's at least worth documenting it in "BIRD User's Guide" that the aspa_check_downstream(), aspa_check_upstream() and aspa_check() do not enforce first AS check. Especially as the "enforce first as" option under BGP configuration is off by default. I tested on BIRD 3.2.1. Martin

2 1

rt_lookup inside a filter
by Itz Wam 05 May '26

05 May '26

Hey folks Long time user of the software, never sent anything here, today’s my first time I cannot manage to find anything in the user guide of v1/v2/v3 concerning some sort of rt_lookup inside of filters The setup is fairly easy Routers are interconnected heterogeneously, there is a direct BGP session using link local IPv6 on any of these interconnection links Routers announce loopbacks over these sessions with rr client There is some sort of local pref / med set up for better traffic quality Then they all peer with N route reflectors Sharing the “real” prefixes via loopback addresses This works well with gateway recursive mode. There are lot of attributes that we can access inside of filters, what I cannot manage to understand is if it’s possible and how to access let’s say in a filter configured at the RR protocol import/export side - the attributes of the computed gateway - that has been announced on the “underlay” BGP protocol side For example using external access to bird I can $ birdc show route all ::/0 ::/0 unicast [RR] * via 2001:db8::1 on IFACE # No BGP.Med $ birdc show route all 2001:db8::1/128 2001:db8::1/128 unicast [PROTO] * via fe80::1 on IFACE BGP.med: X BGP.local_pref: Y Hope I didn’t miss some context Thanks in advance

1 0

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