what is ze

Pre-Alpha. This page describes behavior that may change.

Ze turns a Linux server into a programmable network device. It speaks BGP, manages network interfaces, programs the kernel FIB, and serves one config tree over five operator surfaces: an SSH-accessible CLI, a web UI, a Birdwatcher-compatible Looking Glass, an MCP server for AI assistants, and a REST + gRPC API (both transports share one engine). Everything beyond the supervisor is a plugin. Plugins can be Go modules compiled into the binary, or external processes written in any language that reads and writes lines.

The engine itself has no knowledge of BGP. It is a supervisor that composes a message bus, a config provider, and a plugin manager. BGP is implemented as a subsystem that plugs into those pieces like any other protocol, which is how interface management and the FIB pipeline slot in later without touching the core. That is the whole point of the architecture, and it is described in more detail on the architecture page.

What Ze is not

Ze is not a router operating system. It does not ship a kernel, a shell, or a packaging story for a full network appliance. You install it on an existing Linux box, like you would install ExaBGP, FRR, or BIRD.

Ze is not a Quagga or FRR fork. There is no shared lineage with either codebase. It is not a mature multi-protocol routing suite either: Ze does BGP, BFD, LDP, RSVP-TE, L2TP/PPP, PPPoE, IPsec/IKE, static routes, and route redistribution. OSPF, IS-IS, and PIM are not implemented. If you need a production-proven IGP suite, use FRR.

Ze is not production-ready. The core engine works, but there are no releases, zero production deployments, and the APIs and config syntax are unstable. The status page is the honest list of what works and what does not.

The headline features

The features are grouped by what they let you do, not by internal component name.

Programmable BGP. JSON events out, text or hex commands in. You can write a plugin in Go that links into the binary, or an external process in Python, Rust, or anything else that speaks the line protocol. ExaBGP users will recognise the model immediately, because Ze is its successor.

YANG-modeled configuration with atomic commits. Every config field, every CLI prompt, and every web UI form is driven by a YANG schema. Edits happen in a per-user draft session. You run diff, commit, and if needed rollback, or commit confirmed with an auto-rollback timer. No daemon restart.

Five operator surfaces over one config tree. CLI, web UI, Looking Glass, MCP, and the REST + gRPC API all read and write the same tree through the same validators. REST and gRPC share one API engine — the same commands, the same output, different wire formats. An AI assistant using the MCP server sees the same schema as a human editing at the CLI.

Chaos testing as a first-class citizen. ze-chaos runs deterministic fault injection against a live Ze and verifies protocol-level invariants. It is not an add-on, it is part of how the project is built. See the chaos testing section.

Plugin ecosystem. The binary reports 65 registered plugins, covering the RIB, route server, route reflector, graceful restart, RPKI, AIGP, BFD, BMP, route filters (community, AS-path, AS-path-length, prefix, attribute modify, private-AS removal), route refresh, Role (RFC 9234), FIB backends (kernel, VPP, P4), route redistribution, and every non-unicast address family (EVPN, FlowSpec, BGP-LS, VPNv4, VPNv6, labeled unicast, VPLS, MVPN, RTC, MUP). IPv4 and IPv6 unicast and multicast are built into the engine itself. Run ze --plugins for the current list.

L2TP/PPP BNG. Native L2TPv2 (RFC 2661) subsystem: tunnel and session FSMs, PPP negotiation (LCP, CHAP/PAP/MS-CHAPv2 authentication, IPCP/IPv6CP), kernel data plane via l2tp_ppp, and subscriber route redistribution into BGP.

BFD for sub-second failure detection. Full RFC 5880/5881/5882/5883 implementation with echo mode, keyed SHA1/MD5 authentication, BGP peer opt-in, and Prometheus metrics.

VPP data plane. Optional VPP integration for DPDK-speed forwarding: ze manages the VPP process lifecycle, binds NICs, programs the FIB via GoVPP, manages interfaces, and exports stats telemetry.

Firewall and traffic control. nftables and VPP backends with commit-time capability checks, stateful rules, conntrack, and per-interface queueing disciplines.

How Ze relates to ExaBGP

Ze is the successor to ExaBGP, written by the same author. The programmable model is the same: processes read structured events from stdin and write text commands to stdout. What changes is everything under the hood. Ze is written in Go instead of Python, is multithreaded, supports far more address families end to end, and has a typed plugin SDK for deeper integration than the line protocol allows.

If you already run ExaBGP, ze config migrate converts most config files, and ze exabgp plugin runs your existing scripts unchanged through a bridge. The ExaBGP migration guide is the right entry point.

See also

• Architecture for the mental model.
• Status for what works today.
• Quick start to get a peer up in five minutes.
• Comparison against FRR, BIRD, GoBGP, OpenBGPd, and ExaBGP.

Adapted from main/docs/why-ze.md and main/README.md.