Network Commands

August 26, 2026 · View on GitHub

solo-provisioner network … manages the node's network state. There are three scopes, each with its own guide.

Most operators never run these directly — block node install sets all three up. Use them to inspect, adjust, or repair what it created.

Flags not listed on this page. Every command here also accepts the global flags — --config, --output, --log-level, --force, --verbose, --non-interactive.

These commands take no --profile — they act on the host's network state directly, independent of any deployment profile.

The three planes

flowchart TB
    subgraph N["nftables"]
      A["<b>network firewall</b><br/>inet weaver-host-firewall<br/>who may reach <i>this host</i>"]
      B["<b>network policy</b><br/>inet weaver-workload-policy<br/>tag forwarded pod traffic<br/>with a QoS class"]
    end
    subgraph T["tc"]
      C["<b>network shape</b><br/>HTB hierarchy<br/>what each class actually gets"]
    end
    B -->|"class mark"| C
I want to…ScopeGuide
Control who can SSH to the host, or block an address outrightnetwork firewallfirewall.md
Decide which QoS class a workload's traffic lands innetwork policypolicy.md
Decide how much bandwidth each class getsnetwork shapeshape.md

How they relate

  • The firewall is node-agnostic. It applies to every node type — block, consensus, mirror, relay — and governs traffic delivered to the host itself.
  • The policy plane is workload-specific. It tags forwarded pod traffic with a QoS class. Today the block node is its only caller.
  • Shaping is what the tag buys you. A policy's --stamp <class> names a class; network shape decides that class's rate, ceiling and priority. A stamp with no shape does nothing useful, and a shape nothing stamps into stays empty.

The firewall and the policy plane are separate nftables tables and are turned on by two independent switches on block node install.

Where state lives

PathWritten by
/etc/solo-provisioner/network-weaver-host-firewall.{yaml,nft}network firewall
/etc/solo-provisioner/network-weaver-workload-policy.nftnetwork policy
/etc/solo-provisioner/policies/network policy — one registry file per policy
/usr/local/sbin/solo-provisioner-bandwidth-shaper.shnetwork shape

Two systemd units replay this at boot:

UnitReplays
solo-provisioner-network-nft.serviceBoth nftables tables — shared by the firewall and the policy plane
solo-provisioner-bandwidth-shaper.serviceThe egress tc HTB hierarchy

Ingress shaping is not replayed by a boot unit: the pod's veth is ephemeral, so the daemon re-attaches it per-pod with block node tc-attach.

See also