How Stratum Works

Background reading for operating a node: what happens when you run a command, how traffic moves through a node, and what keeps working when something fails. Nothing here is configured directly — for the commands see the CLI Reference, and for the vocabulary see Concepts.

What happens when you change something

Every change follows the same path, and knowing it explains most of what you will see in practice.

When you add a firewall rule, create a network, or set a bandwidth limit, the agent checks the request, records it, and applies it to the traffic path. The command returns once all three have happened — so when a command reports success, the change is already live. There is no separate "apply" step and no delay to wait out.

Applying a change and carrying traffic are separate jobs. That has one important consequence:

If the agent stops, traffic keeps flowing. Everything already configured stays in force. What you lose is the ability to change anything — no new rules, no new networks, no API — until it is running again.

This is why an expired or revoked license freezes changes but never drops traffic, and why a node that has lost contact with the panel keeps forwarding exactly as it was. It also means a node whose agent has quietly died can look completely healthy from the outside, which is worth remembering when something seems fine but will not accept changes.

How traffic moves through a node

Traffic is inspected as it arrives and again as it leaves.

On the way in, a packet is checked in order, and the cheapest checks come first so unwanted traffic is discarded before it costs anything:

1. Obviously unwanted traffic is dropped at the network card.
2. The sender is verified. On a workload network, a packet must carry the address and hardware address the endpoint is registered with. This is what stops one workload impersonating another — it is enforced on every packet, not assumed.
3. Policy is applied — your firewall rules, in priority order, plus any blocked addresses.
4. The packet is delivered. Locally if the destination is on this node, over the overlay if it is on another node, or out through the gateway if it is leaving the fabric.

On the way out, traffic passes the shaping stage, where bandwidth limits and traffic priority apply.

Not every stage runs on every packet: anything you have not enabled is not in the path at all, and a packet that never leaves the fabric never reaches the gateway stage.

Where a packet can be stopped

When traffic is not arriving, it was stopped at one of those points, and each has a different way of showing it:

The two networks on every node

Every node keeps its own traffic separate from your workloads':

• cnv-mgmt-br0 — the agent's own traffic: the API, and the traffic between nodes.
• cnv-user-br0 — workload traffic.

They are separate so a saturated or misconfigured workload network cannot cost you access to the node. If you can reach the management side you can still reach the agent, read its state, and repair the workload side. Keep the management network reachable only by operators.

Interfaces Stratum manages start with cnv-. The names are short because the kernel limits interface names to 15 characters.

One kind of node

Every node runs the same agent and does the same work: it hosts workloads and attaches them to the fabric, and it moves traffic between the fabric and the outside world — address translation, routing to upstream networks, north-south load balancing. There is no node type to choose.

Nodes differ only in what you give them: the interfaces they hold and the workloads and networks you put on them. A node with nothing attached is an edge router; a node you never point at an uplink simply forwards nothing outward. See Nodes and Interfaces.

The Compute/Gateway split from earlier versions has been removed. Nodes updating from an older version are migrated with no operator action.

More than one node

Nodes are peers. There is no controller to install, and no single node whose loss stops the others forwarding.

• A network can span nodes once you connect them with a VXLAN overlay, so two workloads on different hosts share a subnet and keep their addresses if they move between hosts. Networks are created per node; nothing stretches them for you. See Networking Overview.
• Nodes can form a cluster (agent 1.0.0-rc.81 or later): the members agree on a small set of shared settings — tenants, the blocklist, overlay peers and address allocations — through a leader they elect, and every member can manage the objects of every other. See Clustering Overview.
• Everything else stays on the node it was created on, cluster or not: machines, volumes, networks, firewall rules and the rest belong to one node, even when you manage them from another.
• Failover of a shared address: a pair of nodes can watch each other continuously and share an address that moves to the survivor; such a pair cannot be set up yourself yet. See Gateway High Availability.

What survives what

Where a node keeps its state

Back up the first two. They are what a node needs to come back as itself. See Operations.

The node's records are private: other local accounts and plugins cannot read them, and cannot list /var/lib/cenvero-str/. A node installed with an earlier version is corrected when the agent starts.

Ways to reach a node

The command line works locally and needs no network, so it keeps working when the API is switched off or misconfigured — which makes it the right tool for recovering a node. See the Management API Reference for the network interfaces, and Operations for turning them on.

Where to go next

• Concepts — the vocabulary used across these docs.
• Security Model — what is enforced, and what is yours to configure.
• Networking Overview — networks, overlays, and routing.
• Operations — running, updating, and troubleshooting a node.