- Bird-users - Mailing Lists

[RFC] BMP: Loc-RIB, statistics reports and Adj-RIB-Out for BIRD 3
by taichi aoki 23 Oct '26

23 Oct '26

Hello, I would like to extend BMP in BIRD 3 and I am writing before starting the work, following the "upfront consultation" advice in CONTRIBUTING.md and Maria's reply to Matthieu Gouel in January [1]. Why: today I monitor my routers by polling "show protocols all" over the control socket every 60 seconds. Every poll costs the daemon CPU, and what I get is a snapshot: a session that flaps between two polls, or a route that changes and changes back, is invisible, and anything I do see is up to a minute late. For route-level questions (what is actually in the table, what was dropped by RPKI or other filters, when did it change) I would need "show route" dumps, which do not scale. BMP already pushes Peer Up/Down and Adj-RIB-In pre/post-policy to my own collector; what I miss is: - Loc-RIB monitoring (RFC 9069): the selected routes of the BIRD tables I choose to monitor, including non-BGP ones, as a stream instead of table dumps. - Statistics Reports (RFC 7854 4.8, RFC 8671): periodic reports of the route counters BIRD already keeps, where they map to defined stat types, so most of my CLI polling can stop. - Adj-RIB-Out (RFC 8671): what we announce to each peer, to verify export policy (RPKI invalids, leaks) from the collector. This is the one I need least; it is on the list because others asked for it here [3] and I would rather align with your TX plans than leave it out. To avoid confusion: the current "post-policy" monitoring is Adj-RIB-In after import filters (L flag). Loc-RIB (peer type 3) and Adj-RIB-Out (O flag) do not exist in BIRD today. How I would do it in thread-next, please correct me where I am wrong: 1. Loc-RIB. BIRD has no BGP Loc-RIB as such: a table is shared by all protocols and its best route is chosen by preference, not only by the BGP decision process. I would map one configured BIRD table to one Loc-RIB instance peer: channels on protocol bmp, one rt_export_subscribe of best routes per table through the existing bmp_add_table path, the table name in the VRF/Table Name TLV, the F flag when the channel has an export filter, and the local AS and BGP ID of the per-peer header taken from the bmp protocol configuration and the router id. Mandatory BGP attributes synthesized for non-BGP routes, which RFC 9069 explicitly allows in a Loc-RIB. Does this mapping match how you would present BIRD tables as Loc-RIBs? 2. Peer state. Whatever BMP needs beyond the current ea_bgp_* attributes (counters for statistics, VRF/RD for the RD Instance peer type and distinguisher, FSM event code for Peer Down) published by BGP in proto_state and read by BMP. I would like to agree on the attribute set before coding. 3. Statistics. A timer in BMP. The counters live in the BGP channel import and export stats on BGP's side, and they must not turn into a journal item per route update. Either BGP publishes a snapshot into proto_state on its own timer while some BMP instance wants statistics, or the counters become atomics that BMP's timer reads. I lean to the first; which fits your locking rules better? 4. Adj-RIB-Out, post-policy only; pre-policy Adj-RIB-Out is out of scope. bgp_ptx already exposes a struct rt_exporter as c->c.out_table with feed_net implemented, but there is no live journal push yet ("TODO: actually implement exports" in bgp_free_pending_tx). I would push on prefix add/withdraw in the ptx path, only when the exporter has subscribers, and let BMP subscribe out_table the same way it subscribes import tables today. Is this the merging of the BMP TX with the BGP TX data structures you mentioned in [1], and is anyone already working on it? This is the only hot-path change; the push sits behind a "has subscribers" check, documentation will say it needs export table and what it costs, and I will measure and post numbers. Its initial dump is one table per peer, so it depends on item 6. 5. Tests. I could not find BMP cases in bird-tools netlab master. I would write them (BIRD to collector: Peer Up, route monitoring pre/post/out, End-of-RIB after the initial dump, Loc-RIB, statistics). David mentioned a BMP lab test case in April [2]; if that exists somewhere I would rather build on it. 6. Initial dump pacing. bmp_check_routes walks the whole feed in one event run and nothing is written to the socket until it returns, so the entire Adj-RIB-In dump (one message per route, roughly 130 bytes each, times pre/post) sits in TX buffers before the first byte goes out. Above "tx buffer limit" the session is declared stalled and reconnected, which starts the same dump again; with a table larger than the limit this loops forever, logging "Connection stalled" each time. I would break out of the walk after N routes or when the TX backlog passes a high-water mark derived from the limit, reschedule the event and let the socket drain in between. The stall at the hard limit stays for a collector that really does not read. Two questions: do you prefer this local to BMP, or implemented generically as rt_export_retry_later (which is declared but not defined)? And a paused reader keeps journal items of the table alive; is there a bound you want on that lag? This one is independent of the rest and I can send it first as a standalone patch. Questions: - Is this direction acceptable for thread-next? What would you do differently? - Patch order I have in mind: dump pacing (6), BGP state attributes, Loc-RIB, statistics, per-peer header, Adj-RIB-Out, docs, tests. Adj-RIB-Out can also be a separate round later if you prefer. - Does any of this collide with your unpublished plans for BGP TX or BMP? [1] https://bird.network.cz/pipermail/bird-users/2026-January/018591.html [2] https://trubka.network.cz/archives/list/bird-users@network.cz/thread/YA4I3I… [3] https://bird.network.cz/pipermail/bird-users/2026-January/018589.html Thanks, Taichi Aoki

1 0

Use-after-free in OSPF with BFD on
by Pouria Mousavizadeh Tehrani 22 Oct '26

22 Oct '26

