September 2026 - Bird-users

rpki local address + remote "<hostname>": AF mismatch reaches an assert in sk_open() (3.3.2)
by Hendrik Visage 20 Oct '26

20 Oct '26

(Claude report on another crash experienced on a greenfields BIRD3 deployment): Hello, On BIRD 3.3.2, an RPKI cache configured by name with a local address of the other address family logs an assertion at startup and then simply never connects: bird: 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:1766 Config (four caches, all by name, all with the same IPv4 local address = our loopback; two of the four produced the assertion, one each at two consecutive starts): protocol rpki rpki_3_rtr_rpki_cloudflare_com { roa4 { table roa_v4; }; roa6 { table roa_v6; }; remote "rtr.rpki.cloudflare.com" port 8282; local address 102.205.240.1; refresh 300; retry 600; expire 7200; transport tcp; } Cause, reading 3.3.2: rpki_tr_open() (proto/rpki/transport.c) sets sk->saddr = cf->local_ip first, and only then resolves the name if cf->ip is unset. rpki_hostname_autoresolv() asks getaddrinfo() with .ai_family = AF_UNSPEC and takes res->ai_addr, i.e. whichever family the resolver happens to return first, without consulting cf->local_ip. If that is the other family, sk_open() is reached with mismatched saddr/daddr. In a release build the ASSERT only logs (lib/birdlib.h:270), and af is then derived as (ipa_is_ip4(saddr) || ipa_is_ip4(daddr)) ? AF_INET : AF_INET6, so the socket cannot work — with no error message that points at the cause. Two things would make this diagnosable: pass the family as a hint when it is known: .ai_family = ipa_zero(cf->local_ip) ? AF_UNSPEC : (ipa_is_ip4(cf->local_ip) ? AF_INET : AF_INET6), which is also what an operator means by pinning a source address; if they still disagree, log(L_ERR "%s: local address %I and resolved %I are different address families", …) and return RPKI_TR_ERROR instead of falling into the assert. A related nicety: rpki_hostname_autoresolv() uses only the first addrinfo, so a dual-stacked cache is effectively "whatever the resolver ordered first" even without a local address. An explicit per-protocol family selector would remove the guesswork. Dropping local address from all four rpki protocols was enough for us; the pin was never a requirement on our side. Environment: bird3 3.3.2 from the BIRD Debian repository, amd64, Devuan 6 (trixie-equivalent), kernel 7.0.14-4-pve, KVM guest. Thanks, --- Hendrik Visage Director/Owner HeViS.Co Systems t/a Envisage Cloud SolutionsAS213481 hvisage(a)hevis.co.za GSM/SMS/Signal: +27-84-612-5345 InstantMessenger: https://t.me/hvisage

2 1

OSPFv2: a Network LSA from another router is refreshed when its ID is a local address
by Shariq Faran (Nokia) 14 Oct '26

14 Oct '26

