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 licence 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:
- Obviously unwanted traffic is dropped at the network card.
- The sender is verified. On a workload network, a packet must carry the
- Policy is applied — your firewall rules, in priority order, plus any
- The packet is delivered. Locally if the destination is on this node, over
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:
| Symptom | Likely stage | Where to look |
|---|---|---|
| Nothing arrives from one workload | Sender verification | Check the endpoint's registered address and MAC |
| Some traffic passes, some does not | Firewall policy | firewall list — check order and the default action |
| A change did not take effect on an existing connection | Policy applies to new connections | Existing connections continue until they end; flush them to force re-evaluation |
| Traffic reaches the node but not the internet | Gateway | gateway status, and see Gateway NAT |
| Traffic does not reach another node | Overlay | vxlan peers — see Networking Overview |
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, clustering, and
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, so two workloads on different hosts share a
- Shared configuration is agreed between cluster members through an elected
- Gateway failover: a pair of nodes watch each other continuously and
What survives what
| Event | Traffic | Changes |
|---|---|---|
| The agent stops or crashes | Keeps flowing | Blocked until it restarts |
| The agent is restarted automatically | Keeps flowing | Brief pause |
| The node reboots | Interrupted, then restored from the node's own records | Resume once started |
| The licence expires or is revoked | Keeps flowing | Frozen — see Licensing |
| The cluster leader is lost | Keeps flowing | Brief pause during the election |
| Contact with the panel is lost | Keeps flowing | Local changes still work |
Where a node keeps its state
| Path | Holds |
|---|---|
/etc/cenvero-str/ | The node's configuration. |
/var/lib/cenvero-str/ | The node's own records and licence material. |
/var/log/cenvero-str/ | Logs. |
/run/cenvero-str/ | Runtime files, recreated on every boot. |
Back up the first two. They are what a node needs to come back as itself. See Operations.
Ways to reach a node
| Interface | Port | Use |
|---|---|---|
| Command line | — | cenvero-str-ctl, on the node itself. Always available. |
| REST API | 7070 | Automation and integrations. Off until you set a token. |
| gRPC | 7071 | Streaming integrations. |
| WebSocket | 7072 | Live event feed. |
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.