Hi, I found a use-after-free in OSPF with BFD on, which crashes BIRD 3.4.0 on FreeBSD. In ospf_neighbor_new(), we allocate the ospf_neighbor structure from a child pool, and ospf_neigh_down() frees it with rp_free(). The problem is, if that neighbor relies on BFD, ospf_neigh_update_bfd() later adds the BFD reference to the same pool, and the request's notify points at n->bfd_notify, which is embedded in the neighbor. Since the pool frees resources in allocation order, when the neighbor goes to NEIGHBOR_DOWN, the neighbor is freed first, and then bfd_request_ref_free() cancels a callback inside freed memory. The same happens when OSPF shuts down with neighbors up. To reproduce: MALLOC_CONF=junk:true, two routers with OSPF ptp and bfd on, kill one, and the other dies in seconds. I first tried to allocate the ospf_neighbor from the protocol pool itself and free it at the end of neighbor down, and that fixed it: https://github.com/spmzt/bird/commit/0de65adf9676750d58f5e83ef5be4db7ed811c… But it looks wrong to treat OSPF specially. The main problem is the order, we free the hooks of a pool and its memory in the same loop. So I tried to free all the hooks first before freeing the pool data: https://github.com/spmzt/bird/commit/09e859086fa82ae1f4142ef8d027c733dbb899… I think the second one is the correct fix, but I’ll leave it to you to decide. I also found another bug: a configure that turns bfd on for an OSPF interface with a neighbor up aborts with "Trying to lock in a bad order" (ospf_iface_reconfigure -> bfd_request_session -> do_lock). -- Pouria

1 0

[PATCH v2 0/2] Improved improvements to RAdv
by LEdoian 22 Oct '26

22 Oct '26

Hello, I'm sending a second version of my patch, after discussing the first version in person. I'll use this space to elaborate on the thoughts I have about my changes that I omitted from the first version. Again the commits are available on <https://gitea.ledoian.cz/LEdoian/bird> on branch `ledo-patch-v2`. The first commit is still the same, I'm sending it again just for completeness. For the second commit, I tried to keep the changes minimal, and we agreed to forbid declaring the `default prefix` options after any prefix is already configured, to keep the declarative feel of the config. I still feel somewhat uncertain about the particular wording of `default prefix {}`: I tried to avoid using the word `default` in a place where a prefix could be in order to not mistake this for the ::/0 prefix which behaves differently, but now it's quite similar to `default preference` and `default lifetime`, which are a different kinds of default. Also I'm not sure if I'm sticking to conventions and idiosyncrasies of BIRD, e.g. the defaults are now defined in `config.Y`. I was also thinking about whether it would make sense to control prefix options with attributes and/or filters and while I see some utility in that (mostly slow discontinuation of prefixes), I'm not sure that's what BIRD's task should be. There are also use cases that are possible only with configurations that feel unclean (when a prefix is not static, the only way is to match it against something very general like ::/0 or 2000::/3), but I'm not sure if it causes any problems that actually occur (e.g. it is not at the moment possible to only enable autoconfiguration when the dynamic prefix's length is in some pre-defined range, but does anyone actually need that?) As before, I'd appreciate guidance/tips about what would be a good way to write test for my contribution, as all evidence of it working has only been anecdotal so far. Best, LEdoian LEdoian (2): Docs: Add note about when RAdv keeps prefix RAdv: Make default prefix options configurable doc/bird.sgml | 15 ++++++++++++++- proto/radv/config.Y | 27 ++++++++++++++++++++++----- proto/radv/radv.c | 14 ++++++-------- proto/radv/radv.h | 1 + 4 files changed, 43 insertions(+), 14 deletions(-) -- 2.55.0

1 2

Re: Assertion '!new || rte_is_valid(new)' failed at nest/rt-table.c:1562
by Benoit Chesneau 20 Oct '26

20 Oct '26

Hello, Another instance of this assertion, on FreeBSD, with the same three conditions Danylo described (keep filtered, recursive next hop, change of the resolving route). It also confirms that removing "import keep filtered" makes it go away. Environment - FreeBSD 15.1-RELEASE-p5 amd64, GENERIC kernel - bird3-3.3.2_1 from the FreeBSD quarterly packages (ports commit 46cf3d9696491c61d91ecd22db11c7f7c1e62c24, built 2026-10-18) - edge router of AS209823: about 180 BGP sessions (two transits with full tables, IX peers and route servers at DE-CIX, ERA-IX, LocIX) 1.09M IPv4 and 253k IPv6 routes in the kernel - "import keep filtered" on about 130 eBGP channels - two iBGP sessions to route reflectors on loopback addresses (multihop, next hops resolved through OSPF) - default thread count. Tried once with Thread set to 8 Log : - 2026-10-18 21:33 UTC, bird3 3.4.0 (FreeBSD "latest" packages): Assertion '!new || rte_is_valid(new)' failed at nest/rt-table.c:1562 - 2026-10-19 07:18 UTC, 3.4.0 with "threads 8;": Assertion 'MSL_GET_STATE(ph) == slh_partial' failed at lib/mslab.c:789 - 2026-10-19 11:50 UTC: downgraded to 3.3.2, same config - 2026-10-19 11:55 to 2026-10-20 09:47 UTC: 15 aborts of 3.3.2, all on nest/rt-table.c:1562, SIGABRT, core dumped each time. The interval went down to 5 minutes at the end. Every abort lines up with an OSPF change of the route to one of the two route reflector loopbacks (a reflector was moved from a bhyve VM to a jail, then another router and its reflector were rebooted several times during an upgrade). Nothing else changed on the machine between aborts. A small route reflector (same 3.3.2 package, no keep filtered, no multihop) on the same host never aborted. To fix it, I removed every "import keep filtered" line and reconfigured. Since then the same triggers happened three more times (reflector loopback routes appearing and disappearing, a reboot of the neighbouring router) with no abort. Same change applied on two other edges running 3.3.1 and 3.3.2. Notes - The FreeBSD package binary is stripped, so gdb on the cores only shows a worker thread calling abort() . - With 3.3.2 only rt-table.c:1562 fired; the mslab.c:789 one was seen once, on 3.4.0 with 8 threads. Hope it helps, Benoit Chesneau AS209823 Benoît Chesneau - Enki multimedia t. +33608655490

