Networking

Introduction

This section describes how AosCore networks deployable item instances. Every deployable item instance runs with its own isolated networking: it lives in a dedicated network namespace, receives an IP address from a bridge that AosCore owns, and is governed by firewall rules, bandwidth limits, and DNS resolution scoped specifically to that instance. The goal is that instances cannot see or interfere with each other's traffic unless they are explicitly allowed to.

Two components share the work. The Service Manager is the runtime owner of networking on each Node. It builds and tears down the actual network for every instance as it starts and stops. The Communication Manager is the allocator. It hands out IP addresses, subnets, and the per-instance firewall policy, and keeps that allocation consistent across the Unit. The Service Manager asks the Communication Manager what an instance's network should look like, then makes it so.

Networking at a Glance

Concern	Who decides	Who applies it
IP address and subnet	Communication Manager	Service Manager
Per-instance firewall policy	Communication Manager	Service Manager
Network namespace, bridge, and veth	Service Manager	Service Manager
Bandwidth limits	Communication Manager (limits)	Service Manager
DNS for instances on a network	Service Manager	Service Manager
Traffic accounting	Service Manager	Service Manager

Allocation decisions are made once, centrally, so addresses and policy stay consistent even across restarts and reconnects. The mechanics of building the network happen locally on the Node, so an instance can keep running, and be rebuilt cleanly after a reboot, even while the Node is offline from the cloud.

The Native Network Layer

In many container platforms, the work of attaching a workload to the network is delegated to external CNI (Container Network Interface) plugin binaries: separate executables invoked for bridging, firewalling, bandwidth shaping, and DNS. AosCore does not work that way. What CNI plugins would traditionally provide is implemented as native components inside the Service Manager — there are no external CNI plugin binaries.

These native components work directly with Linux networking primitives. Each has a single, well-defined responsibility:

• Bridge and veth setup — creates the virtual ethernet pair that links an instance's network namespace to the AosCore bridge, assigns the instance's IP address and route, and removes them again on teardown.
• Firewall — installs the per-instance allow rules that permit the connections the instance is entitled to, and the outbound address translation that lets the instance reach networks beyond the bridge.
• Bandwidth limiter — applies rate shaping in both directions so an instance cannot exceed its allocated ingress and egress bandwidth.
• Per-bridge DNS resolver — gives instances on a network the ability to resolve each other by name, registering each instance's names and address as it joins and removing them as it leaves.
• Traffic accounting — maintains byte and packet counters for each instance, feeding both monitoring and traffic-quota enforcement.

The diagram below shows these components, the Linux foundations they build on, and the link to the Communication Manager.

loading...

Host Firewall and Accounting Tables

At runtime, AosCore's networking shows up on the host as three firewall-style tables, each with a distinct purpose and a distinct owner.

Main firewall table

This is the primary per-instance firewall. Its forward-filtering chain is fail-closed: a default-drop safety net is provisioned at boot by the operating system, so that pass-through traffic is denied by default even when the Service Manager is not running. The Service Manager never owns or recreates this table. It only augments the chain with the per-instance allow rules for instances that are currently running. The same table also carries a network-address- translation chain that masquerades outbound traffic leaving the bridge, so instances can reach external networks behind the Node's address.

Traffic accounting table

A separate table holds the byte and packet counters used for monitoring and per-instance traffic quotas. Keeping the counters in their own table keeps accounting cleanly separated from the firewall's allow/deny logic. The Service Manager owns this table and maintains a pair of counters for each running instance.

Provisioning firewall table

A third table is a provisioning-time host firewall. It is active during onboarding, before the Unit is fully provisioned, to constrain host traffic while the system is still being brought up. It belongs to the provisioning flow rather than to the per-instance runtime, and is not part of the steady-state deployable item networking path.

loading...

Linux Foundations

The native network layer is built on a small set of standard Linux building blocks, reached through well-known libraries rather than by shelling out to command-line tools:

• Netlink (libnl) — the kernel interface used for everything that has a network shape: creating bridges and virtual ethernet pairs, assigning addresses and routes, and configuring traffic-control shaping for bandwidth limits.
• nftables (libnftables) — the firewall and traffic-counter tables are programmed through the in-process nftables API, which makes rule changes atomic and self-contained and removes any dependency on external firewall command-line tools.
• dnsmasq — a separate dnsmasq process is started for each bridge to serve DNS for the instances attached to that network. As instances come and go, their entries are written to the resolver's hosts file and the dnsmasq process is signalled to reload them, without restarting it.
• Network namespaces — each instance lives in its own network namespace, and a virtual ethernet pair bridges that namespace to the AosCore bridge. The namespace is what makes one instance's networking invisible to another.

Talking to the Communication Manager

The Service Manager and Communication Manager communicate over a dedicated gRPC network service. Three kinds of interaction matter:

• On instance start, the Service Manager asks the Communication Manager for the instance's network parameters — its IP address and subnet, DNS servers, firewall policy, and bandwidth limits.
• On (re)connect, the Service Manager reports the network state it currently has, so the Communication Manager can reconcile its allocation view with what is actually running on the Node. This keeps the central allocation and the on-Node reality from drifting apart after restarts or interruptions.
• For deferred firewall changes, the Communication Manager streams updates back to the Service Manager. When an instance is allowed to talk to another instance that does not exist yet, the firewall policy can only be completed once that second instance is allocated; the Communication Manager resolves the missing rules later and pushes them down so the Service Manager can apply them without rebuilding the rest of the instance's network.

Section Contents

• Per-Instance Network Lifecycle — the end-to-end flow that builds and tears down an instance's network, step by step.

Related Pages

• Architecture Overview — how the Communication Manager and Service Manager fit together.
• Service Lifecycle — where network setup sits within the broader instance lifecycle.
• Monitoring — how per-instance traffic counters feed metrics and alerts.
• Security Model — the isolation guarantees that per-instance networking contributes to.