RustyBGP: a BGP daemon in Rust that keeps the GoBGP config and API

A drop-in replacement, and what that claim covers

RustyBGP is a BGP implementation written in Rust, designed for high performance on multicore systems. The positioning is precise: it supports most of GoBGP's features with the same gRPC API and the same configuration file format, so you can replace gobgpd with rustybgpd without changing your tooling or configuration.

That is the whole pitch, and it is a narrower and more useful claim than a general statement about performance. A BGP daemon is not a library you link into your application; it is a long-running process that speaks a configuration format to operators, a gRPC API to automation, and BGP to its peers. Everything that touches it, from the config file your team has edited for years to the scripts calling the GoBGP CLI, is the compatibility surface. RustyBGP keeps that surface and changes the implementation.

The audience is therefore a network engineer or a platform team running BGP on Linux, most likely an internet exchange or a network operator, who wants to change the implementation without changing the operating practice around it.

The repository layout matches the architecture. There are api/, config/, daemon/, kernel/, packet/, table/ and tools/ directories, plus a docs/ directory and a tests/ directory. The Cargo.toml declares the workspace members as api, config, kernel, packet, table and daemon, with the workspace package at version 0.2.0, edition 2024, authored by FUJITA Tomonori, and the release profile enables link time optimisation.

The split is informative. The packet directory is the wire format, the table directory is the routing table, the kernel directory is the Linux integration, and api/ is the gRPC surface that the GoBGP CLI talks to. The daemon is the process that ties them together.

Kernel FIB integration instead of Zebra or FRR

The one architectural difference that is not about the GoBGP compatibility is that RustyBGP is Linux-only and integrates directly with the Linux kernel for FIB management, instead of using Zebra or FRR.

The kernel integration supports route injection and withdrawal for IPv4 and IPv6 across VRFs, ECMP with multiple nexthops via RTA_MULTIPATH, nexthop tracking, and connected route redistribution.

Nexthop tracking is the operationally interesting one. It monitors nexthop reachability and withdraws affected routes, which means a next hop that stops resolving takes its routes out of the table rather than leaving them pointing at a dead address. Connected route redistribution is the other, detecting interface address changes and injecting the connected routes into BGP, which is what stops a prefix you have stopped advertising from lingering in the table.

Going direct to the kernel rather than through a separate zebra daemon removes a process and a socket from the path, and it is the clearest reason to run this implementation rather than the one it mirrors. It also means the daemon needs the privileges and the kernel support to write the routing table, and it means the deployment story is Linux-specific in a way a zebra-based setup is not.

The address family coverage is broad, and the list is worth reading as a compatibility statement. It covers IPv4 and IPv6 unicast and multicast, L3VPN, EVPN Types 1 to 5, BGP-LS, Flowspec, SR Policy and MUP. It also lists a set of extensions that are supported: route reflector, BGP confederation, route server, Add-Path, IPv4 routes with IPv6 next hops over either session family, graceful restart and its long-lived variant, RPKI, BFD, BMP with all monitoring policies, MRT, policy under the OpenConfig model, dynamic neighbours and peer groups.

There is a caveat in the EVPN line worth noting. The unsupported list says the EVPN control plane is not supported, meaning RT-based MAC-VRF import and export, while the Types 1 to 5 NLRI relay is.

Getting a daemon running, and driving it with the GoBGP CLI

The quick start is a binary download rather than a build, and the nightly is what the documentation points at:

curl -LO https://github.com/osrg/rustybgp/releases/download/nightly/rustybgp-nightly-linux-x86_64.tar.gz
tar xf rustybgp-nightly-linux-x86_64.tar.gz

There is an x86_64 build and an aarch64 build, and the archive extracts in place. Starting the daemon takes the GoBGP configuration file directly:

sudo ./rustybgpd -f gobgpd.conf
Hello, RustyBGP (32 cpus)!

The greeting line reports the core count the process found, which is the multicore design showing through in the smallest possible way.

Management is the part that makes the compatibility claim concrete, because you do not use a new CLI:

$ gobgp neighbor
Peer            AS Up/Down State       |#Received  Accepted
198.51.100.2 65002   never Idle        |        0         0

The GoBGP CLI, downloaded from the GoBGP releases, talks to RustyBGP over the same gRPC API and prints the same table. An operator or a script that shells out to gobgp does not know the difference.

For configuration details beyond the basics, the documentation points to docs/configuration.md for transport settings. Building from source is a separate matter, and CONTRIBUTING.md is the file that describes how to build, test and submit patches.

The three features that are missing, and why they matter

The readme has an explicit section on differences from GoBGP, and three items are listed as unsupported: VPLS, MPLS VPN Multicast, and the EVPN control plane with RT-based MAC-VRF import and export, while the Types 1 to 5 NLRI relay is supported.

Each of those is a real capability rather than a corner case. VPLS is a service model that some large providers run. MPLS VPN Multicast is the multicast variant of the MPLS VPN family. And the EVPN control plane is what a VXLAN fabric needs in order to import and export routes between MAC-VRFs; relaying the NLRI is the data plane half of EVPN, and without the control plane half the fabric cannot learn remote MAC addresses.

This is the part of the evaluation that decides the project for a lot of operators, and it is why the address family list in the supported features section is not the same as the address family list in practice. BGP-LS, Flowspec, SR Policy and MUP are all listed as supported, and L3VPN and EVPN Types 1 to 5 are listed too, but EVPN control plane is not. A network that runs a VXLAN fabric with a BGP control plane is looking at a different implementation from one that runs a leaf-and-spine fabric with L3VPN and static route leaking.

The documentation is candid about this, which is the right way to publish it. The cost is that the reader has to do the compatibility work themselves, mapping the features they run against the list, rather than being told that the two daemons are interchangeable.

One more detail to keep in mind. The release history has a nightly tag dated 2026-06-24 and v0.2.0 dated 2026-06-30, and the last push to the repository was on 2026-10-19, so the tree is well ahead of the last named release. The version in the workspace manifest is still 0.2.0.

Editorial conclusion

RustyBGP fits a network team that already runs GoBGP and wants a different implementation without rewriting its configuration, its automation or its monitoring, because the configuration format and the gRPC API are the same, which means the GoBGP CLI still works against it. It is the wrong choice if you need VPLS, MPLS VPN Multicast or the EVPN control plane, and it is the wrong choice off Linux, since the kernel FIB integration is a Linux-only design. Before deploying it, check the supported feature list against the address families you actually run, confirm the kernel version supports the FIB operations you need, and note that the last push was on 2026-10-19 with the newest release v0.2.0 from 2026-06-30 and nightly builds in between.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. osrg/rustybgp on GitHub
4. README
5. Releases