2 1

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

BIRD 2.19.3/2.20.0: recursive NEXT_HOP loss does not withdraw ordinary eBGP advertisement
by goodmandqp＠gmail.com 20 Oct '26

20 Oct '26

Bug description After an installed IPv4 BGP route loses its only recursive NEXT_HOP resolver, BIRD 2.19.3 and 2.20.0 mark the route unreachable but continue advertising it to an ordinary eBGP neighbor. In three isolated ordinary forwarding runs on 2.19.3 and one on 2.20.0, the neighbor kept a unicast route via the DUT while the DUT returned ICMP host-unreachable for that destination. The DUT sent another announcement, rather than a withdrawal, after resolver removal. This is an ordinary forwarding router: no route reflector, route server, graceful restart, deliberate discard policy, or policy to announce routes independently of forwarding. A reachable control prefix and both BGP sessions remain healthy. This may be a concrete instance of the recursive-route behavior discussed in 2013 and 2019; I am not claiming a newly introduced regression or an issue unknown to the project. Software version Tested source and executed binary identities: - BIRD 2.19.3: source 5c6376d3075a58d1d378f6d6a7fd50fc0750a72a; binary SHA256 302cdf17722d7601a15aa06d821c8cb92e5b309324a56d19021394e78f2e9793. - BIRD 2.20.0: source 0355729c3a546c910e20bcde423bf36da901f8b5; binary SHA256 f644d09d8a7fa781417394142ecf898bccf146f1c350d339ca7e9d44f9daf91a. Both were built without source patches, using --disable-client --without-libssh --disable-lto and CFLAGS='-O1 -g0'. The nine implicated next-hop, selection and export functions are identical in the two fixed sources. BIRD 3.x and development master have not been tested. The side-by-side validation used openEuler 24.03, Linux x86_64 / WSL2 kernel 6.18.54.1-microsoft-standard-WSL2. The earlier 2.19.3 build log records an older build kernel; it is not used as evidence of the runtime kernel. An additional 2.19.3 ordinary run was completed after recording the current environment. Dependencies: Python 3.11.6, iproute2 6.6.0, util-linux 2.39.1, coreutils 9.4, tcpdump 4.99.4 / libpcap 1.10.4, tshark 4.4.16, iputils 20221126, GCC 12.3.1 (openEuler 38). How to reproduce Dependencies: Linux root with network/mount namespace support, Python 3 standard library, iproute2, util-linux (unshare/nsenter), coreutils timeout, systemd (for the resource-limited command below), tcpdump, tshark, iputils ping, and a BIRD binary built from the stated source. The program uses BIRD's Unix control socket directly; birdc is needed only for the optional manual commands below. It does not import any private test framework or corpus. The attached standalone-next-hop-loss.py is the exact source executed in all six complete runs (four ordinary and two guard controls). Its SHA256 is 6c3bdf292b29ddc8238cccc97e456c19170e0a69ab450c41000fd70981500009. Place it in a short absolute directory, for example /tmp/bird-nh, and create the output directory there. Choose a fresh output location; Unix control-socket paths must remain below 104 bytes. Example invocation: BIRD=/absolute/path/to/bird PROGRAM=/tmp/bird-nh/standalone-next-hop-loss.py OUT=/tmp/bird-nh/out mkdir -p "$OUT" BIRD_SHA=$(sha256sum "$BIRD" | cut -d ' ' -f 1) sudo systemd-run --collect --wait --pipe \ -p CPUQuota=50% -p MemoryMax=256M -p MemorySwapMax=0 -p TasksMax=32 \ timeout --signal=TERM 180 unshare --net --mount --fork \ python3 "$PROGRAM" --bird "$BIRD" --output-root "$OUT" \ --expected-binary-sha256 "$BIRD_SHA" The binary hash argument binds the executable you supplied; compare its version/source separately. A different locally compiled binary is expected to have a different hash. Run the same command with --guard appended for the configuration control. Inspect standalone-result.json: all_gates must be true, error must be null, and cleanup.json must confirm that all owned processes exited. A successful process exit alone is insufficient. The complete sequence is as follows; the attachment also contains the exact ordinary/guard configurations used, so the sequence can be reproduced manually without the Python driver: 1. Create an isolated outer network namespace and three new child namespaces, with no default routes or external interfaces. Use distinct namespace/process identities and record them for cleanup. Create two veth links: source bc_peer=192.0.2.2/24 to DUT bc_dut=192.0.2.1/24, and DUT bc_out=192.0.3.1/24 to observer bc_observer=192.0.3.2/24. Bring the links and each loopback up. On the source, add 198.18.253.1/32 to loopback and create up dummy interfaces bc_target=198.51.155.1/24 and bc_control=198.18.250.1/24. Add source return route 192.0.3.0/24 via 192.0.2.1. Enable IPv4 forwarding only in the DUT namespace. 2. Start one BIRD process in each child namespace with its own config, pid file and Unix control socket (bird -f -c CONFIG -s SOCKET -P PIDFILE). Use the attached baseline configs. Source and DUT use AS65001; observer uses AS65003. Router IDs are 10.0.0.2, 10.0.0.1 and 10.0.0.3 respectively. All sessions are direct, with hold time 30 and keepalive time 10; GR/LLGR are off. The DUT's iBGP input has gateway recursive, igp table bc_igp and import table off. bc_igp contains the two connected subnets and static protocol bc_resolver's route 198.18.253.1/32 via 192.0.2.2. Its eBGP output accepts BGP-learned routes. Both DUT and observer export to their own namespace's kernel FIB. Initially the source advertises only control 198.18.250.0/24. 3. Wait for both sessions to be Established and control routes to be unicast. Verify target 198.51.155.0/24 is absent from DUT and observer. Start full-snaplen captures on both DUT links and wait until tcpdump reports readiness. Change only the source config to the attached peer-announced.conf and issue configure. This adds the connected target route and sets its BGP NEXT_HOP to 198.18.253.1. Wait for DUT and observer target routes to become unicast. From the observer, send two pings each to 198.51.155.1 and 198.18.250.1; both must receive two replies. Save routes, kernel FIB and captures. 4. Without changing the source advertisement, either peer, interfaces or BGP policy, issue disable bc_resolver on the DUT's control socket. For example, use birdc -s DUT_SOCKET 'disable bc_resolver'. Confirm that show route for 198.18.253.1 table bc_igp all reports no match. For at least 35 seconds, keep capturing both links and sample show protocols all, show route 198.51.155.0/24 all, show route export bc_out all, and each namespace's ip -j route show. The source must send no target announcement/withdrawal, both-direction keepalives must continue, and there must be no SYN, FIN, RST or NOTIFICATION. Send the target/control pings again. Verify captures report zero kernel drops. 5. Issue enable bc_resolver. Require target route and successful target/control pings to recover without restarting BGP or sending a new source target UPDATE. Then restore the source baseline config, issue configure, observe the actual source withdrawal and target absence on both receivers. Restart the three owned BIRD processes with baseline configs and verify fresh Established sessions, healthy control and target absence. Stop owned captures/processes and remove only the namespaces/resources created for this reproduction. The program performs this cleanup even after an error and leaves all evidence files in OUT. 6. Repeat from a fresh setup with the sole DUT export-policy change: insert `if dest = RTD_UNREACHABLE then reject;` before `if source = RTS_BGP then accept;`. This is the --guard control. It should withdraw the target after resolver loss and announce it again on recovery. This is a diagnostic workaround, not a proposed blanket policy for route servers or deliberate discard routes. Expected behavior For this forwarding-router deployment, losing the only resolver should make the learned route ineligible for ordinary dissemination and cause withdrawal from the observer; resolution recovery should make it eligible again without requiring another source UPDATE. Keeping an internal candidate for recovery is compatible with this expectation. This follows RFC 4271 sections 9.1.2, 9.1.2.1 and 9.1.3: eligibility depends on next-hop resolvability, and a previously advertised route that is no longer eligible must be withdrawn. Section 9.1.3's exception for policy that intentionally advertises independently of forwarding does not describe this fixture. All 21 listed RFC errata were reviewed; none changes these requirements. No assertion here depends on the formatting or star marker of BIRD's internal route display. https://www.rfc-editor.org/rfc/rfc4271.html#section-9.1.3 https://errata.rfc-editor.org/search/?rfc_number=4271&presentation=records Actual behavior All three ordinary 2.19.3 runs and the ordinary 2.20.0 run passed all 111 prerequisite/control/cleanup checks. After resolver loss the DUT had an unreachable target route, its kernel held an unreachable route, and the observer retained a unicast target via 192.0.3.1. The loss capture contained one DUT target reannouncement and zero target withdrawals in each run. The measured loss observation windows were 37.0 to 42.1 seconds (the program schedules seven five-second waits plus observations). Baseline and recovery target pings each returned 2/2 replies; during loss the DUT returned host-unreachable while control pings still returned 2/2. The source input and BGP sessions stayed unchanged. One guard run on each version also passed all 111 checks. During loss it contained one target withdrawal and no target reannouncement; the observer removed the target. Resolution recovery restored the route and successful pings. In each ordinary run, the abnormal result is continued route advertisement toward a router that cannot forward it; failure of a target ping after intentionally removing the only resolver is not, by itself, the bug. No alternate-path failover, forwarding loop or unrelated destination failure is claimed. Additional information The attachment contains the exact standalone program, role configs, and raw captures, route/FIB snapshots, ping outputs, config hashes and cleanup records for the ordinary/guard 2.20.0 pair. The six-run audit identifies every run; the attached raw records cover the ordinary/guard 2.20.0 pair. Two earlier standalone setup failures (unsupported version-option spelling and an overlong Unix-socket path) are retained separately and are not counted as DUT failures. The final attached source is the corrected, unchanged source that completed all six runs. The attached ZIP is self-contained: no access to our evidence repository is required. It includes the exact executable source, role configurations, six-run audit, recovery-wire audit and the raw ordinary/guard 2.20.0 evidence pair. The source hash above identifies the program actually run. Related design discussions: https://bird.network.cz/pipermail/bird-users/2013-January/008045.html https://bird.network.cz/pipermail/bird-users/2019-April/013331.html They discuss retaining recursive BGP candidates and limiting propagation of invalid routes. The present report supplies a small ordinary-router forwarding reproduction, rather than asserting that the architectural issue is new. The documented limitation with import table on is avoided by explicitly using import table off. This is also distinct from choosing among multiple IGP resolver routes: the fixture removes its sole matching resolver. Code location and suggested fix The following chain is read from the exact 2.19.3 source identified above. Source statements are verified; the correspondence with the observed execution is an inference supported by the independent captures and guard control. I did not instrument native callback entry/exit or test a C patch. 1. proto/bgp/packets.c, bgp_apply_next_hop() (around 1101): recursive input obtains a hostentry and applies it to the route attributes. 2. nest/rt-table.c, rt_update_hostentry() (3664), rt_update_hostcache() and rta_apply_hostentry() (2554): removing the last IGP match resets the hostentry to RTD_UNREACHABLE; dependent routes receive that destination and lose their forwarding nexthop. 3. nest/rt-table.c, rt_next_hop_update_net() (2833): the retained route participates in best-route recomputation and export notification. proto/bgp/attrs.c, bgp_rte_better() (2165), favors reachable alternatives but does not exclude the sole unreachable candidate. 4. proto/bgp/attrs.c, bgp_preexport() (1880), specifically rejects unreachable FlowSpec, but has no corresponding failed-recursion eligibility gate for this ordinary IPv4 BGP route. The configured RTS_BGP export filter accepts it. 5. proto/bgp/packets.c, bgp_use_next_hop(), bgp_use_gateway() and bgp_update_next_hop_ip() (1211, 1252, 1283): on this different-interface ordinary eBGP output, the unusable forwarding gateway is not used and NEXT_HOP becomes the DUT's channel address. This matches the captured reannouncement to the observer. Source links: https://gitlab.nic.cz/labs/bird/-/blob/5c6376d3075a58d1d378f6d6a7fd50fc0750… https://gitlab.nic.cz/labs/bird/-/blob/5c6376d3075a58d1d378f6d6a7fd50fc0750… https://gitlab.nic.cz/labs/bird/-/blob/5c6376d3075a58d1d378f6d6a7fd50fc0750… Suggested correction: separate retained recursive-candidate state from eligibility for ordinary forwarding-router export. In or before bgp_preexport(), reject a BGP-learned unicast-family candidate whose recursive hostentry is unresolved before NEXT_HOP rewriting makes it appear usable to the receiver; hostcache changes must still trigger withdrawal and subsequent re-advertisement when resolution returns. A useful discriminator to review is non-null attrs->hostentry combined with RTD_UNREACHABLE, rather than rejecting every unreachable destination. The exact ordinary-router applicability/opt-out contract should be explicit so intentional non-forwarding route-server/reflector deployments retain their supported behavior. In filter/f-inst.c, SA_DEST deliberately clears hostentry when setting blackhole/unreachable/prohibit. That distinction should be preserved; likewise, keep the retained candidate needed for recovery. Do not turn the observed kernel unreachable entry alone into a blanket request to remove defensive discard routes. Suggested regressions: initial reachable route, resolver-only loss, captured withdrawal, resolver-only recovery, usable alternate BGP candidate, explicit discard policy, and intended RR/RS exceptions. IPv6 and MP variants need separate tests. No source patch has been written, compiled or executed; only the stated export-filter diagnostic was tested. Checklist - Exact binary/source identity and complete independent program retained; the attached source hash matches all six executed-source copies. - Three ordinary 2.19.3 runs, one ordinary 2.20.0 run and one guard per version completed with explicit recovery and cleanup. - Original announcement, unchanged source/session controls, actual egress UPDATEs and independent ICMP evidence verified. - RFC applicability, listed errata, documented import-table limitation and related historical discussions reviewed. - Full written sequence, role configs, dependencies and executable program provided; no private framework required. - Source mechanism, inference, configuration workaround and untested source-code proposal are distinguished. - No native callback instrumentation or source patch was executed; the export-filter control is a tested diagnostic workaround only.

