Scaling GoBGP: Lessons from Building a Dynamic, API‑Driven BGP Control Plane#

Maxime Peim (Cisco)

• Why: Real lessons from running GoBGP as a multi-tenant, API-driven control plane at fabric scale — including an honest comparison showing GoBGP scales worse than Bird/FRR, and what's being done about it upstream.
• What: Architecture and operational patterns for a multi-tenant BGP daemon: per-tenant BGP servers, route policies, and address families sharing one control plane; tenant lifecycle (create/update/delete) handled via gRPC without disrupting existing sessions.
• How: GoBGP was chosen for its API dynamism, path manipulation strength, and Go integration (goroutine-native, Go package + gRPC interfaces), against Bird 3.0 (now multi-threaded, fast, but static config) and FRR (multi-threaded, static). Scaling targets: tens of thousands of peers per region, hundreds of thousands of routes. The deck includes benchmark methodology and results (mostly graphs), and reports that v4.2.0 shipped some contention fixes; PR #3303 (global mutex relaxation) improves benchmarks significantly in the same configuration — an explicit call for contributors.
• Where applicable: Service-provider-style fabrics, SD-WAN control planes, or any system needing programmatic BGP (service discovery, orchestration feedback). If you need raw route-processing throughput, Bird/FRR still win; the value here is the API surface.