- Bird-users - Mailing Lists

[PATCH] BGP: Add gshut command for graceful shutdown (RFC 8326)
by Andreas Scholdan 14 Oct '26

14 Oct '26

Hi, attached are two patches against master (2.20.0): a BIRD patch adding a runtime "gshut" command, and a bird-tools patch with a netlab case (cf-ebgp-gshut) plus a small command helper. This is the RFC 8326 item on the roadmap. gshut [off] <protocol> | "<pattern>" | all While active, routes exported to the selected BGP peers carry the GRACEFUL_SHUTDOWN community (65535,0). Toggling triggers a refeed and does not touch the session. The state shows in "show protocols all". For running instances it survives configuration-driven replacement, including restart and disable. Sessions spawned by a dynamic listener inherit its state; existing ones stay separately selectable. This covers the outbound signalling of RFC 8326. Import policy and the eventual session shutdown stay with the operator. The netlab case checks, as seen on the peers: community added, an existing community preserved, state kept across a restarting reconfiguration, inheritance by a newly spawned dynamic session, and removal with "gshut off". Reference data was recorded with 2.20.0 plus the patch (data-v2.20): save 28 passed, check 23 passed, 5 skipped (save-only waits). AddressSanitizer runs of the suite, of config disable followed by CLI enable, and of replacing a drained BGP instance by a same-name static one and back, were clean. One documented limitation: an instance that is already down loses the flag when replaced by reconfiguration, since that path calls no BGP hook. Two questions: 1. Would you want this covered by a small nest-level state hand-over hook, or is the documented limitation acceptable for now? 2. Is "gshut" the name you want for the command? The patches were developed with LLM assistance; I have reviewed and tested every change. Daemon commit for reference: https://github.com/Scholdan/bird/commit/b84d6a4a9ea644b4a085b06771438a26d4d… Thanks,Andreas Scholdan Med venlig hilsen / Best regards Andreas Scholdan Ebstrupvej 38 8600 Silkeborg 📞 71 75 20 03 ✉️ andreas(a)scholdan.net

1 0

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

[bug report] BFD periodic spacing below negotiated jitter minimum in BIRD 2.19.3
by qipeng ding 13 Oct '26

13 Oct '26

