bgp persist

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

In-memory sent-route cache with replay on peer reconnect. Tracks routes sent to each peer and replays them via cache-forward commands when the peer comes back up, reducing convergence time.

Configuration

plugin {
    internal persist { use bgp-persist }
    internal rib     { use bgp-rib }
}

bgp-persist is not bound to peers. It subscribes to sent UPDATE events and tracks which routes have been advertised to each peer.

Behaviour

The plugin maintains an in-memory ribOut map that records every route sent to each peer, keyed by peer address, address family, and prefix. When a route is withdrawn, the corresponding entry is removed. When a peer goes down, the ribOut for that peer is preserved.

When a peer reconnects and sends its OPEN, the plugin replays the stored routes back to the peer using cache-forward commands. This lets the peer converge faster because it receives the previously-advertised routes without waiting for the full best-path computation and advertisement cycle to complete.

The plugin does not write to disk. The ribOut state lives entirely in memory and is lost if the daemon process exits. For forwarding-state preservation across restarts, pair this plugin with bgp-gr (Graceful Restart).

Metrics

Registered via ConfigureMetrics on the plugin registration.

Metric	Type	Meaning
`ze_persist_routes_stored`	gauge	Routes currently held in the in-memory `ribOut`.
`ze_persist_peers_tracked`	gauge	Peers with stored state.
`ze_persist_route_replays_total`	counter	Replay events triggered on peer reconnect.

See plugin metrics.

Interactions

Subscribes to sent UPDATE events to populate the ribOut map.
Replays routes to reconnecting peers via cache-forward commands.
bgp-gr complements this plugin: GR preserves forwarding state on the wire side during restarts, while bgp-persist speeds up convergence after a peer session reset.