rustbgpd
An API-first BGP daemon in Rust for programmable route-server and control-plane use cases
rustbgpd, an API-first BGP daemon written in Rust
rustbgpd is a Rust BGP daemon that treats gRPC as its primary control interface for route servers, route reflectors, and automated control planes.
What rustbgpd is built for
rustbgpd is a BGP daemon written in Rust and aimed at network operators who run internet exchange point route servers, route reflectors, and automation heavy control planes. The project describes itself as API first, which means the network protocol configuration is not the only way to drive the daemon. The README positions it for IXP route servers and for route reflector roles where a large number of peers must be managed and where operator mistakes during configuration changes are expensive. The stated target is a programmable control plane, and the project notes it is expanding toward cloud and AI scale data center fabric use. As of the repository state the project is in public alpha, which the author frames honestly: the config format and the gRPC API are not yet frozen, so early adopters should expect breaking changes. The project site is rbgp.rs and the daemon requires a recent Rust toolchain, with the README badge indicating Rust 1.95 or newer. The 58 stars and 3 forks show an early stage project, but the documentation spends considerable effort on measured performance rather than slogans. For a routing daemon the audience cares about convergence and reload behavior under churn, and that is exactly what the project publishes.
gRPC as the control interface
The central design decision in rustbgpd is that gRPC is the primary interface for peer lifecycle, routing, and policy operations. A configuration file still exists, but its job is to bootstrap the initial state; after that, gRPC owns the truth. The practical consequence is that operators can add peers, change policy, or inject routes without restarting the daemon. That avoids the downtime and the full table recomputation that a restart would otherwise force on a route server with hundreds of members. The README emphasizes that every claimed behavior is backed by a published, reproducible receipt, and it links to specific measurement documents rather than asserting numbers in prose. One cited figure is a policy reload at IXP scale, measured as 700 route server clients carrying 400,400 routes with live churn, where the new policy reached every member in a median of 1.28 to 1.57 seconds. The same document compares that against BIRD 3.3.1 at 64 to 85 seconds and OpenBGPD 9.1 at 244 to 251 seconds. The project also states its losses plainly, noting OpenBGPD holds a smaller reload stall and BIRD keeps a lower settled memory under flap churn, which is a rare level of candor for a routing tool.
Explaining routing decisions from the live table
Beyond speed, rustbgpd focuses on making each route decision explainable from the live routing information base. The README lists per peer received, best, and advertised views so an operator can see exactly what a neighbor sent, what the daemon selected, and what it advertised back. There is a best path explain and an export gate explain, and import decision explain is available on an opt in basis. Rejected routes are retained with their reasons, which turns debugging a filter from guesswork into reading a recorded cause. The daemon also exposes BMP, MRT, and metrics, and the project says each of these behaviors has a receipt behind it. Cold start is another documented case: the full 400,400 route table is delivered to all 700 members in 4.8 to 5.0 seconds, compared with 60.9 to 63.3 seconds for BIRD and 338.0 to 352.1 seconds for OpenBGPD in the same harness. A route reflector scale test is reported as 1,000 reflector clients with 100,000 routes converging on the wire in 1.82 seconds at 419 MiB of whole process memory. All of the IXP matrix figures are dated in the README as a same host refresh from 2026-08-08, and earlier runs are preserved in the receipts so the numbers can be checked.
Editorial conclusion
rustbgpd is released under the Apache 2.0 license and is described in its README as a public alpha API first BGP daemon with its project site at rbgp.rs.
Community notes