- Bird-users - Mailing Lists

BIRD 3.3.3, 3.2.4, 3.1.9, 2.19.3, 2.18.4, 2.17.7 released
by Maria Matejka 05 Oct '26

05 Oct '26

Dear BIRD users, we're releasing patch versions for all the supported branches. Downloads are possible at <https://bird.nic.cz/get-bird/> and in our upstream repositories. Apart from a bit of hardening, nothing is really security-relevant here. We have fixed a bunch of bugs. There are still more bugs to fix. The selection of what is fixed has no particular rule. Mostly, somebody in the team just picked up *something* and fixed it. We are fixing: - several bugs in BMP in BIRD 3 - interface handling with EVPN/Bridge and a BIRD 3 crash in MPLS reconfiguration - a bunch of corner cases in OSPF, RPKI, RAdv, and the common core If your bug report has been reported as fixed, we would love if you confirmed that from your side. If not, it will most probably get fixed in the next patch release. Officially supported versions are now: - 3.3.x and 2.19.x until 6 months after 3.4.0 and 2.20.0 get released - 3.2.x and 2.18.x until end of November 2026 - LTS 3.1.x and 2.17.x tracking Debian Trixie Also, on commercial note, we offer BIRD Support services, so that you can get help with configuration, priority access to critical bug information and fixes, and better influence the overall development directions. It's the users paying for these services, who keep the development running, so thank you to all who is already doing so! More on that at our website: <https://bird.nic.cz/commercial-services/> Happy routing! Maria and the BIRD Team -- Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.

1 0

[PATCH 0/2] A few small improvements to RAdv
by LEdoian 01 Oct '26

01 Oct '26

Hello, I'm sending a few small patches that really mostly scratch my itch. First one is just a small clarification in docs of behaviour I found surprising, second makes the built-in defaults for prefix option parameters (L and A bits, lifetimes) configurable in radv protocol instance. This is my first patch, so I'm open for comments (but if this looks alright, feel free to use as is :-) ). I didn't yet figure out what would be the best approach to test this in the test suite (BIRD is not a great RA client), so I would appreciate some guidance/hints on that. Also, I'm not entirely sure whether this feels “BIRDy” enough (I have some thoughts on that, but for now I'll skip the extensive deliberation here). I've been running this code for about a week now on my router (my networks don't use SLAAC, which was my itch), it feels stable, but I have no hard data on that. Apart from the patches heere, I have uploaded the code to <https://gitea.ledoian.cz/LEdoian/bird> (the web interface to the commits won't work, feel free to clone that). LEdoian (2): Docs: Add note about when RAdv keeps prefix RAdv: Make default prefix options configurable doc/bird.sgml | 15 ++++++++++++++- proto/radv/config.Y | 20 +++++++++++++++----- proto/radv/radv.c | 14 ++++++-------- proto/radv/radv.h | 1 + 4 files changed, 36 insertions(+), 14 deletions(-) -- 2.55.0

1 2

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

Re: Excuse me
by zx l 12 Sep '26

12 Sep '26

hi can u help make sure how much u have fixed? i need to get the answer

1 0

3D Printing Market Prospects: Technology Advancements, Regional Insights & Industry Forecast to 2035
by km3065158＠gmail.com 01 Sep '26

01 Sep '26

The latest report published by Roots Analysis, titled 3D Printing Market offers a detailed study of the industry size, growth scenarios, and fundamental parameters of the market analysis. In this research report, the author provided an in-depth analysis of market dynamics, including key drivers, restraints, opportunities, and major threats that may impact growth during the upcoming years. Our market analysis report provides a brief discussion on leading market players, the competition landscape, regional dominance, supply-demand ratio, business strategies, and future investment opportunities in the overall industry. This report provides a complete prototype of the estimated growth rate, market value, product types, applications, and type of end users active in this industry. Global 3D Printing Market Size Overview The global 3D Printing market is witnessing an upward trajectory owing to the growing demand for 3D Printing products. In this market study report, authors have covered a comprehensive analysis on current market size and future growth during the projected period. The latest insightful information on market size and future growth opportunities serves as a valuable document to make business decisions promptly. Global 3D Printing Market Dynamics Insight In this exclusive report on the global 3D Printing market, our researcher offers an illustrative study on major market dynamics including competitive landscape, industry outlook, skeptical study on major threats and growth opportunities. Competitive Landscape of 3D Printing Market: Our latest market research report on the 3D Printing market offers an exclusive analysis of the competitive landscape, key players, and company profiles. In order to leverage a competitive edge, the active players in this industry have taken strategic initiatives such as mergers & acquisitions, business deals, collaborations, technological advancements, joint ventures, and the latest product launches. Key Companies Profiled in the Report are • 3D Systems • 3DCeram • Arcam • Autodesk • Canon • Carbon • Dassault Systemes • Desktop Metal • EnvisionTec • EOS 3D Printing Market: Industry Trends and Global Forecasts, Till 2035: Distribution by Type of Offering (Printers, Materials, Software and Services), by Type of Printer (Desktop 3D Printer and Industrial 3D Printer), by Type of Connectivity (Networked / Cloud-Connected 3D Printers and Standalone 3D Printers), by Type of Automation (Automated 3D Printing Systems and Manual 3D Printing Systems), by Printing Orientation (Horizontal 3D Printing, Vertical 3D Printing and Angled 3D Printing), by Technology (Stereolithography, Fused Deposition Modelling, Selective Laser Sintering and Direct Metal Laser Sintering), by Type of Software. Global 3D Printing Market Statistical Analysis The report also covers a detailed discussion of various market segments and competitive scenarios, such as policy implementation and regulatory standards across the industry. Our robust team of research analysts utilized standardized analytical tools such as SWOT analysis and Porter's Five Forces analysis to provide a brief overview of the fundamental growth trends and projected growth rate during the forecast period. Key Geographical Region Segmentation: Our report provides comprehensive details on the regional dynamics, growth scenarios, and future trends that will drive the market during the projected period. The key regional segments that have been highlighted in the market report are mentioned below. ⬝ North America ⬝ Latin America ⬝ Europe ⬝ Middle East & Africa ⬝ Asia Pacific ⬝ Rest of the World To know more about the report, visit https://www.rootsanalysis.com/3d-printing-market Report Highlights: ⬝ In addition to in-depth prediction of the global 3D Printing market, business sphere, and its core operations, the recent report offers detailed information on industrial chain analysis as well as current and future market trends to make strategic investments. ⬝ Our market study report provides brief information about current and historical market scenarios for the business vendors that help them in the evaluation of future market conditions over the next decade. ⬝ The report deeply examines the prominent factors that may influence the market growth during the upcoming years. ⬝ The market report provides knowledge about the new entrants and established players along with their business expansion plans that provide the reader an outlook on the competitive edge. Thank you for reading our report. If you have any requests for customization of the latest report, kindly get in touch with us. Our team will assist you and ensure the report is designed to meet your requirements.

1 0

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