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

AS notation: an AS number is accepted in any of the three RFC 5396 notations everywhere in the configuration and in every command, and bgp as-notation picks the one Ze prints. FRR carries the same choice as bgp asnotation.

BFD strict mode: the capability holds a BGP session out of Established until the BFD session to that neighbor is Up, so a session never forms across a link BFD cannot cross. FRR carries it as neighbor <peer> bfd strict. The other daemons here were not checked for it.

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.

The block is the whole configuration, which is the behavior FRR and BIRD have. import bgp names ze's own Loc-RIB and derives the peer-to-plugin delivery it depends on, so no second binding is written by hand. A consumer that registers after a producer emitted is replayed that producer's current set, so the outcome does not depend on which protocol started first.

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. The RFC 3101 §2.4 border-router default is originated into every attached NSSA in both address families with no operator leaf, and the same install-side gates on a received Type 7 default (P-bit clear, summary import suppressed) apply to both; FRR gates the same origination on default-information-originate. 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

Writes and decodes a pcap: show capture-raw dump bgp pcap writes the recorded messages as a pcap Wireshark dissects as BGP, and ze bgp decode pcap reads one back, reassembling each TCP direction first. The reader takes a tcpdump capture too, so an operator decodes a colleague's file without ze having produced it. ExaBGP decodes hexadecimal from standard input, which ze bgp decode - now matches, but it reads no pcap. The other ten daemons are marked No because none documents a pcap writer or reader of its own; an operator captures with tcpdump and reads the file in Wireshark.

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.

OSPF Standards Coverage

The tables above compare BGP. This one compares OSPF, against the two daemons that also implement it natively. Ze, FRR and BIRD are the whole population here: the other implementations in this table speak BGP only.

Version basis. Ze at commit 35f84e060. FRR at release tag frr-10.7.1 (2026-08-31). BIRD 2.19.2 and BIRD 3.3.2 (both 2026-07-30), which carry an identical OSPF standards list, so one column serves both.

What each column asserts. The three columns are not judged alike, so no cell here says a bare "yes".

A Ze cell states what the code does with the value, in three grades. Originates and consumes means Ze builds it, parses it on receipt, and something acts on the parsed value. Originates means built and parsed, with no consumer beyond display. No means no producer exists.

An FRR or BIRD cell names the evidence: the configuration command, or the source file that implements it, at the version above. That is what was checked. Neither daemon was run, and no cell here claims interop.

Where the open ground is. RFC 8362 and RFC 8666 travel together, because OSPFv3 Segment Routing is defined over the Extended LSAs. Neither FRR nor BIRD implements either, so this is the one part of the table where Ze is alone.

A note on RFC 8362, because the row above says less than it looks. Ze's Extended LSAs carry the U-bit and the scope bits RFC 8362 Section 2 assigns, 0xA021 through 0xA029, with E-AS-External at AS scope (0xC025) and E-Link at link-local scope (0x8028). RFC 8362 Section 2 wants the U-bit set "so that the LSAs will be flooded by OSPFv3 routers that do not understand them", and that is what Ze now sends. Until 2026-09-17 Ze declared those types less 0x8000, so RFC 5340 Section 4.4.1 held every one of them to the link and Ze's Prefix-SIDs stopped at the first router in a mixed area that did not support them.

Ze originates 3 of the 7 Extended LSA types: E-Router, E-Intra-Area-Prefix and E-Inter-Area-Prefix, the three OSPFv3 Segment Routing rides on.

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.

• OSPF as PE/CE (RFC 4577) is absent. No DN-bit originator, no VRF, and no sham link. FRR has none of it either; BIRD has the DN bit alone.
• OSPFv3 Extended LSAs (RFC 8362) are partial. Ze builds 3 of the 7 LSA types. They carry the U-bit and their assigned scope since 2026-09-17, so a router that does not understand them floods them on. Neither FRR nor BIRD implements RFC 8362 at all.
• 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. Ze does carry BFD strict mode (draft-ietf-idr-bgp-bfd-strict-mode, capability 74), which holds a BGP session out of Established until the BFD session is Up.
• 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 35,000+ unit tests, 2,100+ end-to-end tests, 88 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.