Nodes and Interfaces

Every 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.

What 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.

Compute mode has been removed

Earlier 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.

You 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.

Why it went:

• 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.
• 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.
• 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.

It was not a security boundary

Worth being explicit about, because it is the one thing people assume they are losing.

Compute 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:

• 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.
• 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.
• 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.
• 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 and Security Model.

One 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.

What a node does

One node handles all of it:

• Carries workloads. Endpoints attach to networks, and the node enforces each endpoint's identity.
• Serves the networks it holds. Addressing, DHCP, DNS, firewall policy, bandwidth limits and quotas.
• 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.
• Cooperates with its peers. Shared state, a stretched overlay, and failover of a floating address between a pair of nodes.

Nothing 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.

Interfaces: the thing that actually limits a node

This is the part worth understanding properly, because it — not any node setting — is what constrains a deployment.

An interface can carry only one fast-path attachment. They cannot be stacked. So each of these jobs needs its own interface:

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.

What that means in practice

A node that hosts workloads and nothing else needs two interfaces:

cnv-mgmt-br0    management  (agent, cluster, HA channel)
cnv-user-br0    workloads

A 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:

cnv-mgmt-br0    management  (the first card is its port)
cnv-nic-1       the internet-facing uplink
cnv-nic-2       the inward side
cnv-nic-3       load-balancer VIP traffic

So 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.

If 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.

The two forwarding interfaces are not roles

The 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.

On a host with one physical card

Worth being direct about, because it is the common shape on a dedicated server with a single public address.

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:

cnv-mgmt-br0    management  (holds the host address; cnv-nic-0 is its port)
cnv-user-br0    workloads

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.

A 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.

Combining interfaces: link bonding

Bonding 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.

There are two modes, and they answer different questions.

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.

Pick 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.

The 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 for the bond commands.

Reading a node back

To see what a node is — its hardware id, its agent version, and what it believes about itself:

cenvero-str-ctl node info

The interfaces it uses are in its configuration, which you inspect rather than edit:

sudo cenvero-str-ctl config show

See Configuration for every field, and how a configuration reaches a node.

Choosing a layout

See also

• Gateway NAT & Internet Access — reaching the internet and publishing services.
• Load Balancer — why the L4 balancer needs its own interface.
• BGP Edge Routing — exchanging routes with upstream routers.
• Gateway High Availability — a redundant pair sharing a floating address.
• Configuration — the interface fields, and how configuration is delivered.