rustbgpdIXP route-server evaluation matrix
One page for an exchange evaluating rustbgpd as a route server: the capabilities IXP evaluations actually score, each with its current status and a link to the config, cookbook, ADR, or measurement receipt that backs it.
One page for an exchange evaluating rustbgpd as a route server: the capabilities IXP evaluations actually score, each with its current status and a link to the config, cookbook, ADR, or measurement receipt that backs it. Statuses are deliberately conservative — an "In progress" row says exactly what is missing, while "Measured" and "Observed" bound a receipt without turning it into a general or cross-daemon superiority claim. Where an incumbent currently does better, the row links the comparison rather than omitting it. To evaluate against live members with zero blast radius, start with the route-server shadow pilot. Provisioning is one of three mutually exclusive modes — hand-written, arouteserver-driven, or IXP Manager-driven — chosen in the cookbook's fork.
| # | Capability | Status | What exists | Evidence |
|---|---|---|---|---|
| 1 | Config generation (arouteserver pipeline) | Yes | Keep your general.yml / clients.yml and refresh cadence: arouteserver template-context → in-repo rs-config-render → fail-stale render → --check --strict validated reload, proven end to end against the pinned official arouteserver image. Upstream arouteserver has no rustbgpd target — the render step is maintained here, not there. | IXP filter pipeline · tools/rs-config-render/ · ADR-0110 |
| 2 | RFC 7947/7948 route-server semantics | Yes | Byte-level transparent redistribution (verified on the wire against BIRD/GoBGP/FRR), both §2.3.2 path-hiding mitigations (Add-Path and per-client best-path), RFC 7948 §4.8 next-hop ownership rejection. | Route-server cookbook · ADR-0101 · ADR-0107 · M83 in RECEIPTS.md |
| 3 | BGP communities | Yes | Standard, extended, and large communities in matching and actions across TOML and .rpol policy; RFC 7947 §2.3.2 / RFC 8195 control communities (per-target announce / no-announce / prepend, scrubbed on egress, transparency preserved for non-participating sessions). Extended-community control forms are deliberately not implemented. | RFC notes · control-community matrix |
| 4 | RPKI: invalid = reject | Yes | RTR client with multi-cache union, RFC 6811 validation with maxLength enforced in the Invalid determination, invalid = reject at import in one deny statement. Each changed VRP/ASPA snapshot asks every affected Established peer to replay every negotiated family; negotiated Enhanced Route Refresh can bracket but does not delta-reduce that replay. Recovery of previously rejected routes requires negotiated Route Refresh and replay. | [rpki] reference · reject-at-import lab (M83) in RECEIPTS.md · rendered hygiene chain in the pipeline |
| 5 | IRR-based filtering | Yes | Per-member IRR prefix/origin sets (bgpq4-expanded, from arouteserver's resolved data model) rendered into trie-backed .rpol sets, refreshed on your existing cadence, fail-stale on any implausible or broken IRR answer. A changed dataset asks each affected Established import peer to replay every negotiated family; negotiated Enhanced Route Refresh does not make that replay entry-delta-scoped, and rejected-route recovery requires negotiated Route Refresh and replay. The daemon has no native IRRd/bgpq4 client — ingest rides arouteserver's. | IXP filter pipeline · ADR-0110 |
| 6 | Looking glass incl. filtered routes | Yes | Alice-LG through the birdwatcher adapter retains status, peer, accepted, filtered, and noexport views. The pinned gate source-builds Alice-LG 6.2.0 with prefix lookup enabled, preserves its four-peer/seven-route accepted and noexport baseline, then runtime-adds a fifth peer and proves an AS-path-loop and an import-policy rejection through Alice's filtered backend and global prefix lookup, including the synthesized community-to-configured-label join; the adapter's table-wide filtered dump (/routes/table/{table}/filtered) feeds that lookup. The pre-fifth-peer captures remain hash-identical across that phase. This is a backend/API proof, not rendered-browser behavior. The sidecar also serves IXP Manager's status, live BGP inventory/detail, symbols, member received/export, and atomic capped global-table seams through direct startup aliases or an atomically reloadable file-backed resolver. Ordinary wildcard-community pairs follow Bird's Eye's accepted-route semantics; full-table counts remain unavailable. The pinned contract (tests/compat/ixp-manager-birdseye/contract.json) records verified IXP Manager 7.4 Bird's Eye API compatibility with documented BIRD-internal divergences, never unqualified compatibility. | birdwatcher adapter · Alice-LG wiring |
| 7 | Reload at IRR scale | Yes | The same-night v0.75.0 campaign covers 320 members × 183,040 generated IPv4 prefixes at 0%, 10%, and 50% received-view overlap, three cross-daemon roots per overlap. Every row has 320/320 sessions and zero parse errors; rustbgpd v0.75.0 completion p50 is 0.584–0.801 s, BIRD 3.3.2 12.926–14.810 s, and OpenBGPD 9.3 44.010–63.948 s. At 50% overlap OpenBGPD's changed-observer gap p50 is shorter (377–517 against 591–627 ms). BIRD 3.3.3, released 2026-10-01, is not yet measured. The v0.68.0 rows and the diagnostic grouped control remain in the dated receipt. | v0.75.0 cross-daemon receipt, measured 2026-10-04 to 2026-10-05 · v0.68.0 IRR reload receipt, measured 2026-08-30 |
| 8 | Paired-RS operations | Yes | Runbook for two independent route servers: why members peer with both, staggered config updates, inter-RS consistency checked with rbgp diff advertised, and the maintenance-window drain flow (RFC 8326). | Paired route servers |
| 9 | MANRS documentation | Yes | MANRS IXP Programme Action 1 is mapped requirement-by-requirement to validated config fragments and member-verifiable surfaces. Separately, the pinned MANRS tool traverses seven synthetic routes through Alice-LG and must identify one deliberate ROA mismatch; this is consumer interoperability, not MANRS certification or a route-server policy proof. | MANRS IXP Action 1 · consumer proof |
| 10 | Dual-stack performance evidence | In progress | IPv4/IPv6 route-server behavior is real-peer and differential-proven. A rustbgpd-only dual-stack policy-reload campaign (September 2026, 0.69.0 daemon source) covers 200 and 700 members, each negotiating IPv4 and IPv6 unicast: all 13 cells passed supplemental gate v3, and five 700-member cells keep their original gate v2 cleanup-refusal failures. The cross-daemon IXP matrix and bgperf2 campaigns remain IPv4-only, so no IPv6 comparative-performance claim is made. The IPv4-only 24 h route-server flagship history includes qualifying runs on v0.70.0 and the v0.71.0 tag, v0.72.0 FAIL on 2026-09-24 on one expired policy stats read, untagged 292c32b39 PASS on 2026-09-26 qualifying that SHA and no release tag, and v0.73.0 FAIL on 2026-09-29 on one rbgp doctor report whose failing check was not retained. No dual-stack soak has run. | M102/M103 in RECEIPTS.md · dual-stack policy-reload campaign · dual-stack readiness receipt · IXP receipt · freshest cross-stack receipt |
| 11 | IRR-scale transactional apply | Measured | Two independent single-host runs measured 2026-08-04 at clean, then-current origin/main commit 02c752408b2336061da050d3396c3f7a538d3389. Each completed 4/4 streamed Plan → token-bound Apply → commit-confirm cycles for a ~295.6 MB candidate at 320 members × 183,040 routes and 3,218,965 IRR filter entries, with 320/320 sessions and zero parse errors. Explicit abort and 10 s timeout auto-revert restored disk and runtime byte-exactly; rollback completed 69.5 s / 69.0 s after the deadline under a 600 s ceiling. This is one fleet shape in two fixed-order repeats, not a cross-daemon comparison. | transactional-apply receipt · compact evidence |
| 12 | Live AS_SET receiver behavior | Observed | Repeated local runs on 2026-08-29 sent an ordinary AS_SEQUENCE control and a two-member AS_SET over IPv4 from one raw route-server client, without changing any receiver's AS_SET policy default. The control reached all five receivers. rustbgpd 0.67.0, BIRD 3.3.2, and OpenBGPD 9.2 did not install the AS_SET route; GoBGP 4.8.0 installed it in accepted Adj-RIB-In, and FRR 10.3.1 installed it. All sessions and processes survived, and withdrawal cleared both routes. "Not installed" does not distinguish policy rejection from treat-as-withdraw; this manual observation is not a conformance ranking. | M105 procedure and observation · topology · driver |
For a sizing review, start with the current evaluator evidence roll-up. It separates current four-daemon import/convergence data from the IXP-specific reload and member-churn campaign, records the IPv4-only boundary, and explains why the three commonly cited 1,000-peer memory values are not a time series.
Related evaluation material: the broader daemon feature comparison, the reload classification of every config field, the receipt index behind every wire-behavior and performance claim, and the migration notes for mapping an existing BIRD / OpenBGPD / ARouteServer deployment.