rustbgpd: an API-first BGP daemon that makes route servers programmable

The problem rustbgpd targets

Traditional BGP daemons like BIRD and OpenBGPD are configured through files and often need a reload or restart to change peers, policy, or inject routes. In an IXP route server or a large route reflector, that means downtime or slow convergence when members flap or policy changes. rustbgpd takes a different path: it is API-first, with gRPC as the primary interface for all peer lifecycle, routing, and policy operations. The config file bootstraps initial state, then gRPC owns the truth. No restarts to add peers, change policy, or inject routes. This design targets operators who automate their network and need to react to changes in seconds, not minutes. The project describes itself as an API-first BGP daemon in Rust for IXP route servers, route reflectors, and automation-heavy control planes. The README also notes it is expanding toward cloud and AI-scale data-center fabric use, but that direction is not yet the stated initial target.

How the gRPC interface and policy language work

The core mechanism is that the daemon exposes a gRPC API, and the config file only sets the initial state. After startup, all changes go through gRPC. The README gives a concrete example: you can browse the RIB, see peer summaries, and even use a live TUI dashboard. The `rbgp` CLI talks to the daemon over HTTP to port 50051. Policies are written in `.rpol`, a typed, compiled language with named prefix and community sets. The documentation highlights indexed matchers rather than linear walks, which is a performance-relevant design choice. Policies support parameterization, composition, and unit tests embedded in the policy file itself. The route-server example `hygiene.rpol` shows a policy that rejects AS_SETs, rejects invalid ASPA, and tags RPKI outcomes as extended communities. You can test policies offline with `rbgp policy check` and `rbgp policy test`, and the daemon can explain route decisions from the live RIB, including per-peer received, best, and advertised views.

Getting it running: the 60-second Docker example

The README provides a quick start using Docker Compose. You clone the repository, then run `cd examples/docker-compose` and `docker compose up -d --build`. The `--build` flag forces a build from the current checkout, which avoids reusing an older image. Once both containers are up, you can run `docker compose exec rustbgpd rbgp -s http://127.0.0.1:50051 summary` to see the FRR peer come up, `rib` to browse the RIB, and `top` to launch a TUI dashboard. The Compose service supplies a public, test-only bearer token for the in-container `rbgp` commands. The README explicitly warns this token is for the demo only, not for deployment. That is a useful reminder that the API has authentication, but the example uses a known token, so you must not carry it into a production setup.

What the published benchmarks claim and what they omit

The README leads with a set of performance numbers, each linked to a published receipt. For an IXP route server with 700 clients and 400,400 routes, the policy-file reload completes in 1.28 to 1.57 seconds p50, versus BIRD 3.3.1's 64 to 85 seconds and OpenBGPD 9.1's 244 to 251 seconds. Cold start delivers the full table to all members in 4.8 to 5.0 seconds, versus BIRD's 60.9 to 63.3 and OpenBGPD's 338.0 to 352.1. Member-flap propagation is also faster. The README is careful to list the losses too: OpenBGPD has a smaller reload stall, and BIRD holds a lower settled RSS under flap churn. At IRR scale, BIRD also uses less peak RSS. The project says every number links to a reproducible receipt, and the methodology and fairness protocol are included. That is a strong point in favor of the claims. However, these are measurements from a specific harness on a specific host, and the README notes the figures are from a v0.64.0 refresh. You should not extrapolate to your own hardware without running the receipts yourself.

Where rustbgpd is the wrong tool

The most obvious limitation is the alpha status. The config format and gRPC API are not frozen, and breaking changes are possible between minor versions. The README says so in a warning box. That alone rules out production use for most networks. The platform support is also narrow: only Linux x86_64 and aarch64 are supported daemon targets. If you run BGP on other platforms, or need a daemon that integrates with legacy config management, rustbgpd is not for you. The memory profile is another concern: at IRR-scale reloads, rustbgpd's RSS peak is 1,972 to 2,098 MiB versus BIRD's 1,375 to 1,420 MiB. If you are memory-constrained, that is a real trade-off. Finally, the gRPC-first model means you cannot just edit a config file and reload; you need an automation layer that speaks gRPC. For a small network with a single route server, that is overhead you may not want.

Alternatives: BIRD and OpenBGPD take a file-based approach

The two named alternatives in the README are BIRD and OpenBGPD. Both are mature, file-configured daemons that have been the default for IXP route servers for years. BIRD uses a configuration language and supports online reconfiguration, but the README's benchmarks suggest that reloads at IXP scale take tens of seconds. OpenBGPD is part of the OpenBSD project and is known for a small, secure codebase. Its reload times are even slower in the published receipts. The fundamental difference is architectural: BIRD and OpenBGPD treat the config file as the source of truth, and changes require a reload process that rebuilds state. rustbgpd treats gRPC as the source of truth after bootstrap, so changes are incremental and immediate. That is why rustbgpd can claim faster policy reloads. But it also means you are tied to the gRPC API and the daemon's runtime state; there is no text file to audit after the fact unless you export it.

Maintenance and upgrade cost

The project is under active development, with releases v0.65.0, v0.66.0, and v0.67.0 within a week in August 2026. That cadence indicates rapid iteration, which is good for fixing bugs but bad for stability. The README explicitly maps the stability and compatibility boundaries in `docs/stability.md`, and the alpha expectations say breaking changes are possible between minor versions. That means upgrading from v0.66 to v0.67 might require config or API changes. The license is Apache-2.0, which is permissive and does not impose copyleft obligations, but the README also mentions a LICENSE-MIT file, so there may be dual licensing. You should check the repository for the exact license terms before distributing modifications. The project also has a platform support contract in SUPPORT.md, which you should read to know what hardware and OS combinations are guaranteed to work.

What to verify before you commit

The README gives you a concrete path: run the Docker example, then explore the policy language and the gRPC API. Before you invest in a pilot, you should reproduce at least one of the published benchmark receipts on your own host, because the numbers are tied to a specific harness and hardware. The receipts include methodology and fairness protocols, so you can check whether the comparison is fair. You should also review `docs/stability.md` to understand what parts of the API are likely to change. The test-only bearer token in the Compose example is a warning: if you deploy rustbgpd, you must set up your own authentication and not reuse that token. Finally, check the platform support contract to confirm your deployment targets are covered. The project is public alpha, so treat every minor release as potentially breaking.

Editorial conclusion

Adopt rustbgpd if you run an IXP route server or a control plane where peer churn, policy reloads, and route injection must happen without daemon restarts, and where the gRPC-first model fits your automation. Do not adopt it for a production network yet: the config format and gRPC API are not frozen, and breaking changes can arrive between minor versions. Before any pilot, verify the platform support contract (Linux x86_64 and aarch64 only), review the stability and compatibility document, and reproduce the published benchmark receipts on your own hardware, because the performance claims are tied to specific harnesses and host configurations. Also confirm that the test-only bearer token used in the Docker example is not accidentally carried into a real deployment.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes