{
    "product": "Cenvero Stratum",
    "generated_at": "2026-08-03T07:17:08+00:00",
    "format": "cenvero-docs-v1",
    "document_count": 1,
    "documents": [
        {
            "slug": "architecture",
            "title": "How Stratum Works",
            "category": null,
            "url": "https://stratum.cenvero.com/docs/architecture",
            "headings": [
                {
                    "level": 1,
                    "text": "How Stratum Works"
                },
                {
                    "level": 2,
                    "text": "What happens when you change something"
                },
                {
                    "level": 2,
                    "text": "How traffic moves through a node"
                },
                {
                    "level": 3,
                    "text": "Where a packet can be stopped"
                },
                {
                    "level": 2,
                    "text": "The two networks on every node"
                },
                {
                    "level": 2,
                    "text": "One kind of node"
                },
                {
                    "level": 2,
                    "text": "More than one node"
                },
                {
                    "level": 2,
                    "text": "What survives what"
                },
                {
                    "level": 2,
                    "text": "Where a node keeps its state"
                },
                {
                    "level": 2,
                    "text": "Ways to reach a node"
                },
                {
                    "level": 2,
                    "text": "Where to go next"
                }
            ],
            "word_count": 1145,
            "markdown": "# How Stratum Works\n\nBackground reading for operating a node: what happens when you run a command,\nhow traffic moves through a node, and what keeps working when something fails.\nNothing here is configured directly — for the commands see the\n[CLI Reference](/docs/cli), and for the vocabulary see [Concepts](/docs/concepts).\n\n## What happens when you change something\n\nEvery change follows the same path, and knowing it explains most of what you will\nsee in practice.\n\nWhen you add a firewall rule, create a network, or set a bandwidth limit, the\nagent checks the request, records it, and applies it to the traffic path. The\ncommand returns once all three have happened — so when a command reports success,\nthe change is already live. There is no separate \"apply\" step and no delay to\nwait out.\n\nApplying a change and carrying traffic are separate jobs. That has one important\nconsequence:\n\n> **If the agent stops, traffic keeps flowing.** Everything already configured\n> stays in force. What you lose is the ability to *change* anything — no new\n> rules, no new networks, no API — until it is running again.\n\nThis is why an expired or revoked licence freezes changes but never drops\ntraffic, and why a node that has lost contact with the panel keeps forwarding\nexactly as it was. It also means a node whose agent has quietly died can look\ncompletely healthy from the outside, which is worth remembering when something\nseems fine but will not accept changes.\n\n## How traffic moves through a node\n\nTraffic is inspected as it arrives and again as it leaves.\n\n**On the way in**, a packet is checked in order, and the cheapest checks come\nfirst so unwanted traffic is discarded before it costs anything:\n\n1. **Obviously unwanted traffic is dropped** at the network card.\n2. **The sender is verified.** On a workload network, a packet must carry the\n   address and hardware address the endpoint is registered with. This is what\n   stops one workload impersonating another — it is enforced on every packet, not\n   assumed.\n3. **Policy is applied** — your firewall rules, in priority order, plus any\n   blocked addresses.\n4. **The packet is delivered.** Locally if the destination is on this node, over\n   the overlay if it is on another node, or out through the gateway if it is\n   leaving the fabric.\n\n**On the way out**, traffic passes the shaping stage, where bandwidth limits and\ntraffic priority apply.\n\nNot every stage runs on every packet: anything you have not enabled is not in\nthe path at all, and a packet that never leaves the fabric never reaches the\ngateway stage.\n\n### Where a packet can be stopped\n\nWhen traffic is not arriving, it was stopped at one of those points, and each has\na different way of showing it:\n\n| Symptom | Likely stage | Where to look |\n|---|---|---|\n| Nothing arrives from one workload | Sender verification | Check the endpoint's registered address and MAC |\n| Some traffic passes, some does not | Firewall policy | `firewall list` — check order and the default action |\n| 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 |\n| Traffic reaches the node but not the internet | Gateway | `gateway status`, and see [Gateway NAT](/docs/networking/gateway-nat) |\n| Traffic does not reach another node | Overlay | `vxlan peers` — see [Networking Overview](/docs/networking/overview) |\n\n## The two networks on every node\n\nEvery node keeps its own traffic separate from your workloads':\n\n- **`cnv-mgmt-br0`** — the agent's own traffic: the API, clustering, and\n  failover signalling.\n- **`cnv-user-br0`** — workload traffic.\n\nThey are separate so a saturated or misconfigured workload network cannot cost\nyou access to the node. If you can reach the management side you can still reach\nthe agent, read its state, and repair the workload side. Keep the management\nnetwork reachable only by operators.\n\nInterfaces Stratum manages start with `cnv-`. The names are short because the\nkernel limits interface names to 15 characters.\n\n## One kind of node\n\nEvery node runs the same agent and does the same work: it hosts workloads and\nattaches them to the fabric, and it moves traffic between the fabric and the\noutside world — address translation, routing to upstream networks, north-south\nload balancing. There is no node type to choose.\n\nNodes differ only in what you give them: the interfaces they hold and the\nworkloads and networks you put on them. A node with nothing attached is an edge\nrouter; a node you never point at an uplink simply forwards nothing outward.\nSee [Nodes and Interfaces](/docs/nodes).\n\n> The Compute/Gateway split from earlier versions has been removed. Nodes\n> updating from an older version are migrated with no operator action.\n\n## More than one node\n\nNodes are peers. There is no controller to install, and no single node whose loss\nstops the others forwarding.\n\n- **A network can span nodes**, so two workloads on different hosts share a\n  subnet and keep their addresses if they move between hosts. See\n  [Networking Overview](/docs/networking/overview).\n- **Shared configuration** is agreed between cluster members through an elected\n  leader. Losing the leader starts an election; it does not interrupt traffic.\n- **Gateway failover**: a pair of nodes watch each other continuously and\n  share an address that moves to the survivor. See\n  [Gateway High Availability](/docs/clustering/high-availability).\n\n## What survives what\n\n| Event | Traffic | Changes |\n|---|---|---|\n| The agent stops or crashes | Keeps flowing | Blocked until it restarts |\n| The agent is restarted automatically | Keeps flowing | Brief pause |\n| The node reboots | Interrupted, then restored from the node's own records | Resume once started |\n| The licence expires or is revoked | Keeps flowing | Frozen — see [Licensing](/docs/licensing) |\n| The cluster leader is lost | Keeps flowing | Brief pause during the election |\n| Contact with the panel is lost | Keeps flowing | Local changes still work |\n\n## Where a node keeps its state\n\n| Path | Holds |\n|---|---|\n| `/etc/cenvero-str/` | The node's configuration. |\n| `/var/lib/cenvero-str/` | The node's own records and licence material. |\n| `/var/log/cenvero-str/` | Logs. |\n| `/run/cenvero-str/` | Runtime files, recreated on every boot. |\n\n**Back up the first two.** They are what a node needs to come back as itself. See\n[Operations](/docs/operations).\n\n## Ways to reach a node\n\n| Interface | Port | Use |\n|---|---|---|\n| Command line | — | `cenvero-str-ctl`, on the node itself. Always available. |\n| REST API | 7070 | Automation and integrations. Off until you set a token. |\n| gRPC | 7071 | Streaming integrations. |\n| WebSocket | 7072 | Live event feed. |\n\nThe command line works locally and needs no network, so it keeps working when the\nAPI is switched off or misconfigured — which makes it the right tool for\nrecovering a node. See the [Management API Reference](/docs/api) for the network\ninterfaces, and [Operations](/docs/operations) for turning them on.\n\n## Where to go next\n\n- **[Concepts](/docs/concepts)** — the vocabulary used across these docs.\n- **[Security Model](/docs/security)** — what is enforced, and what is yours to configure.\n- **[Networking Overview](/docs/networking/overview)** — networks, overlays, and routing.\n- **[Operations](/docs/operations)** — running, updating, and troubleshooting a node.\n"
        }
    ]
}