BGP implementation comparison

Disclaimer and evidence: this comparison was generated with AI assistance and is provided for informational purposes only. All listed projects are under active development and their capabilities change over time. Verify current features against each project's own documentation before making decisions. Rows should be read as evidence-backed advice rather than marketing: code paths link to upstream source where the site can map them, official feature pages are preferred when source links are not practical, and No or Partial means the cited evidence did not support a stronger claim. Corrections and updates are welcome via the issue tracker.

Overview

Address Families

Core Protocol

Cross-Protocol Redistribute

Ze advertises locally-originated routes from non-BGP protocols (connected, static, L2TP, IS-IS, OSPF) into BGP via the redistribute-orchestrator plugin. Operators enable it per-destination and per-source via redistribute { destination <proto> { import <source> { family [...]; } } }. The same config block also drives the intra-BGP IngressFilter ACL when the source is ibgp / ebgp. Per-peer NEXT_HOP substitution (nhop self) is automatic; explicit producer-supplied NEXT_HOP is passed through verbatim.

IS-IS meshes with BGP in both directions, matching the vendor IGP-BGP mutual-redistribution operators expect. IPv6 rides the same single-topology SPF tree -- matching one other implementation's single-topology IS-IS default (that implementation also offers RFC 5120 Multi-Topology, which Ze does not yet implement).

OSPFv2 meshes with BGP in both directions like IS-IS, exports OSPF routes into BGP, and injects connected/static/BGP routes as Type 5 AS-External LSAs. Ze also implements stub, totally-stubby, and NSSA areas (RFC 3101) with Type 7 origination, translator election, and Type 7 to Type 5 translation. Per-interface authentication covers simple password, keyed-MD5 (RFC 2328), HMAC-SHA (RFC 5709), and the RFC 7474 extended-sequence variant, with key chains for hitless rotation and sequence-number replay protection.

Policy & Route Manipulation

Ze takes a programmable approach to policy: external plugin filters manipulate routes via filter { import [...] export [...] } chains using named filter instances or explicit <plugin>:<filter> references. Filters chain as piped transforms (accept/reject/modify) with delta-only output. RFC-mandated checks run as default filters that can be selectively overridden. Built-in filter plugins shipped with Ze include prefix-list matching (ge/le bounds), AS-path regex filtering, community presence matching (standard/large/extended), route attribute modification (local-preference, MED, origin, next-hop, AS-path prepend), community tag/strip, and RFC 9234 role enforcement.

Security

Monitoring & Observability

Most BGP daemons expose operational issues through a mix of per-command output rather than a single aggregated view. Ze provides a cross-subsystem report bus: any subsystem can push warnings (state-based) or errors (event-based) onto a single place, and ze show warnings / ze show errors return the aggregate as structured JSON. The login banner reads the same source, so nothing is silently hidden.

SNMP is a deliberate non-goal, not a gap: FRR and freeRtr both expose legacy AgentX/MIB agents, but Ze's operational surface (Prometheus, gNMI, gRPC, structured JSON events) already covers what those MIBs would carry, without maintaining a second protocol stack to do it.

API & Programmability

Ze's register-once row means a command, config node, plugin, RPC, or event can feed the CLI, web workbench, REST/gRPC, MCP, generated docs, completion, authorization, and audit paths. FRR has partial YANG/API evidence. freeRtr has integrated CLI, NETCONF, and help generation, but not the same all-surface pipeline in the inspected sources.

Operations

Update groups: Ze automatically groups peers by encoding context and builds each UPDATE once per group, fanning out the wire bytes to all members. No configuration needed -- one other implementation in this table requires explicit peer-group assignment for the same optimization.

Best-Path Selection

ExaBGP does not perform best-path selection -- it forwards all received routes to external processes and injects routes from them. It is a route injector/receiver, not a router.

BNG Capabilities

Ze includes a production BNG stack with two access methods: L2TPv2 (RFC 2661) and PPPoE (RFC 2516), both with RADIUS integration (RFC 2865/2866). Most BGP daemons in the comparison table have no BNG functionality at all. L2TP and PPPoE run concurrently on the same daemon and share the same auth, pool, and shaper plugins through a transport-agnostic PPP driver. RADIUS accounting includes real per-subscriber traffic counters read from the kernel PPP interface. Control-plane scale test infrastructure validates 2000 concurrent L2TP sessions across 10 tunnels without requiring root, kernel modules, or Docker.

Where Ze is behind today

The detail tables above are useful. The gaps also need to be visible without reading thirteen tables.

• BGP confederations (RFC 5065) are missing. BIRD 3, bio-rd (partial), FRR, GoBGP, BIRD 2, and freeRtr support them.
• Privilege separation is missing. At least one other implementation in this table has it.
• BFD integration is partial. Several other implementations here have full support.
• Embeddable library mode is missing. At least two other implementations in this table offer one.
• Custom filter language is missing. Ze relies on plugin chains instead.
• Multi-Topology IS-IS (RFC 5120) is missing. Ze's IS-IS matches the single-topology default other implementations ship, but not their optional multi-topology extension.
• Ze is pre-release. The first release is planned for 2026, and this table includes implementations with years to decades of production hardening.
• Performance has not been benchmarked under route-server-size load. Go carries an estimated 10-15% CPU overhead versus C/Rust implementations; this has not been measured under load. See Performance.