Hello, OSPFv2 is right to treat a Network LSA as self-originated when its Link State ID is one of our interface addresses, even if another router advertised it (RFC 2328 13.4). The next step is wrong. If this router is not originating that LSA, it should be flushed at MaxAge. Instead, when a copy younger than MaxAge is already in the local LSDB, BIRD refreshes it and leaves the other router's ID in the Advertising Router field. The two routers then exchange that same LSA continuously, one at age 0 and the other at age 3600. This is in proto/ospf/lsupd.c, in ospf_receive_lsupd(), at the 13.(5f) / 13.4 check, and in ospf_advance_lsa() in proto/ospf/topology.c. It is present in BIRD 2.0.8. The same check is still in current master as of 29 Sep 2026. This is not a security issue. The receive check is: lsa.rt == router_id OR (OSPFv2 AND type is Network AND ospf_addr_is_local()) ospf_addr_is_local() walks every OSPF interface in the area and compares the Link State ID with the interface address. A match calls ospf_advance_lsa(). That function has two branches. If the local copy exists and its age is still under MaxAge, it does only this: sequence = received sequence + 1 age = 0 It does not change the Advertising Router. It then floods that copy. The log line is printed only in this branch: Advancing LSA: Type: 2002, Id: 10.0.0.1, Rt: 192.0.2.1, Seq: 80000002 If there is no local copy, or the local copy is already MaxAge, the same function installs the received LSA at MaxAge and floods that. That second branch is the flush. The loop needs the first branch, so it needs a young copy to still be present. How the two routers keep it going Call the router named on the LSA R1 (192.0.2.1). Call the router that now has the address R2 (192.0.2.2). The Link State ID is 10.0.0.1. 1. R1 no longer has 10.0.0.1. The LSA still carries R1's router id, so R1 takes the self-originated path. Its copy is MaxAge, so it floods age 3600. 2. R2 still has 10.0.0.1, so it also takes the self-originated path. Its copy is younger than MaxAge, so it sets age 0 and sequence plus 1, leaves the Advertising Router as 192.0.2.1, and floods that. 3. R1 receives a newer copy that still carries its own router id. Its local copy is MaxAge, so it floods age 3600 again. Each pass is limited by MinLSArrival. A normal Network LSA refresh is 1800 seconds. SPF runs on every pass. How to reproduce Two routers, one OSPFv2 area, broadcast interfaces. No customer network is involved. These addresses are only an example. R1 router id 192.0.2.1 R2 router id 192.0.2.2 A broadcast link on which R1 is DR, interface address 10.0.0.1/30 R1 has a full neighbor, so it originates: type 2002, id 10.0.0.1, advertising router 192.0.2.1 While that LSA is still in R2's LSDB and its age is under 3600: 1. Configure 10.0.0.1/30 on R2, on an OSPF interface in the same area. 2. After that, delete 10.0.0.1/30 from R1. R2 must already hold a copy younger than MaxAge at step 2. That is the copy it will advance. When this will not show up The flush sticks if the address is deleted on R1 first, and R2 is given 10.0.0.1 only after that Network LSA is age 3600 or gone from R2. There is then no young copy to advance. Deleting 10.0.0.1/30 on R1 and configuring the same address back on R1 does not start the loop. A point-to-point link does not originate a Network LSA, so it does not hit this either. Suggested fix For a Network LSA whose Advertising Router is not the local router id, use the flush that ospf_advance_lsa() already uses when the local copy is missing or MaxAge. Do that even if a young copy exists. A Network LSA this router really originated (lsa.rt == router_id) should still advance as it does today. Against current master, inside the existing self-originated block: OSPF_TRACE(D_EVENTS, "Received unexpected self-originated LSA"); if ((lsa_type == LSA_T_NET) && (lsa.rt != p->router_id)) { lsa.age = LSA_MAXAGE; en = ospf_install_lsa(p, &lsa, lsa_type, lsa_domain, body); ospf_flood_lsa(p, en, NULL); continue; } ospf_advance_lsa(p, en, &lsa, lsa_type, lsa_domain, body); continue; I can send this as a patch against master if that is useful. Thanks, Shariq Faran

3 5

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

How to switch from bird1.6 to bird2 without dropping routes?
by CH 05 Oct '26

05 Oct '26

Hi; We've got a bunch of Ubuntu 22.04 machines around the world using BIRD1.6 to provide anycast for nginx, much like Google does for DNS at 8.8.8.8. Each machine is in a different data center, talking to an ISP's router, and each ISP is different. Now we want to switch to BIRD2, but we don't want to interrupt service by dropping routes if we can help it. One piece of advice we got was to run BIRD1.6 and BIRD2 side-by-side on the same machine, and establish a new BGP session with BIRD2 before turning off BIRD1.6. I found https://bird.network.cz/pipermail/bird-users/2024-May/017665.html, which sets them up in two different network namespaces, but I don't know why that is helpful or if there's more to do. This is what I've worked out so far: ------------------->8-----cut here----->8------------------ $ sudo -i # apt install bird # rm /var/lib/dpkg/info/bird.prerm # mv /run/bird/* /run # apt install bird2 # systemctl cat bird > /tmp/bird.service # systemctl edit --force --full bird2 ( load the contents of /tmp/bird.service ) # systemctl start bird2 # birdc -s /run/bird/bird.ctl show status | head -n1 BIRD 2.0.8 ready. # birdc -s /run/bird.ctl show status | head -n1 BIRD 1.6.8 ready. ------------------->8-----cut here----->8------------------ The remaining question is what do we have to do change in the new BIRD2 /etc/bird/bird.conf file to allow it to take over for the old BIRD1.6? That's in addition to the expected configuration file changes needed for BIRD2 compatibility (which we may or may not have done correctly). I suspect we'll have to change the router id at the very least; do we also have to bind to another ip address and set strict binding? Thank you! -- CH (ch-and-bird-users(a)ch.pkts.ca)

5 7

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

Crash on radv protocol when tracing is enabled
by Strzadala, Michal 28 Sep '26

28 Sep '26