2 1

Reviving an old patch (babel)
by Yifei Sun 19 Oct '26

19 Oct '26

Hello, I'm curious if this old patch "allow enabling link quality estimation manually" (from 2023) could be reviewed again? Archive: https://trubka.network.cz/archives/list/bird-users@network.cz/thread/UZGFL5… Original author's latest rebased patch: https://github.com/NickCao/bird/commit/a1fa200ab8a7bb9da2b1593b4347ae472f5d… There's also another unsubmitted patch related to vrf interface delete race condition: https://github.com/NickCao/bird/commit/95dfb71dbf65a0d07308081a9ff773d50f8a… Thanks a lot! Best, Yifei

1 0

Kernel: krt_shutdown() calls tm_stop() on a NULL scan_timer when krt_start() failed (3.3.3, 3.4.0, thread-next; same code in 2.20.0)
by Hendrik Visage 18 Oct '26

18 Oct '26

Good day, While setting up (using Claude’ assistance) an internal PrivateASN “client” setup, we hit some snags on kernel protocols, but also some crashes. See the report from Claude about the crashes. Any better formats to report the analysis on this group? ## Summary of report. A kernel protocol whose krt_sys_start() fails ("Kernel table N already registered by X") stays in PS_START with p->scan_timer == NULL. Any later shutdown of that protocol (reconfiguration that restarts or removes it, `disable`, SIGTERM, graceful restart) runs krt_shutdown() -> krt_scan_timer_stop() -> tm_stop(NULL) and the daemon segfaults. Reproducible unprivileged with a 12-line config on 3.3.3 and 3.4.0. It took down two production routers on 2026-10-14 (once on `configure`, once on SIGTERM, after the SIGTERM path had already withdrawn all routes). ## Versions - bird3 3.3.3-cznic.1~trixie and 3.4.0-cznic.1~trixie (pkg.labs.nic.cz), Linux 7.0, Devuan. - Code involved is identical in v3.3.3, v3.4.0 and thread-next dcf094d3f (2026-10-12). - master (2.20.0): krt_shutdown() has the same order (krt_scan_timer_stop() before the PS_START check) and krt_start() the same early return; tm_stop() in lib/timer.c also reads t->expires first. Not tested there. ## Reproducer a.conf: log stderr all; router id 192.0.2.1; ipv4 table t2; protocol device { } protocol kernel k1 { kernel table 254; ipv4 { table master4; import none; export none; }; } protocol kernel k2 { kernel table 254; metric 10; ipv4 { table t2; import none; export all; }; } b.conf = a.conf with k2 changed to `kernel table 101;` (no metric). cp a.conf run.conf unshare -rn sleep 60 & NSP=$! nsenter -t $NSP -U -n --preserve-credentials --wd=$PWD ip link set lo up nsenter -t $NSP -U -n --preserve-credentials --wd=$PWD bird -f -c run.conf -s ctl -P pid & nsenter -t $NSP -U -n --preserve-credentials --wd=$PWD birdc -s ctl show protocols cp b.conf run.conf nsenter -t $NSP -U -n --preserve-credentials --wd=$PWD birdc -s ctl configure `bird -p` accepts a.conf. At start: <ERR> k2: Kernel table 254 already registered by k1 `show protocols` shows k2 in state `start`. The `configure` logs <INFO> Reconfiguring <INFO> Restarting protocol k2 and birdc reports "Connection closed by server"; bird is gone (SIGSEGV). `birdc -s ctl disable k2` instead of the configure gives the same result. | version | configure (table 254 -> 101) | disable k2 | |---|---|---| | 3.3.3-cznic.1 | SIGSEGV | SIGSEGV | | 3.4.0-cznic.1 | SIGSEGV | SIGSEGV | ## Observed in production (3.3.3, two routers, 2026-10-14) Router A, `birdc configure` moving the stuck protocol to its own kernel table: 22:52:13 bird: Reconfiguring 22:52:13 bird: Restarting protocol kuls4 22:52:13 kernel: bird[1814]: segfault at 30 ip 0000555b82c5d994 sp 00007ffdf1b62828 error 4 in bird[72994,555b82c00000+116000] Router B, SIGTERM (init script restart) with the same stuck protocol still present: 23:37:49 bird: Shutting down 23:38:14 kernel: bird[1648]: segfault at 30 ip 0000559ad06c7994 sp 00007ffd3ea32008 error 4 in bird[72994,559ad066a000+116000] Same text offset 0x72994 both times. With bird3-dbgsym 3.3.3-cznic.1, addr2line resolves it to tm_stop() lib/timer.c:133 (`if (!t->expires)`). Consistent with the fault address: struct timer = resource (32 bytes) + hook (8) + data (8), so `expires` is at offset 0x30 of a NULL timer. Both faults are on the main-thread stack (sp 0x7ffd...). On router B the 25 s between "Shutting down" and the fault were the regular shutdown withdrawing ~1M kernel routes and ~100 BGP sessions on the main loop; the crash came when the stuck protocol's turn came. ## Analysis (3.3.3 line numbers) 1. sysdep/linux/netlink.c:2798 krt_sys_start(): HASH_FIND(nl_table_map, af, table id) finds the other kernel protocol, logs "Kernel table %u already registered by %s" and returns 0. `metric` is not part of the key. 2. sysdep/unix/krt.c:946 krt_start(): line 969 `if (!krt_sys_start(p)) { rem_node(&p->krt_node); return PS_START; }` runs before line 975 krt_scan_timer_start(p). p->scan_timer is only ever created inside krt_scan_timer_start() (tm_new_init), so it stays NULL. The protocol remains in PS_START; nothing else happens, it ran 34 min like that. 3. sysdep/unix/krt.c:984 krt_shutdown(): line 988 krt_scan_timer_stop(p) is the first statement. krt.c:690 krt_scan_timer_stop() calls tm_stop(p->scan_timer) with NULL; lib/timer.c:133 reads t->expires. The guard `if (p->p.proto_state == PS_START) return PS_FLUSH;` is at line 990, after the call. 4. On hosts where strict netlink dumps are unavailable (krt_use_shared_scan(), krt_scan_all_tables = 1) the same statement takes the other branch: krt_scan_all_timer_stop() with ASSERT(krt_scan_all_count > 0) and a decrement that this protocol never matched with an increment. Not tested. Every shutdown path reaches krt_shutdown(): protocol restart or removal on reconfigure, `disable`, SIGTERM, and `graceful restart` (PDC_CMD_GR_DOWN is only consulted after the timer stop). Once a kernel protocol is in this state there is no way to end it without the fault. ## Tested change Moving the PS_START check above the timer stop (krt-shutdown.patch, against the 3.3.3 release tarball): --- sysdep/unix/krt.c.orig +++ sysdep/unix/krt.c @@ -985,11 +985,11 @@ { struct krt_proto *p = (struct krt_proto *) P; - krt_scan_timer_stop(p); - if (p->p.proto_state == PS_START) return PS_FLUSH; + krt_scan_timer_stop(p); + /* FIXME we should flush routes even when persist during reconfiguration */ if ((p->sync_state != KPS_INIT) && !KRT_CF->persist && (P->down_code != PDC_CMD_GR_DOWN)) { With it, the reproducer survives both cases: after `configure` k2 comes up on table 101; after `disable` k2 is down and the daemon keeps running. Two remarks on how we got there: - There is no config-time rejection of two kernel protocols on the same (af, kernel table), unlike "Kernel syncer (%s) already attached to table %s" for BIRD tables. `bird -p` passes such a config. - doc/bird.sgml (kernel `metric`): "routes with different metrics do not clash with each other, therefore using dedicated metric value is a reliable way to avoid overwriting routes from other sources". We read that as two kernel protocols on one kernel table with different metrics being supported. ## Second, separate crash on router A (not reproduced) After crash 1, router A was started fresh (22:53:54) with the conflict removed (kuls4/6 on kernel table 101, all four kernel protocols `up`). 78 s later, with no CLI activity, it segfaulted again: 22:55:12 kernel: bird[13330]: segfault at 30 ip 0000562a8033ea23 sp 00007fc85c2462c0 error 4 in bird[6ea23,562a802e5000+116000] Text offset 0x6ea23 -> mb_alloc() lib/resource.c:452, `ASSERT_DIE(DG_IS_LOCKED(p->domain))`. struct pool = resource (32 bytes) + TLIST_LIST(resource) inside (16 bytes), so `domain` is at offset 0x30: the pool pointer passed to mb_alloc() was NULL. (A NULL p->domain would fault at 0x28, the `order` field behind the 40-byte mutex in struct domain_generic.) Unlike crash 1, sp is a thread stack (0x7fc8...), i.e. a protocol or table loop, not the main loop where the kernel protocols run. State at the time: - Graceful restart recovery in progress (`graceful restart wait 120`, 112 channels waiting). Two configured BGP peers never connect (Active), so the recovery lock holds until the 120 s timer; the kernel protocols were still in KPS_LEARNING with exports not started. - ~100 BGP sessions, two with full tables still being received (last log line 1 s before the fault was an AS_SET withdrawal from one of them). - 4 RPKI sessions, Established 0-3 s after start, with `import table yes` and ROA autoreload on all BGP channels, so channel_roa_changed() was running on the BGP loops during recovery (that function allocates from c->proto->pool). - 4 kernel protocols on kernel tables 254, 100, 101; 3 pipes; 1 BMP. I could not find what called mb_alloc() with a NULL pool: no core dump (the daemon is not dumpable on that host), no backtrace. nest/proto.c sets p->pool only in proto_start() (line 1690) and clears it after PS_DOWN_XX (line 2884). The June 2026 ROA-autoreload / reload-during-GR fixes (24194edaa, 7a7ebdcc0, 0f5e8e988, b18793719 on stable-v3.3) are in 3.3.3. The only correlation I have: this configuration (the extra kernel protocol on table 101, its BIRD table and pipe) was running for the first time. The same configuration without that kernel protocol (table, pipe and BGP sessions kept) has been stable on both routers since, through several restarts and reconfigurations. The 12-line reproducer above does not cover this case (no BGP, RPKI or graceful restart). I can arrange a core dump for a future occurrence if useful. --- Hendrik Visage Director/Owner HeViS.Co Systems t/a Envisage Cloud Solutions hvisage(a)hevis.co.za GSM/SMS/Signal: +27-84-612-5345 InstantMessenger: https://t.me/hvisage