This is a size-compatible resubmission of the same report sent on9 October and held for exceeding the400KB list limit. The attached tar.xz contains all228 members of the previously verified ZIP, with identical member bytes. Extract it with tar -xJf bird-bfd-spacing-review-20261013.tar.xz and use the standalone program described below. The exact program and observations are unchanged; no additional defect or fresh execution is claimed. Please treat this as the replacement for the oversized held copy. Bug description BIRD 2.19.3 emits consecutive, unchanged, periodic BFD Control packets closer together than the negotiated minimum after jitter. With a 200 ms negotiated interval, sender-side gaps of 95.588 ms and 9.043 ms were captured in separate native runs. A self-contained normal-configuration program reproduced short gaps in both independently started sessions. The reported pairs are Up, have Poll=Final=0, retain the same discriminators and BFD payload, and have no intervening packet from that sender. This report concerns packet spacing, not session establishment or an alleged security impact. Software version Tested BIRD 2.19.3, source commit 5c6376d3075a58d1d378f6d6a7fd50fc0750a72a, binary SHA256 302cdf17722d7601a15aa06d821c8cb92e5b309324a56d19021394e78f2e9793. The binary was built from that checked-out source in openEuler24.03 under WSL2 on Windows. Both native endpoints use the same binary. Tests used one serial systemd unit with CPUQuota=50%, MemoryMax=256M, MemorySwapMax=0 and TasksMax=32. Source-only comparison with master commit 4e414896c39d366e99c7076f3ddc66f3dd7f65e5 shows the same relevant recurrence and BFD timer setup; that master binary was not tested. How to reproduce Requirements: Linux root, Python3, iproute2, util-linux (unshare/nsenter), tcpdump, systemd and a BIRD2.19.3 executable. Save the attached normal_bfd_interval_review.py unchanged, choose a short owned output directory so Unix socket paths fit, and run: sudo systemd-run --unit=bird-bfd-review-1 --collect --wait --pipe \ -p CPUQuota=50% -p MemoryMax=256M -p MemorySwapMax=0 \ -p TasksMax=32 timeout 180 unshare --net --mount --fork \ python3 /absolute/path/to/normal_bfd_interval_review.py \ --bird /absolute/path/to/bird --output /var/tmp/bfd-review \ --mode bfd_rx_change Run a second fresh unit with --mode bfd_tx_change. The program refuses the host network namespace, creates two owned veth-connected role namespaces (192.0.2.1/2, interfaces bc_dut/bc_peer), configures one unauthenticated asynchronous BFD session per role with minTX=minRX=200ms, idleTX=1s and multiplier3, starts passive timestamp observers and capture before BIRD, and waits for both Up. It collects25 steady Up packets, normally changes only the DUT RX or TX interval to400ms and waits for the matching native Poll/Final, collects25 packets in the affected direction, then restarts both roles with200ms and collects25 restoration packets. No fabricated packets, workload, process pause or shared-service changes are made. Inspect standalone-result.json, endpoint-timing-review.json, both passive timestamp logs and stimulus/restore.pcap. A nonzero short_intervals_beyond10ms count identifies strong short-spacing observations; program exit0 means collection completed, not protocol PASS. All processes created by the program are terminated; cleanup.json verifies their exit and only loopback remains in the outer namespace. Incidence varies with host scheduling, so a zero count in one run does not disprove the retained findings. Expected behavior RFC5880 section6.8.7 requires periodic spacing to respect max(localDesiredMinTX,remoteRequiredMinRX) less0-25% per-packet jitter: minimum150ms for200ms, or300ms for400ms. Immediate Final replies and changed-content packets are explicit exceptions and are excluded from the reported pairs. RFC7419 does not replace that safety margin. All8 RFC5880 errata were reviewed: none changes this pacing requirement. Poll/Final transition rules are checked separately under section6.8.3. Actual behavior The exact attached source (SHA256 b798462dc1892a3133c09db6b11af22328feaa8aafd06b3bb52d983068b79810) completed cleanly in two fresh isolated executions. RX-change execution captured271.856ms at400ms and99.353/131.996ms at restored200ms; TX-change execution captured110.162ms at baseline200ms,267.650ms at400ms and32.013ms at restored200ms. Each is below the corresponding jittered minimum. Earlier dual-endpoint runs captured95.588ms and9.043ms at200ms. Both normal parameter changes and matching Poll/Final were observed; short periodic spacing is a separate finding. Complete raw observations and hashes are attached. Additional information Measurements use AF_PACKET software kernel timestamps, with outgoing packet_type4 and matching incoming type0 frames at the opposite endpoint. Frame hashes and nearest timestamps bind the endpoints, and capture corroborates the DUT-side frames. They are not hardware wire timestamps. In the95.588ms example, delivery delays were44.1/47.7us and observer queues127.1/159.0us; realtime-minus-monotonic offset varied2.5us. The9.043ms example had125.9/113.8us delivery and233.4/224.6us observer queues. These variations cannot explain the shortfall. The95.588ms phase had zero additional cgroup throttle events; the9.043ms phase had four. Scheduling pressure can delay a send, but it is not evidence that a subsequent unchanged periodic packet below the minimum is permitted. RFC5880 section7's deployment cautions are acknowledged. No forwarding failure, downstream policer drop or broader-version impact was tested. Code location and suggested fix Fixed-source links: https://gitlab.nic.cz/labs/bird/-/blob/5c6376d3075a58d1d378f6d6a7fd50fc0750… (bfd_session_update_tx_interval and bfd_tx_timer_hook) and https://gitlab.nic.cz/labs/bird/-/blob/5c6376d3075a58d1d378f6d6a7fd50fc0750… (timers_fire). Fact: BFD sets recurrent=.75*T and randomize=.15*T (a legal jitter subset), while timers_fire schedules the successor from the previous expiry before calling the hook, unless that successor is already past loop->last_time. The hook then records cached current_time and calls bfd_send_ctl. An exact extracted-function model with mocked clock/heap/send callback demonstrates the consequence: an event serviced100ms late can leave a successor only50ms after its modeled send, despite a150ms recurrence. This demonstrates scheduler arithmetic, not a full BIRD execution. A likely native mechanism is deadline catch-up after late service, or preemption between rescheduling and send; actual native callback deadlines have not been traced, so that causal attribution remains a hypothesis. Suggested BFD-specific change: use a one-shot periodic timer and anchor the next jittered deadline to a fresh monotonic timestamp of actual successful periodic transmission, auditing buffered/failed sends. Preserve immediate Final/changed-content behavior, deferred Up TX increases until Final, immediate negotiated decreases, Demand/zeroRX suppression and idle/state transitions. Avoid changing every recurrent timer client without auditing its contract. Regress normal mult1/3/255 pacing, delayed callbacks, directional changes and recovery. No BIRD patch has been authored, built or validated. Checklist Fixed tested source and binary recorded; exact attached normal program executed twice in fresh isolation; complete textual steps and dependencies provided; actual native configurations, logs, captures, timestamps, sample identities and cleanup retained; RFC, all errata and relevant update applicability checked; sender/receiver and clock/queue observations separated; successful parameter negotiation distinguished from periodic-spacing anomalies; source facts, model result, native root-cause hypothesis and unverified fix design labeled explicitly; no claim about an untested patch or BIRD3 runtime. This report was prepared with AI assistance and reviewed against the cited source and actual execution evidence. On Fri, 09 Oct 2026 06:32:28 -0700, qipeng ding <goodmandqp(a)gmail.com> wrote: > Bug description > BIRD 2.19.3 emits consecutive, unchanged, periodic BFD Control packets closer together than the negotiated minimum after jitter. With a 200 ms negotiated interval, sender-side gaps of 95.588 ms and 9.043 ms were captured in separate native runs. A self-contained normal-configuration program reproduced short gaps in both independently started sessions. The reported pairs are Up, have Poll=Final=0, retain the same discriminators and BFD payload, and have no intervening packet from that sender. This report concerns packet spacing, not session establishment or an alleged security impact. > > Software version > Tested BIRD 2.19.3, source commit 5c6376d3075a58d1d378f6d6a7fd50fc0750a72a, binary SHA256 302cdf17722d7601a15aa06d821c8cb92e5b309324a56d19021394e78f2e9793. The binary was built from that checked-out source in openEuler24.03 under WSL2 on Windows. Both native endpoints use the same binary. Tests used one serial systemd unit with CPUQuota=50%, MemoryMax=256M, MemorySwapMax=0 and TasksMax=32. Source-only comparison with master commit 4e414896c39d366e99c7076f3ddc66f3dd7f65e5 shows the same relevant recurrence and BFD timer setup; that master binary was not tested. > > How to reproduce > Requirements: Linux root, Python3, iproute2, util-linux (unshare/nsenter), tcpdump, systemd and a BIRD2.19.3 executable. Save the attached normal_bfd_interval_review.py unchanged, choose a short owned output directory so Unix socket paths fit, and run: > > sudo systemd-run --unit=bird-bfd-review-1 --collect --wait --pipe \ > -p CPUQuota=50% -p MemoryMax=256M -p MemorySwapMax=0 \ > -p TasksMax=32 timeout 180 unshare --net --mount --fork \ > python3 /absolute/path/to/normal_bfd_interval_review.py \ > --bird /absolute/path/to/bird --output /var/tmp/bfd-review \ > --mode bfd_rx_change > > Run a second fresh unit with --mode bfd_tx_change. The program refuses the host network namespace, creates two owned veth-connected role namespaces (192.0.2.1/2, interfaces bc_dut/bc_peer), configures one unauthenticated asynchronous BFD session per role with minTX=minRX=200ms, idleTX=1s and multiplier3, starts passive timestamp observers and capture before BIRD, and waits for both Up. It collects25 steady Up packets, normally changes only the DUT RX or TX interval to400ms and waits for the matching native Poll/Final, collects25 packets in the affected direction, then restarts both roles with200ms and collects25 restoration packets. No fabricated packets, workload, process pause or shared-service changes are made. Inspect standalone-result.json, endpoint-timing-review.json, both passive timestamp logs and stimulus/restore.pcap. A nonzero short_intervals_beyond10ms count identifies strong short-spacing observations; program exit0 means collection completed, not protocol PASS. All processes created by the program are terminated; cleanup.json verifies their exit and only loopback remains in the outer namespace. Incidence varies with host scheduling, so a zero count in one run does not disprove the retained findings. > > Expected behavior > RFC5880 section6.8.7 requires periodic spacing to respect max(localDesiredMinTX,remoteRequiredMinRX) less0-25% per-packet jitter: minimum150ms for200ms, or300ms for400ms. Immediate Final replies and changed-content packets are explicit exceptions and are excluded from the reported pairs. RFC7419 does not replace that safety margin. All8 RFC5880 errata were reviewed: none changes this pacing requirement. Poll/Final transition rules are checked separately under section6.8.3. > > Actual behavior > The exact attached source (SHA256 b798462dc1892a3133c09db6b11af22328feaa8aafd06b3bb52d983068b79810) completed cleanly in two fresh isolated executions. RX-change execution captured271.856ms at400ms and99.353/131.996ms at restored200ms; TX-change execution captured110.162ms at baseline200ms,267.650ms at400ms and32.013ms at restored200ms. Each is below the corresponding jittered minimum. Earlier dual-endpoint runs captured95.588ms and9.043ms at200ms. Both normal parameter changes and matching Poll/Final were observed; short periodic spacing is a separate finding. Complete raw observations and hashes are attached. > > Additional information > Measurements use AF_PACKET software kernel timestamps, with outgoing packet_type4 and matching incoming type0 frames at the opposite endpoint. Frame hashes and nearest timestamps bind the endpoints, and capture corroborates the DUT-side frames. They are not hardware wire timestamps. In the95.588ms example, delivery delays were44.1/47.7us and observer queues127.1/159.0us; realtime-minus-monotonic offset varied2.5us. The9.043ms example had125.9/113.8us delivery and233.4/224.6us observer queues. These variations cannot explain the shortfall. The95.588ms phase had zero additional cgroup throttle events; the9.043ms phase had four. Scheduling pressure can delay a send, but it is not evidence that a subsequent unchanged periodic packet below the minimum is permitted. RFC5880 section7's deployment cautions are acknowledged. No forwarding failure, downstream policer drop or broader-version impact was tested. > > Code location and suggested fix > Fixed-source links: https://gitlab.nic.cz/labs/bird/-/blob/5c6376d3075a58d1d378f6d6a7fd50fc0750… (bfd_session_update_tx_interval and bfd_tx_timer_hook) and https://gitlab.nic.cz/labs/bird/-/blob/5c6376d3075a58d1d378f6d6a7fd50fc0750… (timers_fire). Fact: BFD sets recurrent=.75*T and randomize=.15*T (a legal jitter subset), while timers_fire schedules the successor from the previous expiry before calling the hook, unless that successor is already past loop->last_time. The hook then records cached current_time and calls bfd_send_ctl. An exact extracted-function model with mocked clock/heap/send callback demonstrates the consequence: an event serviced100ms late can leave a successor only50ms after its modeled send, despite a150ms recurrence. This demonstrates scheduler arithmetic, not a full BIRD execution. A likely native mechanism is deadline catch-up after late service, or preemption between rescheduling and send; actual native callback deadlines have not been traced, so that causal attribution remains a hypothesis. Suggested BFD-specific change: use a one-shot periodic timer and anchor the next jittered deadline to a fresh monotonic timestamp of actual successful periodic transmission, auditing buffered/failed sends. Preserve immediate Final/changed-content behavior, deferred Up TX increases until Final, immediate negotiated decreases, Demand/zeroRX suppression and idle/state transitions. Avoid changing every recurrent timer client without auditing its contract. Regress normal mult1/3/255 pacing, delayed callbacks, directional changes and recovery. No BIRD patch has been authored, built or validated. > > Checklist > Fixed tested source and binary recorded; exact attached normal program executed twice in fresh isolation; complete textual steps and dependencies provided; actual native configurations, logs, captures, timestamps, sample identities and cleanup retained; RFC, all errata and relevant update applicability checked; sender/receiver and clock/queue observations separated; successful parameter negotiation distinguished from periodic-spacing anomalies; source facts, model result, native root-cause hypothesis and unverified fix design labeled explicitly; no claim about an untested patch or BIRD3 runtime. This report was prepared with AI assistance and reviewed against the cited source and actual execution evidence.

