{
    "product": "Cenvero Stratum",
    "generated_at": "2026-08-03T07:17:37+00:00",
    "format": "cenvero-docs-v1",
    "document_count": 1,
    "documents": [
        {
            "slug": "nodes",
            "title": "Nodes and Interfaces",
            "category": null,
            "url": "https://www.stratum.cenvero.com/docs/nodes",
            "headings": [
                {
                    "level": 1,
                    "text": "Nodes and Interfaces"
                },
                {
                    "level": 2,
                    "text": "Compute mode has been removed"
                },
                {
                    "level": 3,
                    "text": "It was not a security boundary"
                },
                {
                    "level": 2,
                    "text": "What a node does"
                },
                {
                    "level": 2,
                    "text": "Interfaces: the thing that actually limits a node"
                },
                {
                    "level": 3,
                    "text": "What that means in practice"
                },
                {
                    "level": 3,
                    "text": "The two forwarding interfaces are not roles"
                },
                {
                    "level": 3,
                    "text": "On a host with one physical card"
                },
                {
                    "level": 2,
                    "text": "Combining interfaces: link bonding"
                },
                {
                    "level": 2,
                    "text": "Reading a node back"
                },
                {
                    "level": 2,
                    "text": "Choosing a layout"
                },
                {
                    "level": 2,
                    "text": "See also"
                }
            ],
            "word_count": 1775,
            "markdown": "# Nodes and Interfaces\n\nEvery node runs the same agent and does the same job: it carries workloads, enforces policy on their traffic, and routes between the networks it holds and whatever lies beyond them. There is no node type to pick and nothing at install time that decides which of those a node is allowed to do.\n\nWhat actually shapes a deployment is **interfaces** — how many a node has, and what each one is already doing. That is what this page is about.\n\n## Compute mode has been removed\n\nEarlier versions asked each node to be one of two things: *Compute*, which hosted workloads but did not route, or *Gateway*, which routed. **That split is gone. Every node routes.**\n\nYou do not have to do anything about it. A node updating to this version has its configuration rewritten as part of the update — no reinstall, no mode to choose, no command to run. Networks, endpoints, firewall rules, tenants and addressing are untouched, and a node that was already a gateway carries on exactly as before.\n\nWhy it went:\n\n- **It could only be decided once.** The mode was fixed at install and could not be changed afterwards, so getting it wrong meant reinstalling a live, licensed machine to correct a single setting.\n- **Almost nobody actually chose it.** The installer never asked and never wrote the setting, and a node without it was treated as Compute — so nearly every node was Compute by accident rather than by intent.\n- **It broke routed addressing.** A Compute node did not route between networks. On a single-card dedicated server — the common shape — that made routed additional addresses, which is how most providers sell extra IPs, simply not work.\n\n### It was not a security boundary\n\nWorth being explicit about, because it is the one thing people assume they are losing.\n\nCompute mode never decided who may talk to whom. It happened not to route, which closed one path as a side effect — that is not the same as a policy, and it protected nobody deliberately. What keeps traffic separated is enforced in the path the packet is already taking, and does not depend on whether a node routes:\n\n- **Sender verification.** Traffic from an endpoint must carry the address and hardware address that endpoint is registered with, checked on every packet. This is what stops one workload impersonating another.\n- **Firewall policy.** Your rules are applied wherever traffic enters the node, so a rule is in force at every entry point rather than on one interface.\n- **Different customers cannot reach each other.** Traffic between the private networks of two *different* tenants is refused outright, in the packet path, whether or not you have written a single firewall rule. This replaced what the old mode was accidentally doing, and it is stronger: private addresses are not reachable from outside either, so there is no route around it.\n- **Your own networks are yours to decide about.** Two networks belonging to the same tenant are not separated by default — that is the firewall's decision. Set its default action to `deny` and the separation becomes explicit and auditable rather than incidental. See [Zero-Trust Firewall](/docs/networking/firewall) and [Security Model](/docs/security).\n\nOne thing that is deliberately *not* blocked: two workloads reaching each other by their **public** addresses, when both are on the same node. That traffic is turned around inside the node instead of going out to your provider and back — faster, and it never touches your uplink. Blocking it would separate nothing, because a public address is reachable from the internet anyway; it would only make the same conversation slower. It is still fully metered and still bound by every bandwidth limit and quota. See [Gateway NAT](/docs/networking/gateway-nat).\n\n## What a node does\n\nOne node handles all of it:\n\n- **Carries workloads.** Endpoints attach to networks, and the node enforces each endpoint's identity.\n- **Serves the networks it holds.** Addressing, DHCP, DNS, firewall policy, bandwidth limits and quotas.\n- **Routes.** Between its own networks, and out to whatever is upstream — including address translation so a private subnet reaches the internet over one public address, published services, and route exchange with your upstream routers.\n- **Cooperates with its peers.** Shared state, a stretched overlay, and failover of a floating address between a pair of nodes.\n\nNothing on that list is reserved for a particular kind of node. What limits a node is how many interfaces it has free, which is the next section.\n\n## Interfaces: the thing that actually limits a node\n\nThis is the part worth understanding properly, because it — not any node setting — is what constrains a deployment.\n\n**An interface can carry only one fast-path attachment.** They cannot be stacked. So each of these jobs needs its *own* interface:\n\n| Job | Needs its own interface |\n|---|---|\n| Management (agent, cluster, failover signalling) | the management bridge |\n| Workload traffic | the workload bridge |\n| The uplink the node forwards out of | the WAN interface |\n| The inward side it forwards to | the LAN interface |\n| L4 load balancer VIP traffic | a dedicated VIP interface |\n\n> **You do not need a separate physical card for each.** A VLAN sub-interface or a virtual interface counts as its own interface for this purpose. What you cannot do is point two of these jobs at the *same* interface.\n\n### What that means in practice\n\nA node that hosts workloads and nothing else needs two interfaces:\n\n```\ncnv-mgmt-br0    management  (agent, cluster, HA channel)\ncnv-user-br0    workloads\n```\n\nA node that also forwards traffic across its edge, and load-balances, needs more, because the uplink, the inward side and the VIP each want their own:\n\n```\ncnv-mgmt-br0    management  (the first card is its port)\ncnv-nic-1       the internet-facing uplink\ncnv-nic-2       the inward side\ncnv-nic-3       load-balancer VIP traffic\n```\n\nSo the answer to \"how many cards does this node need?\" is **one per distinct job it is doing** — a node doing more jobs needs more interfaces. Add the load balancer and it needs one more again.\n\nIf you skip the load balancer's interface, everything else still works — you simply have no L4 balancing, and the symptom is a VIP that looks perfectly configured and passes no traffic. See [Load Balancer](/docs/networking/load-balancer).\n\n### The two forwarding interfaces are not roles\n\nThe node's configuration names two interfaces for the forwarding path. They are placements, not roles: the node decides which direction a packet is going from its routing table, not from which setting named an interface. So the question to ask when planning is not \"which one is the WAN\" — it is \"are there two free interfaces\". See [Configuration](/docs/configuration).\n\n### On a host with one physical card\n\nWorth being direct about, because it is the common shape on a dedicated server with a single public address.\n\n**Hosting workloads on one card is fine.** The uplink is enslaved to the management bridge, which carries the host's address, and the workload bridge carries workloads. Two interfaces, one card, nothing contended:\n\n```\ncnv-mgmt-br0    management  (holds the host address; cnv-nic-0 is its port)\ncnv-user-br0    workloads\n```\n\n**Forwarding between two separate interfaces is a different matter.** Both sides want their own fast-path attachment, and on a one-card host both candidates are already spoken for: the workload bridge carries the workload attachment, and the management path deliberately carries none at all — attaching workload anti-spoofing to the host's own path has taken a machine off the network before, which is why that exclusion exists.\n\nA VLAN sub-interface or a virtual interface pair is what creates the missing one. **We have not validated that layout, and we would rather say so than hand you a configuration to try on a machine you cannot get back.** If you need it on single-card hosts, talk to us before you build a product around it.\n\n## Combining interfaces: link bonding\n\nBonding is the other half of the interface story. Instead of splitting jobs across interfaces, it joins several physical interfaces into **one logical interface** that the rest of Stratum treats as a single NIC — so a bond can be the workload bridge's uplink, or the interface the node forwards out of.\n\nThere are two modes, and they answer different questions.\n\n| Mode | What it gives you | What it needs |\n|---|---|---|\n| **`active-backup`** | **Survival.** One member carries all traffic; if its link dies, another takes over. Throughput stays that of a single link. | Nothing from your switch — the members can even go to two different switches, which is what protects you from losing one. |\n| **`802.3ad`** (LACP) | **Capacity and survival.** Traffic is spread across all members, so total throughput can exceed one link, and a failed member drops out. | A matching port-channel configured on the switch. Without it the bond will not come up. |\n\n> **Two links does not mean one connection goes twice as fast.** With LACP, traffic is distributed *per conversation* — each connection picks a member and stays on it. Ten connections spread across two links; one large single transfer still rides one link at that link's speed. If you need a single stream faster, you need a faster link, not more of them.\n\nPick `active-backup` when you want redundancy and control nothing about the switch. Pick `802.3ad` when you own the switch configuration and want the aggregate capacity.\n\nThe bond becomes a normal interface once created, so everything in the interface table above applies to it — a bond can hold one job, not several. See [CLI Reference](/docs/cli) for the `bond` commands.\n\n## Reading a node back\n\nTo see what a node is — its hardware id, its agent version, and what it believes about itself:\n\n```bash\ncenvero-str-ctl node info\n```\n\nThe interfaces it uses are in its configuration, which you inspect rather than edit:\n\n```bash\nsudo cenvero-str-ctl config show\n```\n\nSee [Configuration](/docs/configuration) for every field, and how a configuration reaches a node.\n\n## Choosing a layout\n\n| You want | Use |\n|---|---|\n| A single node to learn on, or a self-contained deployment | One node — it hosts workloads *and* reaches the internet |\n| More workload capacity | More nodes in one cluster; each carries workloads and its own policy |\n| No single point of failure at the edge | Two nodes paired for high availability, sharing a floating address that moves to the survivor |\n| A node dedicated to edge traffic | A node with no workloads attached — same software, you simply give it nothing to host |\n\n## See also\n\n- [Gateway NAT & Internet Access](/docs/networking/gateway-nat) — reaching the internet and publishing services.\n- [Load Balancer](/docs/networking/load-balancer) — why the L4 balancer needs its own interface.\n- [BGP Edge Routing](/docs/networking/bgp) — exchanging routes with upstream routers.\n- [Gateway High Availability](/docs/clustering/high-availability) — a redundant pair sharing a floating address.\n- [Configuration](/docs/configuration) — the interface fields, and how configuration is delivered.\n"
        }
    ]
}