1 0

How to filter prefixes in radv protocol
by Arnaud Gomes-do-Vale 18 Oct '26

18 Oct '26

Hi, I have a Linux machine (Devuan excalibur running in a LXC container if this matters) with the following IPv6 configuration: 2: eth0@if18: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000 link-netnsid 0 inet6 2001:910:1320::1/128 scope global valid_lft forever preferred_lft forever inet6 2001:910:1320::252/64 scope global valid_lft forever preferred_lft forever inet6 fe80::1:c0ff:fe04:243/64 scope link proto kernel_ll valid_lft forever preferred_lft forever 5: net6@if21: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000 link-netnsid 0 inet6 2001:910:1320:6::1/64 scope global valid_lft forever preferred_lft forever inet6 fe80::2e:e2ff:fe18:2a46/64 scope link proto kernel_ll valid_lft forever preferred_lft forever This machine is running BIRD with a radv protocol set up as follows: protocol radv { interface "eth0" { prefix 2001:910:1320:0::/64 { autonomous on; }; prefix 2001:910:1320::1/128 { autonomous no; onlink no; skip yes; valid lifetime 0; preferred lifetime 0; }; min ra interval 30; max ra interval 90; solicited ra unicast; }; interface "net6" { link mtu 1420; prefix 2001:910:1320:6::/64 { autonomous on; }; solicited ra unicast; rdnss { ns 2001:910:1320:0:XXXXXXX; ns 2001:910:1320:0:YYYYYYY; }; dnssl { domain "glou.org"; }; }; } No matter what exact combination of options I pass to the radv protocol, the RAs BIRD sends on interface eth0 still advertise prefix 2001:910:1320::1/128, with both valid and preferred lifetimes set to 86400 seconds. This is not an issue in general except for NetBSD client machines which interpret this advertisment literally and grab address 2001:910:1320::1; of course this tends to cause issues on the network. Tested with BIRD 2.17.5 from up-to-date Devuan excalibur and with latest 2.20.0 package. Is there a way to prevent BIRD from advertising the /128 subnet and only have it advertise the /64, or is this a bug in BIRD? -- Arnaud