1 0

BIRD 3.4.0 and 2.20.0 released
by Maria Matejka 13 Oct '26

13 Oct '26

Dear BIRD users, we are releasing BIRD versions 3.4.0 and 2.20.0. Both versions include all relevant fixes applied in versions 3.3.3, 3.2.4, 3.1.9, 2.19.3, 2.18.2 and 2.17.7. Downloads are possible at <https://bird.nic.cz/get-bird/> and in our upstream repositories. We have added the BGP channel option `ignore otc` to allow people apply this check manually instead. We have also added passive support for the EVPN ESI attribute. We have added an option to create local-host routes from interface records via the Direct protocol, and a `show radv interfaces` CLI command. This is mostly a minor minor release, and there are more things in progress. Officially supported versions are now: - 3.4.0 and 2.20.0 until 6 months after 3.5.0 and 2.21.0 get released - 3.3.0 and 2.19.0 until end of April 2027 - 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, so that you can get help with configuration, priority access to critical bug fixes, and better influence the overall development directions. It's the users paying for these services, who keep the development running. 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.

3 2

BIRD 2.19.3 NSSA static startup export not retried after link-local readiness
by qipeng ding 10 Oct '26

10 Oct '26

Bug description When BIRD starts while a native link-local address is still tentative, BIRD2.19.3 can leave a valid static external IPv6 route configured at NSSA ASBR startup unpublished beyond convergence after the interface and adjacency become usable. Initial export logs "Cannot find forwarding address for NSSA-LSA". The local route remains present, both routers become Full and ordinary OSPF routes converge, but the receiver gets no target Type7 or external route during a further40-second observation. A normal outbound reload, with the same peer PID and configuration bytes, immediately publishes Type7 and installs the receiver route. This is ordinary native configuration and startup, not malformed traffic or an alleged security effect. Software version Tested BIRD2.19.3, source commit5c6376d3075a58d1d378f6d6a7fd50fc0750a72a, executable SHA256302cdf17722d7601a15aa06d821c8cb92e5b309324a56d19021394e78f2e9793. Linux openEuler24.03 under WSL2. Both endpoints run this same unmodified binary. Each independent run used CPUQuota50%, MemoryMax256M, MemorySwapMax0, TasksMax32 and a 180-second process bound. No source patch was applied. Results are limited to this fixed binary and topology; no current-master runtime or FRR execution is claimed. How to reproduce Requirements: Linux root, Python3, iproute2, util-linux, tcpdump and BIRD2.19.3; birdc is useful for the equivalent manual steps. The attached normal_nssa_startup_export.py is self-contained and imports only Python standard-library modules. Its exact verified source SHA256 is 0d214e2218925520f02ff04e82f09cbf2f6109f85b7df81093ebdf54c38b15c7. Choose a previously nonexistent short output directory and an absolute BIRD executable path. Run the following command, preserving the attached source unchanged: sudo systemd-run --unit=bird-nssa-startup-review-a --collect --wait --pipe -p CPUQuota=50% -p MemoryMax=256M -p MemorySwapMax=0 -p TasksMax=32 timeout 180 unshare --net -- python3 /absolute/path/normal_nssa_startup_export.py --bird /absolute/path/bird --output /tmp/snssa-review-a Repeat with another unused output directory and unit name. Both exact final-source natural-startup executions were independently verified. As a third positive control, run once with --wait-link-local: the corrected program verifies addr_info tentative/dadfailed Boolean fields, and this ready-address control publishes normally without a reload. The failure requires the ordinary startup where BIRD begins before native link-local DAD completes. The complete equivalent textual sequence is: inside a fresh outer network namespace containing only lo, start two owned network namespaces with unshare --net sleep 240 and retain their PIDs. Create one veth pair named sn_dut/sn_peer, move each endpoint into its respective namespace with ip link set ... netns PID, bring lo and the endpoint up, and assign 2001:db8:55::1/64 to DUT and2001:db8:55::2/64 to peer using ip -6 addr add ... nodad. Verify there are no default routes. For the ready-address control, wait until each native link-local address has no tentative flag. Do not disable DAD globally. Configure DUT as: log stderr all; router id 10.0.0.1; protocol device bc_device { scan time 1; } protocol ospf v3 osp { debug all; ipv6 { import all; export filter { reject; }; }; area 1 { nssa; summary yes; interface "sn_dut" { type ptp; hello 1; dead 4; retransmit 2; transmit delay 1; }; }; } Configure peer with router id 1.1.1.1, device bc_device, the same OSPF area/interface settings on sn_peer, and IPv6 export filter { if source = RTS_STATIC then accept; else reject; }. Include the static protocol from the start: protocol static origin { ipv6; route 2001:db8:55:feed::/64 blackhole { ospf_metric2=20; ospf_tag=16909060; }; } The attached startup-dut.conf/startup-peer.conf files provide the exact whitespace-correct full configurations used. Validate both with bird -p -c CONFIG. Start tcpdump on DUT sn_dut before starting either bird -f -c CONFIG -s ROLE.ctl -P ROLE.pid in its own namespace. Use birdc -s ROLE.ctl (or the program's Unix control-socket client) to poll show ospf neighbors until both are Full and show route 2001:db8:55::/64 all until the ordinary OSPF route is present. Confirm show route 2001:db8:55:feed::/64 all on peer shows the origin static route. Record actual IPv6 interface addresses, peer PID and peer configuration hash. Poll the target on DUT for 40 additional seconds and capture show route all/show ospf lsadb. Observe missing target and the startup FA errors. Execute reload out osp only on peer, without changing its configuration, PID or interface addresses. Require DUT target route and exact Type7 LSDB identity, corroborated by the native capture. Remove only the peer static protocol, configure normally and verify target withdrawal plus both Full. Stop only the owned captures/processes and namespaces. The program performs all these steps, records every command/CLI reply/config/log/capture and verifies cleanup; it never attaches to an external network or exports kernel routes. Expected behavior Initial suppression is reasonable while no valid NSSA forwarding address is available. Once an ordinary global address and OSPF interface are usable, the configured, export-accepted static route should be reevaluated and originated as Type7 without manual reload. RFC3101 sections2.3/2.4 require a valid nonzero FA for propagated NSSA external routes, and RFC5340 sections4.4.3.7/A.4.8 require an IPv6 global FA. The same unchanged route/configuration successfully publishes with P1 and FA2001:db8:55::2 on outbound reload. The initial error should not permanently lose this export work. This report does not challenge suppression while FA is genuinely unavailable. Actual behavior Two final-source independent natural-startup executions reproduce the missing export. A separate exact-source control waits for confirmed non-tentative link-local addresses before starting BIRD and publishes the route normally without reload. After Full and positive ordinary-route control, absence persists for 40.187s and 40.158s. First valid Type7 appears 0.023955s and 0.015342s after the respective reload trigger. In each run source PID/configuration are unchanged. Native Type7 is area1, ASBR1.1.1.1, prefix2001:db8:55:feed::/64, type2 metric20, tag0x01020304, P1, FA2001:db8:55::2. OSPF pseudoheader and LSA Fletcher checksums independently verify; capture kernel drops are zero. The receiving external route/LSDB appear, and subsequent ordinary withdrawal succeeds with both routers Full. Additional information Two earlier three-role NSSA startup attempts also failed to establish the same ordinary external-route baseline. Their exact failed sources, polls, logs and captures remain archived. A later Totally NSSA policy test adds its external control after Full and passes; that setup workaround neither fixes nor dismisses this startup finding. The two earlier standalone executions used an otherwise valid protocol identifier that emitted a nonfatal keyword-shadow warning; those results remain preserved. The attached final source uses bc_device. The initial ready-address check then proved incorrect because ip -j uses an addr_info tentative Boolean. Those preliminary controls are explicitly invalidated as ready-address claims and retained. The final source fixes this Boolean gate; two natural-startup reproductions and a genuinely ready-address positive control were rerun cleanly. No corpus PASS is inferred from these standalone observations. Primary RFC texts and all10 associated errata records were reviewed: the one RFC3101 erratum4767 is rejected path-preference wording; RFC5340 verified2078/3350/3351/3352/3357, held1582/1583 and rejected2046/7649 do not amend this FA/export lifecycle. Verified3352 R-bit constraints concern route processing; normal reachable routers are used here. A separate default-route-policy question is not part of this report. Code location and suggested fix Fixed-source links: https://gitlab.nic.cz/labs/bird/-/blob/5c6376d3075a58d1d378f6d6a7fd50fc0750… (ospf_rt_notify, find_surrogate_fwaddr, ospf_originate_ext_lsa, ospf_feed_begin/end), https://gitlab.nic.cz/labs/bird/-/blob/5c6376d3075a58d1d378f6d6a7fd50fc0750… (ospf_ifa_notify3, ospf_iface_new), and https://gitlab.nic.cz/labs/bird/-/blob/5c6376d3075a58d1d378f6d6a7fd50fc0750… (proto_cmd_reload, channel_request_feeding). Source facts: ospf_rt_notify chooses a surrogate FA for a single-NSSA export; if none is found it logs and returns before installing external_rte or originating Type7. find_surrogate_fwaddr scans p->iface_list for the NSSA and admissible nonsecondary, nonpeer addresses above link scope. ospf_ifa_notify3 creates OSPF interfaces on link-local-address notification, while global-address notifications schedule Link/Router LSAs; those paths do not explicitly refeed failed external exports. ospf_iface_new adds the interface to the list. Manual reload out reaches proto_cmd_reload -> channel_request_feeding -> export notification again, now allowing ordinary Type7 origination. Logs show early export errors before the OSPF interface/link-local notification path; actual Type7 appears only after reload. The source-supported root-cause explanation is lost/deferred export work when initial feed and the first device/static update precede usable NSSA interface state, followed by later link-local availability without export retry. The ready-address control shows an initial FA error can recover automatically if interface construction is already available during the initial device/static-update sequence; the delayed-address case misses that opportunity. Native internal callback ordering has not been instrumented, so the precise scheduling attribution remains a hypothesis, while the failed export and manual-refeed recovery are directly observed facts. Suggested concrete design: track pending NSSA exports when FA selection is temporarily unavailable, and coalesce a deferred outbound channel refeed when an eligible NSSA interface/global address becomes available. Hook the availability transitions in ospf_iface_new/ospf_ifa_notify3, with channel-state and pending-work guards; reuse channel_request_feeding rather than invoking export notification recursively inside address callbacks. Preserve route withdrawal and FA changes, avoid repeated full refeeds on every Hello/SPF and audit down/removal transitions. Regress both ready-address and naturally delayed-address startup, valid reload control and withdrawal. This is a suggested design, not an authored, built or tested patch. Checklist Fixed tested version/source and binary hash recorded; complete textual native steps and independently executable exact source attached; exact final source clean-run in two natural-startup reproductions plus a genuinely ready-address positive control; actual initial absence, positive Full/RIB controls, same PID/config reload recovery, raw valid Type7 and receiver LSDB/RIB, zero capture drops, ordinary withdrawal and ownership cleanup verified; all failed/earlier attempts retained; RFC and all applicable errata reviewed; source facts, causal hypothesis and untested fix clearly separated; no inherited FRR/corpus credit, current-master runtime claim or speculative security claim. Maintainer acceptance is not claimed.

2 1

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

"Bird CPU usage is almost always 100% fixes" don't added to upstream repo!?
by Юрий Иванов 08 Oct '26

08 Oct '26

Hi, We faced the same problem discussed here https://github.com/projectcalico/bird/issues/95 According to the message https://github.com/projectcalico/bird/issues/95#issuecomment-2373663908 this bug should be fixed. Still can't find whether these patches was included into main branch.

3 2

Doc for route attribute 'dest' needs update
by Pete Heist 08 Oct '26

08 Oct '26

The documentation of the enum 'dest' route attribute for BIRD 2.x and 3.x still lists RTD_ROUTER, RTD_DEVICE and RTD_MULTIPATH: https://bird.nic.cz/doc/bird-3.3.3.html#route-attributes Afaict these symbols have not existed since BIRD 2, when RTD_UNICAST was introduced. I would offer a patch, but the wording might be better coming from a developer. :) Regards, Pete Heist

1 0

[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