August 2026 - Bird-users

Re: Assertion '!new || rte_is_valid(new)' failed at nest/rt-table.c:1562
by Danylo Mikula 08 Oct '26

08 Oct '26

Hello Maria, We hit this one too, on routers that hold a multihop upstream session, so here is a reproducer for it, attached as bird-repro-rte-is-valid.sh. It came out smaller than your sketch: one upstream rather than ten, no `merge paths`, and no reconfiguration -- the trigger is `birdc disable`/`enable` of a static protocol. It uses two network namespaces, needs only root, iproute2 and bird3, and cleans up after itself. Three conditions look each necessary and together sufficient: 1. the channel keeps filtered routes -- `import table on`, or `import keep filtered` 2. the next hop is resolved recursively -- i.e. a multihop session 3. the route resolving it changes -- appearing or disappearing, either direction The script runs the same scenario five times, removing one ingredient at a time. On Debian's bird3 3.3.2-1~bpo13+1: BIRD version 3.3.2 import table, multihop, remove filtered=1 *** ABORTED *** keep filtered, multihop, remove filtered=1 *** ABORTED *** import table, multihop, ADD filtered=1 *** ABORTED *** import table, NOT multihop, rm filtered=1 survived no keep-filtered, multihop, rm filtered=0 survived the assertion, deduplicated over the aborted runs: Assertion '!new || rte_is_valid(new)' failed at nest/rt-table.c:1562 On your note about 3.1.x: I believe it will not abort there, although it may well reach the same state. The assertion is in nest/rt-table.c on v3.2.0, v3.2.3, v3.3.2 and thread-next, and absent on v3.1.7 and v3.1.8, which carry `/* Ignore invalid routes */` and `if (!rte_is_valid(new)) new = NULL;` at that point instead. It looks introduced by 34a8a2749b1cab415c48b2cbdb05bc8faf345374 ("Table: Optimal and Any Export refactoring"), which is not reachable from master, is contained in no v2 tag, and whose earliest release tag is v3.2.0. One more thing that may narrow it down. With `merge paths` configured, sysdep/unix/krt.c:911 sets `cc->ra_mode = RA_MERGED`, while the channel default is RA_OPTIMAL (nest/proto.c:1322) and the assertion is in the RA_OPTIMAL consumer -- so in Christoph's configuration the kernel channel should not have been the subscriber that died. His follow-up message on the list mentions that two of his three upstreams are multihop, which fits condition 2 above. The script is standalone and needs nothing beyond iproute2, so it should adapt into a netlab case without much work. Thanks, Dan

2 1

[PATCH] BGP: Fix bucket assert when encoding BMP route monitoring messages
by Yifei Sun 07 Oct '26

07 Oct '26

Good afternoon, the 2 issues I reported last week (e038bf6 and 371531d) was resolved on my side in 3.3.1. Thank you! Today in CI, I'm seeing some assertion throws that affects both 3.3.0 and 3.3.1 with BMP (traces also in the linked CI log): - https://github.com/stepbrobd/rfm/actions/runs/27352866052/job/80819677363#s… - https://github.com/stepbrobd/rfm/actions/runs/27347885470/job/80814124422#s… Relevant config: - https://github.com/stepbrobd/rfm/blob/187c61620b3af6ec77e1cc730c6b6b37d174d… I applied the same patch on 3.3.1 locally to unblock CI, and the current patch is based on thread-next bgp_create_update_bmp() encodes routes for BMP using a temporary bucket allocated on stack. Such buckets are not allocated from the bucket slab and have no ID assigned, so the assert at the beginning of bgp_delete_from_bucket() fails as soon as the NLRI encoder pops the prefix, aborting the daemon on the first route monitoring message that carries a real prefix. On BIRD 3.3.1: > Assertion 'b->my_id' failed at proto/bgp/attrs.c:2020 Temporary BMP buckets always hold exactly one prefix and take the single-prefix path, which does not use the bucket ID at all, so allow them through the assert. Introduced in 9fa3e89476ed53b6a9d41931a8cdf9a8c675be27 "BGP: Compacting export prefix buckets" --- proto/bgp/attrs.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/proto/bgp/attrs.c b/proto/bgp/attrs.c index 6c38d4955..ee893d2c1 100644 --- a/proto/bgp/attrs.c +++ b/proto/bgp/attrs.c @@ -2063,7 +2063,7 @@ bgp_delete_from_bucket(struct bgp_ptx_private *c, struct bgp_bucket *b, u32 id) bgp_bucket_consistency(b); #endif - ASSERT_DIE(b->my_id); + ASSERT_DIE(b->my_id || b->bmp); u32 row_num = BUCKET_PREFIX_ROW(id); u32 pos = BUCKET_PREFIX_POS(id); ASSERT_DIE(b->last_pref_id); -- 2.54.0

3 5

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

[Bug]: BIRD 3.3.1 memory leak on CLI call invocations
by Laszlo Király 29 Sep '26

29 Sep '26