Hello, We've been experiencing bird crashes while using the radv protocol with enabled tracing on v2.19.2 (master branch is also affected). I've found that wrong struct is casted and forwarded into RADV_TRACE macro causing "bug("unknown network type")" and SIGABRT at the end. Patch: diff --git a/proto/radv/radv.c b/proto/radv/radv.c index 7c2e8953..db2910b6 100644 --- a/proto/radv/radv.c +++ b/proto/radv/radv.c @@ -291,29 +291,30 @@ radv_prune_neighbors(struct radv_proto *p) { /* Only process routes from our protocol */ if (e->src != p->p.main_source) - continue; + continue; /* Get the expiration time EA */ eattr *expires_ea = ea_find(e->attrs->eattrs, EA_RA_LIFETIME); if (!expires_ea) - continue; + continue; btime expires = expires_ea->u.data S; if (expires <= now) { - /* Neighbor has expired, add to withdrawal list */ - net_addr_nbr *nbr = (net_addr_nbr *) e->net; + /* Neighbor has expired, add to withdrawal list */ + net_addr_nbr *nbr = (net_addr_nbr *) n->n.addr; - struct expired_nbr *ep = tmp_allocz(sizeof(struct expired_nbr)); - net_copy_nbr(&ep->n, nbr); - ep->next = expired_list; - expired_list = ep; + struct expired_nbr *ep = tmp_allocz(sizeof(struct expired_nbr)); + net_copy_nbr(&ep->n, nbr); + ep->next = expired_list; + expired_list = ep; - RADV_TRACE(D_EVENTS, "Router %N expired", nbr); + RADV_TRACE(D_EVENTS, "Router %N expired", nbr); + } + else { + next = MIN(next, expires); } - else - next = MIN(next, expires); } } FIB_WALK_END; Regards, Michal

3 3

Bug Report - BIRD 3.3.2 — `Assertion '!new || rte_is_valid(new)' failed at nest/rt-table.c:1562`
by Lars Strandos 25 Sep '26

25 Sep '26

