Ze Architecture

What Ze Is

Ze is an open-source configuration and protocol engine. The network operating system built on it speaks BGP, manages Linux network interfaces, programs the FIB, and serves configuration over SSH and the web UI.

None of that is in the core. The core is a supervisor which holds a typed message bus, a config provider, and a plugin manager. BGP, interface management and the rest register as subsystems and plugins. Each one brings its own YANG and augments the configuration tree where it belongs.

Component Map

ze daemon (registry-driven YANG runtime)
  |
  +-- Engine (protocol-agnostic lifecycle supervisor)
  |     +-- ConfigProvider (YANG tree and transactions)
  |     +-- PluginManager / ProcessManager
  |     +-- Configured subsystems (PPPoE and L2TP)
  |
  +-- Plugin Server (shared runtime backbone)
  |     +-- Typed EventBus, subscriptions, and event history
  |     +-- YANG command / RPC dispatcher
  |     +-- Registry discovery and five-stage plugin startup
  |     +-- BGP reactor and feature plugins (RIB, RS/RR, policy, RPKI, ASPA, BMP)
  |     +-- OSPF
  |     +-- IS-IS
  |     +-- BFD
  |     +-- Loc-RIB -> sysrib -> FIB
  |     +-- Dataplane: Netfilter -> Linux; VPP -> VPP; ARP; ND; DHCP
  |     +-- Interface, firewall, traffic, and other ConfigRoot plugins
  |     +-- Internal plugins (goroutines, DirectBridge runtime path)
  |     +-- External plugins (managed processes, five-stage control over authenticated TLS)
  |
  +-- Northbound listeners
        +-- SSH CLI/editor, Web UI, and Looking Glass
        +-- REST, gRPC, gNMI, and MCP
        +-- Prometheus metrics and BMP routing telemetry

Key Design Choices

Key Wire Abstractions

Plugin Server / EventBus

The Plugin Server is Ze's central runtime junction. It implements ze.EventBus for typed publishers and subscribers, owns the YANG-derived command and RPC dispatchers, coordinates plugin startup, and maintains subscription and event history state. In-process subscribers receive typed values directly; plugin process subscribers receive lazily encoded messages through the same fan-out. There is no separate standalone bus in the primary YANG runtime.

Components avoid importing each other's implementation packages. Internal plugins bootstrap through net.Pipe and use DirectBridge for runtime calls; external plugins connect back over authenticated TLS. Route-producing plugins write selected paths into the shared Loc-RIB. sysrib performs system-wide arbitration, then publishes typed best-change events to FIB consumers.

BGP Subsystem

The BGP subsystem owns the protocol: TCP connections, FSM state machines, wire parsing, capability negotiation, and the reactor event loop. It produces structured events and consumes commands. It never imports plugin code.

For a walk-through of the BGP state machine, see bgp-fsm.md.

Configuration

JUNOS-like hierarchical syntax: {} blocks, ; terminators, # comments. YANG-driven parsing. Three-level inheritance: BGP globals, group defaults, peer overrides. Configuration is stored in ZeFS (a blob store with commit/rollback) and managed through an interactive editor accessible over SSH.

For the full config syntax reference, see config-reference.md.

Plugin Architecture

Most protocol and system features are registry-loaded plugins: RIB storage, route reflection, graceful restart, RPKI validation, NLRI encoding, FIB programming, firewall, traffic control, and more. PPPoE and L2TP are Engine-managed subsystems. Internal plugins start as goroutines, bootstrap over net.Pipe, and then use DirectBridge for structured runtime calls without serialization. External plugins are managed child processes controlled through the same five-stage protocol and runtime RPC over authenticated TLS.

For the plugin architecture overview, see plugin-overview.md. For writing plugins, see plugin-development/.

Data Flow

Receive:  Network -> WireUpdate -> Reactor -> EventDispatcher -> Plugins
Announce: Text command -> ParseUpdate() -> WireUpdate -> Peer
Forward:  Cache lookup -> Egress filters -> Wire (zero-copy when ContextID matches)

The reactor fires a single StructuredEvent per received UPDATE. Forwarders (route server, route reflector) and state trackers (RIB plugin) both subscribe to the same dispatch but consume it differently: forwarders make per-peer forwarding decisions, state trackers update best-path state.

FIB Pipeline

Selected routes move through a shared route-decision pipeline:

1. Protocol route producers insert BGP best paths and OSPF or IS-IS SPF paths into the shared Loc-RIB
2. System RIB observes Loc-RIB changes and selects system-wide routes by administrative distance and recursive next-hop resolution
3. FIB consumers receive typed system-rib/best-change events from the Plugin Server/EventBus
4. Kernel FIB programs OS routes through netlink or route sockets; optional VPP FIB uses the GoVPP API

Programs

Source Layout

Deeper Reading