Hello BIRD maintainers, I would like to report a memory leak in BIRD3. After uplifting from v2 we can see a persistent memory consumption increase in bird daemon. Running bird daemon by Valgrind turned out that the leak is in BIRD3's 'domain_new' called from 'cli_command'. Every birdc interaction leaks one 80-byte domain object. ==53== 248,160 bytes in 3,102 blocks are definitely lost in loss record 204 of 204 ==53== at 0x48419B4: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==53== by 0x4990D1: bird_xmalloc (xmalloc.c:46) ==53== by 0x584514: domain_new (domain.c:72) ==53== by 0x499438: obstacle_target_init (obstacle.h:57) ==53== by 0x499BCD: cli_command (cli.c:258) ==53== by 0x499D48: cli_event (cli.c:294) ==53== by 0x47CCEE: ev_run_list_limited (event.c:336) ==53== by 0x572FFE: io_loop (io.c:2641) ==53== by 0x5843CF: main (main.c:1114) ==53== ==53== LEAK SUMMARY: ==53== definitely lost: 248,160 bytes in 3,102 blocks ==53== indirectly lost: 0 bytes in 0 blocks ==53== possibly lost: 576 bytes in 2 blocks ==53== still reachable: 481,941 bytes in 3,818 blocks ==53== suppressed: 0 bytes in 0 blocks ==53== ==53== For lists of detected and suppressed errors, rerun with: -s ==53== ERROR SUMMARY: 34 errors from 12 contexts (suppressed: 0 from 0) Not familiar with BIRD source code, just guessing that domain_free() needs to be called when the CLI command's obstacle target completes. BGP+BFD routing was configured and'birdc configure/birdc show'commands are called frequently by our monitor application and the leak is proportional to CLI invocation count. Let me know if any additional detail is needed. --- Additionally, 'use-after-free errors' can be seen in the log: Invalid read of size 8 at bgp_listen_free (bgp.c:416) Address is inside a block that was already free'd by pool_free This happens during BGP protocol shutdown (proto_cleanup > proto_loop_stopped > pool_free > bgp_listen_free). The BGP listen socket structure is accessed after its containing pool is freed. This is a BIRD3 bug in protocol teardown ordering, not related to the memory leak but indicates a use-after-free that could cause crashes. Best Regards, Laszlo Kiraly

2 3

BIRD 3.3.0 Issue with bgp listen in VRF
by Arnaud Houdelette-Langlois 17 Sep '26

17 Sep '26

Hello. I’m currently trying to setup an EVPN SDN with proxmox (FRR) and bird for route reflectors and gateways. My RR BGP conf is like : template bgp vtep { vrf "vrf-underlay"; local as 65000; source address router_id; rr client; #rr cluster id 172.16.2.20; evpn { table evpnrr; igp table underlay; import all; export all; }; } protocol bgp uproxrtr1 from vtep { neighbor 172.16.2.21 internal; } This is working as long as bird is establishing the connexion. But the listening socket is opened in the default VRF. The issue disapear with bird 2.19.0, so I’ll stick with it for now. -- Arnaud HOUDELETTE-LANGLOIS Administrateur systèmes et réseaux informatiques Responsable de la sécurité des systèmes d'information Normandie-Université +33 2 31 56 69 54

2 2

Static route loses interface tracking after birdc configure
by Danylo Mikula 31 Aug '26

31 Aug '26

Hello, On BIRD 3.3.2 a static route with an interface or neighbour next hop stops reacting to interface state after the first `birdc configure`. It is frozen at whatever state that reconfiguration evaluated and never moves again -- it neither withdraws when the interface goes down nor returns when it comes back -- until `birdc restart <proto>`. `configure soft` and `configure undo` behave the same, and `birdc reload` does not repair it. `check link` makes no difference either way. The attached reproducer, bird-repro-static-iface-tracking.sh, needs only root, iproute2 and an installed bird3, cleans up after itself, and marks any step whose result differs from expectation. On Debian's bird3 3.3.2-1~bpo13+1: BIRD version 3.3.2 fresh: iface up route=yes want=yes fresh: iface down route=no want=no fresh: iface up route=yes want=yes -- birdc configure, configuration unchanged -- after cfg: iface up route=yes want=yes after cfg: iface down route=yes want=no <-- MISMATCH after cfg: iface up route=yes want=yes -- birdc restart s1 -- after restart: down route=no want=no -- birdc configure, taken while the iface is DOWN -- still down route=no want=no then: iface up route=no want=yes <-- MISMATCH then: iface down route=no want=no The same script on the same machine, with BIRD= and BIRDC= pointing at Debian's bird2 2.17.5-0+deb13u1: BIRD version 2.17.5 fresh: iface up route=yes want=yes fresh: iface down route=no want=no fresh: iface up route=yes want=yes -- birdc configure, configuration unchanged -- after cfg: iface up route=yes want=yes after cfg: iface down route=no want=no after cfg: iface up route=yes want=yes -- birdc restart s1 -- after restart: down route=no want=no -- birdc configure, taken while the iface is DOWN -- still down route=no want=no then: iface up route=yes want=yes then: iface down route=no want=no Where it seems to come from: the dependency is the route chain hanging off the neighbour-cache entry. `static_reconfigure_rte()` calls `static_add_rte()`, which links the new route into `n->data`, and then `static_reset_rte()`, which sets `r2->neigh->data = NULL`. `neigh_find()` returns the same cached neighbour for an unchanged next hop, so the reset clears the chain the add has just built, and `static_neigh_notify()` then walks an empty list. That came in with commit eb6918e4db57b7e5fabc531963deb46313289d80 ("Neighbor cache: fixed neighbor referencing"), which replaced a plain `r2->neigh = NULL;` in `static_reset_rte` with a block that also clears the shared `r2->neigh->data`, and added the matching `neigh_link()` in `static_add_rte`. The commit is not reachable from master, no v2 tag contains it, and the earliest release tag that does is v3.0.0 -- which matches bird2 passing the run above. Thanks, Dan

1 0

BIRD crashes on FreeBSD with ipa_zero()/ipa_is_ip4() assertion
by Pouria Mousavizadeh Tehrani 27 Aug '26

27 Aug '26

Hi, I'm trying to switch a FreeBSD IXP router from another routing daemon to BIRD for BGP. I already have OSPF running on the same system, and BIRD works without any problems. However, after starting BIRD and establishing/attempting to establish BGP sessions, I get the following error multiple times in `bird.log`: [0001] <BUG> Assertion 'ipa_zero(s->saddr) || ipa_zero(s->daddr) || (ipa_is_ip4(s->saddr) == ipa_is_ip4(s->daddr))' failed at sysdep/unix/io.c:1767 Many seconds after these errors, BIRD crashes. BIRD version: 3.3.2 (the same issue also occurs with older versions) FreeBSD version: 16.0-CURRENT (same with 15.1-RELEASE) Thanks, -- Pouria

2 1

ECMP for BGP multihop vs. direct
by Christoph 26 Aug '26

26 Aug '26

Hi, we have 3 BGP upstreams a) direct b) multihop c) multihop a) always wins against b) and c) even if the AS path length is equal in all 3 cases. What is the recommended way to tell BIRD 3.3.x that it should consider them as if they were all direct and ignore the fact that some are multihop? goal: ECMP routes get installed for all 3 upstreams when their properties match. best regards, Christoph

