configuration reference

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

The exact shape of every configuration field in Ze lives in the YANG schemas themselves, not in a separately-maintained reference. The schemas are the code, and ze schema show prints them verbatim. This page is the index of the sources you read when you need the exact answer.

Where the answers live

The YANG schemas. Each component and plugin keeps its schema in a yang/ directory beside its code: main/internal/component/bgp/yang/, main/internal/component/bgp/plugins/*/yang/, main/internal/component/iface/yang/, and so on. Read them directly for the exact type, default, and validation rule for a leaf.

ze schema show. Runtime introspection reads from the same schemas the daemon uses. ze schema list gives you every registered module; ze schema show <module> prints the full YANG content of one.

ze schema list
ze schema show ze-bgp-conf
ze schema methods ze-bgp-conf        # All RPCs with parameters

See Introspection for the full set of schema discovery commands.

The in-tree guide. main/docs/guide/configuration.md is the hand-written version of the same material. It covers the common cases well. It is not exhaustive, but it is the fastest path to an answer for the common questions.

Retired keywords

Ze accepts one spelling for each field and rewrites no file for you. A keyword Ze used to accept is refused as an unknown field, and the parse error names what to write instead: unknown field in <block>: process (process is retired: write attach process instead) (line N). The retired keywords today:

Retired	Write instead
process <name> { ... } inside a peer or group	attach process <name> { ... }
admin-distance	distance, inside rib { distance { ... } }, which declares every protocol
certificate-fingerprint	ca <pki-ca-name>, naming the certificate authority root exported from the hub

ze config migrate does not convert old syntax either: it only rewrites a current config between the set form (the default) and the hierarchical form (ze config migrate format hierarchical <file>), hashing plaintext passwords. ExaBGP configs go through ze exabgp migrate.

Shapes worth knowing

A few BGP leaves whose shape is easy to get wrong. The YANG source is main/internal/component/bgp/yang/ze-bgp-conf.yang.

Leaf	Shape	Notes
timer { delay-open N; }	0 to 240 seconds, default 0	RFC 4271 DelayOpen. A peer OPEN ends the wait early; 0 sends OPEN at once
capability { route-refresh <mode>; }	enable, disable, require, refuse	Absent means not advertised. require refuses a session whose peer does not offer it, refuse one whose peer does
capability { extended-message <mode>; }	same four modes	RFC 8654
add-path { ... limit { receive N; } }	1 to 65535	PATHS-LIMIT for received paths
filter { import { filters [ ... ]; final accept; } }	per direction, at bgp, group or peer level	Each configured direction needs its own final accept or final reject. Filters are defined in the top-level policy { } block. An EBGP peer with no policy in a direction rejects announcements in it (RFC 8212)

In the editor, a bare commit is refused: write commit now, commit now force, commit confirmed <N> [force], commit accept, commit abort or commit verify (Editor Workflow).

See also

• Configuration overview for the model and the commit workflow.
• YANG model for how the schemas drive every surface.
• BGP peers for the per-peer reference.
• Introspection for the schema discovery commands.
• In-tree configuration guide for the hand-written long form.