These points are repeated here so visitors do not have to hunt for them.

Positioning

Ze is an open-source network operating system and the successor to ExaBGP. It runs as a daemon on any Linux, or as a gokrazy appliance where gokrazy init starts Ze with no general shell or package manager. It speaks BGP, manages network interfaces, installs routes into the kernel FIB or VPP plane, and serves a config editor over SSH and a web UI. The plugin architecture uses YANG-modelled schemas, so plugins can extend the engine without modifying it.

It is also pre-release, with a first release planned for 2026. It sits beside implementations with years to decades of production hardening; one dates to 1998. Its Go runtime is expected to carry a 10-15% CPU cost compared with the C/Rust implementations in this table, and that estimate has not been benchmarked under real load. BGP confederations, privilege separation, and a custom filter language are still missing, while at least one other implementation has shipped each of them for years. Ze is strongest where it has chosen depth: plugin architecture, YANG-modelled configuration end to end, MCP integration, and a production BNG stack alongside BGP.

ExaBGP is the automation specialist. It pioneered the external-process model where BGP events are delivered as JSON to stdin/stdout of user scripts in any language. Deployed worldwide for traffic engineering, DDoS mitigation, route injection, and SDN integration. It has broad address family support. It is single-threaded Python with no RIB, no best-path selection, and no route reflection by design. ExaBGP is a route injector and event source, not a router.

rustbgpd is an API-first BGP daemon targeting IX route server and SDN controller use cases. It trades address family breadth for modern operational tooling (gRPC, Prometheus, structured logging, TUI, config diagnostics) and memory safety guarantees.

bio-rd is a Go BGP library and daemon originating from DE-CIX. Designed as an embeddable library for building route servers and SDN controllers. It has strong route-server support with RFC 9234 (BGP Roles), BMP, and ECMP. IPv4/IPv6 unicast only: no VPN, EVPN, FlowSpec, or other address families. No Graceful Restart or Route Refresh. Apache-2.0 license.

RustyBGP is an experimental Rust BGP daemon by the GoBGP team (OSRG). It offers a GoBGP-compatible gRPC API and multi-core design with low memory usage. Its own README describes it as having "very basic BGP features": limited address family and policy support. It is useful for research and multi-core experimentation, not yet production-ready.

FRR is the most feature-complete open-source routing suite, covering BGP plus OSPF, IS-IS, PIM, and more. Best choice when you need a full routing stack with broad AFI/SAFI coverage and kernel FIB integration.

BIRD 2/3 dominates IXP route server deployments. It is known for low memory use and a powerful filter language. BIRD 3 (stable Dec 2024) adds multithreading for 5000+ peer scale. Management is CLI/config-file only.

GoBGP pioneered the API-first model with gRPC as its primary interface. Broadest AFI/SAFI coverage. Higher memory and CPU usage than C implementations under large routing workloads. It is best used as an SDN controller or route injector rather than a high-performance router.

OpenBGPd is security-focused with privilege separation and OpenBSD heritage. Deployed at major IXPs. Lean, reliable, and standards-compliant with strong RFC coverage including BGP Roles and Extended Messages. No programmatic API beyond the CLI socket.

freeRtr is a full router OS written entirely in Java. It implements the full routing stack with its own TCP/IP forwarding plane that can be backed by DPDK, XDP, or P4 dataplanes. It has the broadest AFI/SAFI coverage of any implementation in this table, including MUP, MVPN, RTC, and VPN FlowSpec. It has been actively developed since 2012 with 4000+ functional test cases. It has no programmatic API, YANG model, or structured logging.

FAQ

Ze is pre-release. Why trust it yet?

Do not take that on faith: it is backed by 22,200+ unit tests, 1,500+ end-to-end tests, 78 fuzz targets, and interop testing against 9 independent BGP implementations. That evidence can be checked. It is not a promise. Ze does not have operational mileage yet: real deployments over real time, on real networks. Use it in labs first.

Why no BGP confederations yet?

Not implemented yet. It's a real gap against implementations that have had it for years, and it's listed as one plainly above rather than left for you to find in a table.

Why no custom filter language?

Ze does not have a bespoke filter DSL like some implementations here do. Instead, filters are external plugins chained per peer/group: JSON events in, text commands out, over a TLS connect-back socket, in any language that can read lines. You can write a filter in Go, Python, or whatever you already know, instead of learning a new syntax.

Is Ze's performance actually competitive with C/Rust implementations?

Unknown under large route-server load. The current estimate is 10-15% CPU overhead from the Go runtime, but that number has not been benchmarked under real load. Treat it as an open question rather than a claim. See Performance for the actual convergence and throughput numbers measured so far.

Does Ze implement every BGP feature in this table?

No. The BGP-specific gaps are listed above: no BGP confederations, partial BFD integration, no custom filter DSL, no privilege separation, and no embeddable library mode. The full-router comparison belongs on the Open Source Network OS comparison.