2 1

Assertion '!new || rte_is_valid(new)' failed at nest/rt-table.c:1562
by Christoph 26 Aug '26

26 Aug '26

Hi, on bird 3.3.2-cznic.1~trixie after adding: merge paths on limit 3; to the IPv6 protocol settings and reconfiguring I noticed this BUG line in the log running 'configure' a second time did not reproduce the same BUG log entry: <INFO> Reconfigured <TRACE> device1: Scanning interfaces <TRACE> kernel2: Scanning routing table <TRACE> kernel2.ipv6: Export state changed from DOWN to FEEDING <TRACE> kernel2.ipv6: Export state changed from FEEDING to PARTIAL <TRACE> kernel2.ipv6: route refresh begin: rr 13057 set 1 valid 0 pruning 0 pruned 0 <TRACE> kernel2: Pruning table master6 <TRACE> kernel2.ipv6: route refresh end: rr 13057 set 1 valid 1 pruning 0 pruned 0 <TRACE> kernel2.ipv6: table prune after refresh begin: rr 13057 set 1 valid 1 pruning 1 pruned 0 <TRACE> kernel2.ipv6: table prune after refresh end: rr 13056 set 1 valid 1 pruning 1 pruned 1 <WARN> I/O loop cycle took 6999.418 ms for 10 events <BUG> Assertion '!new || rte_is_valid(new)' failed at nest/rt-table.c:1562 best regards, Christoph

2 1

[PATCH 0/3] filter: improve runtime error diagnostics
by Alice39s 12 Aug '26

12 Aug '26

Hi, Filter runtime errors (`F_ERROR`) currently share filtered counters and the `filtered out` route trace with intentional policy rejects (`F_REJECT`). The detailed interpreter error is rate-limited, which can make route-dependent filter failures difficult to classify. One example is constructing a standard-community pair from a 32-bit Large Community field. Configuration parsing succeeds because the concrete value is route-dependent, but a value above 65535 correctly fails the pair constructor at runtime. This series: 1. reports both evaluated values in pair range errors; 2. keeps the existing filtered aggregate, adds a runtime-error subset for import and export, and uses a distinct route trace; 3. documents runtime pair checks and a safe LC-field guard. The series does not change log rate limits or add another error-log source. Silent export evaluations do not alter the new counters, and import keep-filtered behavior is unchanged. Base: thread-next 06ca9bf5c588df6c0587eb64bd375eb0ade526ab Validation: - autoreconf, configure, full build, and make check; - BIRD user and programmer HTML documentation; - daemon-level import/export errors and explicit-reject controls; - keep-filtered and silent export-query behavior. An equivalent series for current master is available if this should also land in BIRD 2. Alice39s (3): filter: report values for out-of-range pair components nest: track filter runtime errors in channel statistics doc: explain pair construction range failures Thanks, Alice39s alice39s(a)xmsl.dev

2 6