BGP Protocol

Address Families

Capabilities

Multipath installation

When several BGP candidates tie under multipath selection, Ze carries the winner and its equal-cost sibling next hops into the shared Loc-RIB. The system RIB then emits one ECMP group to the active FIB backend. Membership-only changes, such as one equal-cost peer disappearing, update the installed group without requiring the winning peer to change.

show rib reports the primary next-hop and the additional ecmp-paths. Together they are the complete installed next-hop set.

Long-Lived Graceful Restart readvertisement

RFC 9494 stale-route handling is applied per destination on both normal forwarding and RIB readvertisement. An LLGR-capable peer receives the stale route unchanged. A non-LLGR eBGP peer receives a withdrawal. A non-LLGR iBGP peer receives the route with NO_EXPORT and LOCAL_PREF=0, allowing partial deployments to retain reachability without preferring stale information.

Only the LLGR filter runs during stale readvertisement. Other export policy has already run on the original announcement and is not applied twice.

Egress attribute rules

Several rails write an UPDATE: the announce rails that encode a route Ze produced, the forward rail that relays another speaker's UPDATE, and the route-server rail. Each rule below is answered at one site that every rail asks, rather than re-derived per rail. The rails that re-derived a rule disagreed about it: the announce rail stripped LOCAL_PREF toward an external peer and the forward rail did not.

Unrecognized NLRI types in a typed family

RFC 7606 Section 5.4 requires a speaker advertising a typed address family to discard routes carrying an NLRI type it does not implement, "unless the relevant specification for that address family specifies otherwise". The ruling is registered per family by the plugin that owns the family, so compiling that plugin out removes both the advertisement and the obligation.

The recognizer answers about the route TYPE only. A well-typed but malformed NLRI is a Section 5.3 concern, handled before this. When the length fields do not agree with the section the NLRI boundaries are unknowable, so no discard decision is made rather than one being guessed.

RFC 7911 Path Identifier regeneration

RFC 7911 Section 2 requires a speaker that re-advertises a route to generate its own Path Identifier, assigned so that (prefix, identifier) uniquely names a path advertised to a neighbor. Both forward rails do that instead of relaying the identifier the source chose.

The key is the path at ingress: the source that sent it and the identifier that source used. A withdrawn route carries no path attributes, so an attribute-derived identifier could not be recomputed when the path leaves; the ingress key can. The same key makes a re-announcement with changed attributes replace rather than duplicate. Identifiers are released at peer removal, not at session down, so a reconnecting peer re-announces under the identifiers its destinations already hold. Zero is minted and accepted like any other value (RFC 7911 Section 3).

Regeneration runs whenever either side of the forward frames identifiers. A session where neither side negotiated ADD-PATH keeps its zero-copy forward.

Protocol event capture and replay

A peer writes every message it receives to a bounded JSONL file, together with the config operations applied while the capture runs. ze-test replay <file> feeds the file back through the same read path with an injected clock.

The tee sits on the complete wire message in both read paths, before message processing. RFC 7606 enforcement rewrites attributes and synthesizes withdrawals, and the family and prefix-limit checks can return before anything is dispatched, so the plugin message-observer hook cannot see what a bug capture needs.

Off by default. The tee costs one nil comparison and no allocation per received message. Config payloads pass a redactor, and TCP-MD5 keys never appear on the wire, so the file holds routing data and no local secret. ze doctor reports whether an enabled peer's capture directory is usable (doctor-bgp-capture-directory).

ze-test replay [--json] [--local-as N] [--peer-as N] [--router-id N] <capture-file|->

Path Attributes