2 2

BIRD 3.3/3.4: CLI stalls and mslab cleanup CPU (3.4.0 test patches)
by Pavel Trefný 15 Oct '26

15 Oct '26

Hi BIRD developers and users, We would like to share a performance problem we encountered with BIRD 3.4.0 on Linux, our investigation, and an experimental patch series that substantially improved behaviour on our test server. We can provide the patches for review. The investigation, patches and test runs were carried out with assistance from OpenAI Codex, an AI coding agent, with us directing the experiments on our server. The measurements below come from the actual test runs. ### Symptoms and environment After moving from 3.2.4 to 3.4.0, we observed multi-second delays in basic `birdc` commands and sustained utilisation of approximately one full CPU core by the main thread. With 3.2.4, the CLI was much more responsive after convergence. This was an operational comparison, not a controlled benchmark of the two unmodified releases; startup kernel scans could also delay 3.2.4. We had also observed similar performance symptoms with the 3.3 series. The profiles, patches and quantitative measurements below are for builds based on 3.4.0; we have not profiled or tested these patches on 3.3. The server runs Linux on x86_64 with 16 logical CPUs and 12 BIRD worker threads. It has 158 BGP protocols, of which 143 were established in our baseline, and seven Kernel protocols. The Kernel channels reported approximately 3.79 million exports in aggregate. These exports span multiple tables and must not be interpreted as 3.79 million distinct prefixes. CPU affinity alone did not solve the CLI delays: the CLI still depends on the main loop, including its synchronous work. Stack sampling showed time spent in `msl_cleanup()` and synchronous Linux kernel scans through `nl_get_reply()` / `nl_get_scan()` / `krt_do_scan()`. We therefore addressed both allocator work and main-loop latency. ### Experimental changes The series applies to clean upstream 3.4.0, in this order: 1. **`0001-bounded-allocator-cleanup.patch`** Make mslab cleanup resumable, with a budget of at most 256 page heads per callback across full and partial cleanup. Partition the private full-page list into 4096 buckets and use atomic dirty bits to select buckets affected by publication or frees. This avoids repeatedly walking the entire unchanged full-page population. Collect the published partial list only when a possible empty-page transition requires it. The implementation retains the producer/consumer model and RCU grace periods before republishing partial pages. It handles frees behind a retained cursor and destruction with unfinished cleanup. Page headers and the public API remain unchanged; the extra metadata is approximately 33 KiB per mslab. The patch includes regression tests. 2. **`0002-main-loop-quota.patch`** Reduce the existing cooperative main-loop operation quota from 2048 to 128, giving other main-loop work more frequent opportunities to run during route feed/export activity. 3. **`0003-async-kernel-and-cli.patch`** Use a dedicated nonblocking netlink socket for Linux per-table route dumps. Collect and validate a complete dump before beginning refresh/prune, so an interrupted, truncated or otherwise invalid dump is discarded and retried instead of pruning against an incomplete snapshot. Receive at most eight datagrams per callback with a 10 ms time budget; apply/replay at most 64 messages per callback with the same time budget. Individual operations can still exceed the time budget. Serialize scan jobs, defer initial export until the scan completes, buffer route notifications and replay them in FIFO order, and cancel jobs during protocol shutdown. Snapshot and notification buffers are capped at 256 MiB and 8 MiB respectively, with abort/resync handling. Also remove an early `continue` in the main-loop wakeup-pipe path that skipped other ready sockets. Repeatedly rescheduled work could otherwise keep the CLI from being serviced despite its socket being ready. The CLI remains in the main loop; we did not move it to a separate thread. ### What profiling changed in our approach Our first local batching prototype introduced excessive partial-list recollection. We corrected that in an intermediate version, which we call V3. That amplification was a defect in our prototype, not a demonstrated defect in unmodified upstream 3.4.0. V3 nevertheless still consumed almost one main-thread CPU core: profiling then identified repeated full-page list walks as the dominant remaining cost. The bucket/dirty-bit approach above is our final experimental version, V4. ### Measurements on this server The quantitative baseline below is **our already modified V3**, immediately before deploying V4, not stock 3.4.0. Both versions use the asynchronous scan and quota changes. Routing policy, scan intervals and CPU affinity were unchanged between them. This is a comparison of successive live runs on one server, not a replay of identical traffic. | Version and observation window | Main-thread CPU | | --- | ---: | | V3, 60 seconds after convergence | 96.60% | | V4, first 60-second window after convergence | 23.40% | | V4, second 60-second window after convergence | 23.92% | | V4, longer window from 360 seconds after startup | 27.56% | Here, 100% means one logical CPU. CPU usage comes from the main thread's `/proc/PID/task/PID/stat`, rather than percentages inferred from profiling. Full-page cleanup accounted for 64.46% of userspace instruction-pointer samples in the immediate V3 baseline and 8.51% in the first V4 profile. These sample shares are separate from the CPU utilisation figures. During a 600-second V4 observation, all 120 CLI probes returned, with no 3-second timeouts. For the 73 probes from 360 seconds after startup, the median was 4.09 ms, p95 6.06 ms and maximum 1269.45 ms. In that later window, the whole process averaged 50.16% CPU and RSS was approximately 4.04–4.06 GiB. Export counters continued to advance. All named BGP states matched the V3 baseline and all seven Kernel protocols were up with exports READY at the final check. ### Validation and remaining limitations We built with default `./configure`; `make -j2 bird check` passed. New allocator tests cover sparse frees among 60,000 objects, bounded cleanup work, slot reuse, payload/accounting, frees behind a cursor and unfinished destruction. The sparse-work regression fails on V3 and passes on V4. A four-thread test with cross-thread frees passed, including 20 repeated runs on V4. Linux network-namespace tests passed for route ordering, cancellation, interface failure, interrupted dumps and a large case with 400,000 IPv4 plus 100,000 IPv6 routes. We checked route counts, export changes, preservation of existing routes on interrupted dumps, retry behaviour and clean shutdown. Applying the series to the official 3.4.0 archive reproduced all eight changed build-source files byte for byte. This remains experimental and the final V4 observation is short. Occasional CLI delays around 1.27 seconds remain. Netlink write ACKs, interface/FDB scans, legacy scans, shutdown and lock waits can still block. We have not established long-term stability or verified every live forwarding route end to end. An earlier prototype trial also logged two "Export flag inconsistency" messages in Kernel channels; we have not established their cause or shown that these patches resolve them. We would appreciate feedback on the allocator dirty-bucket design and RCU handling, and on the snapshot/notification ordering and cancellation approach for kernel scans. Is there an existing upstream approach we should follow? We can share the three patches, test fixtures and measurement details, or split the changes differently if that would make review easier. Best regards, Pavel Trefny PS (for Czech-speaking readers): My mu nerozumime, ale my mu verime :-)

3 2