Hi, # BIRD 3.3.2 — `Assertion '!new || rte_is_valid(new)' failed at nest/rt-table.c:1562` Apparent race between `rt_next_hop_update_net()` and `channel_notify_optimal_req()`. Addresses, ASNs and hostnames below are replaced with documentation ranges (RFC 5398, RFC 3849). Pointer values, offsets and line numbers are verbatim. ## Summary BIRD 3.3.2 aborts on an internal assertion roughly every 20–40 seconds on two independent route servers once recursive next-hop resolution is active and the table is under churn. ``` Assertion '!new || rte_is_valid(new)' failed at nest/rt-table.c:1562 ``` **84 and 81 aborts** in about 40 minutes. The two machines are separate VMs on separate hypervisors, same configuration shape, same peers. They began aborting **three seconds apart**, which pointed at a data/timing trigger arriving over BGP rather than anything host-local. The backtrace shows the assertion firing in the main loop while a worker thread is suspended mid-update inside `rt_next_hop_update_net()`. ## Environment ``` BIRD 3.3.2 (Debian package bird3 3.3.2-cznic.1~trixie, amd64) OS Debian GNU/Linux 13 (trixie) Kernel 6.12.107+deb13-cloud-amd64 Role IX-style route server ``` Ruled out: 16 GB RAM, ~1 GB in use, BIRD RSS 538–564 MB at abort. No kernel OOM records, `dmesg` clean. Configuration parses (`birdc configure check` → OK). ## Backtrace Symbolised with `bird3-dbgsym` 3.3.2-cznic.1~trixie. **Thread 1 — main loop, the abort:** ``` #3 bug (msg=msg@entry=0x... "Assertion '%s' failed at %s:%d") at sysdep/unix/log.c:446 #4 channel_notify_optimal_req (c=c@entry=0x562028c3a000, req=req@entry=0x562028c3a128) at nest/rt-table.c:1562 new = <optimized out> old = <optimized out> trte = <optimized out> u = 0x7f8308f4f2b0 #5 channel_notify_optimal (_channel=0x562028c3a000) at nest/rt-table.c:1591 c = 0x562028c3a000 #6 ev_run_list_limited (l=0x... <global_work_list>, limit=7, limit@entry=10) at lib/event.c:336 #7 io_loop () at sysdep/unix/io.c:2642 #8 main (argc=<optimized out>, argv=<optimized out>) at sysdep/unix/main.c:1114 ``` **Thread 2 — next-hop update worker, suspended mid-update:** ``` #5 birdloop_yield () at sysdep/unix/io-loop.c:2372 #6 synchronize_rcu () at ./lib/rcu.h:96 #7 rt_next_hop_update_net (tab=<optimized out>, ni=<optimized out>, n=<optimized out>) at nest/rt-table.c:4747 #8 rt_next_hop_update (_tab=<optimized out>) at nest/rt-table.c:4951 #9 ev_run_list_limited (l=l@entry=0x..., limit=4294967294, limit@entry=4294967295) at lib/event.c:336 #10 birdloop_run (_loop=0x...) at sysdep/unix/io-loop.c:2114 #11 ev_run_list_limited (...) at lib/event.c:336 #12 bird_thread_main (arg=0x...) at sysdep/unix/io-loop.c:1034 ``` **Thread 3 — idle in `poll()`**, `bird_thread_main` at `sysdep/unix/io-loop.c:1094`. ## What this looks like Thread 2 is inside `rt_next_hop_update_net()` and has yielded in `synchronize_rcu()` → `birdloop_yield()`, so the network it is updating is part-way through modification. Thread 1, in the main loop, runs `channel_notify_optimal()` for a channel and `channel_notify_optimal_req()` asserts that the route it has been handed is valid. We have not read the source to confirm the exact window, and the relevant locals are optimised out, so this is offered as where to look rather than as a diagnosis. ## Reproduction Consistent and quick once the conditions are present: 1. Route server with ~1.07M IPv4 and ~250k IPv6 in `master4`/`master6`, learned over two multihop eBGP sessions from edge routers. 2. Eight multihop eBGP customer sessions sourced from a loopback, whose next hops require **recursive resolution** against the local table. 3. A default route installed such that those next hops actually resolve. 4. Churn — a session flap, or `systemctl restart bird` to reload the full table. The abort then occurs within seconds to a couple of minutes, repeatedly. Log immediately before one abort, showing recursive resolution in bulk: ``` Next hop address 2001:db8:0:2::211 resolvable through recursive route for 2001:db8::/32 Next hop address 2001:db8:1000:700::11 resolvable through recursive route for 2001:db8::/32 Next hop address 2001:db8:1::1 resolvable through recursive route for 2001:db8:1::/48 Next hop address 2001:db8:1::1 resolvable through recursive route for 2001:db8:1::/48 Next hop address 2001:db8:1::2 resolvable through recursive route for 2001:db8:1::/48 Next hop address 2001:db8:1::2 resolvable through recursive route for 2001:db8:1::/48 Assertion '!new || rte_is_valid(new)' failed at nest/rt-table.c:1562 ``` Before another: ``` edge_a.ipv4: table prune after refresh end: rr 4096 set 5 valid 5 pruning 5 pruned 5 fabric_b: Connecting to 2001:db8:100:b00b::3 from local address 2001:db8:1000:701::1 fabric_b: Connection lost (Connection refused) fabric_b: Connect delayed by 5 seconds device1: Scanning interfaces Assertion '!new || rte_is_valid(new)' failed at nest/rt-table.c:1562 ``` ## The workaround, which also isolates the trigger Changing **one line** — the static default used as the recursive resolution target — is the difference between a stable process and one aborting every 20–40 seconds. Same box, same table, same peers. ``` # aborts, 84 times in ~40 minutes protocol static resolver6 { ipv6; route ::/0 via fe80::1%eth0; } protocol static resolver4 { ipv4; route 0.0.0.0/0 via "eth0"; } # stable, 30+ minutes and counting protocol static resolver6 { ipv6; route ::/0 blackhole; } protocol static resolver4 { ipv4; route 0.0.0.0/0 blackhole; } ``` With `blackhole` the default still exists in the table and is still exported to peers, but nothing resolves recursively through it — so `rt_next_hop_update_*` has no hostentries to process and Thread 2's code path is never entered. This was verified as a controlled test rather than assumed: the change was applied to **one** of the two route servers while the other was left alone. The changed box stopped aborting immediately (restart counter frozen, uptime growing past 30 minutes); the untouched box continued aborting every 20–40 seconds until the same change was applied to it. Re-applying the gateway form to the second box reproduced the abort on demand and produced the core above. ## Configuration shape ``` Protocols 12 BGP, 5 Static, 2 Pipe, 2 Kernel, 1 RPKI, 1 BFD, 1 Device Tables master4, master6, t_cust4, t_cust6, rpki4, rpki6, aspa1 Pipes master4 <=> t_cust4, master6 <=> t_cust6 Kernel export none, learn off (BIRD installs nothing in the FIB) RPKI RTR session with roa4, roa6 and aspa channels ``` BGP: two multihop eBGP to edge routers carrying a full table, two single-hop eBGP to switches, eight multihop eBGP customer sessions sourced from a loopback with recursive next-hop resolution. Import filters call `roa_check()` and `aspa_check_downstream()` / `aspa_check_upstream()`. ## Impact Both route servers of a redundant pair abort on the same input at the same time, and `Restart=on-abort` restarts each in a loop. Every restart drops all BGP sessions; the edge routers then re-push a full table, which does not complete before the next abort. Customer sessions cannot stay established. The redundancy provides no protection because both machines fail identically. ## Core dumps etc The compressed core (57–105 MB per dump) https://www.filemail.com/d/bpysuryqkeusczh Best regards Lars Strandos

1 0

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