Network service and topology NETT 005

Proposed Infrastructure Network Topology Nett Routing BGP

Defines Nett as the network automation service and establishes the v1 topology, isolation, and rollout model.

Author
Lars Solem
Updated

Status

Proposed on 2026-03-14 by Lars Solem.

Context

Dataverket needs to provision compute, Kubernetes, VPN, public ingress, and tenant-isolated networks without relying on manual switch or router changes.

The accepted CLI ADR already defines dvnet, which implies a first-class network service. The service naming ADR does not yet formalize that service.

The platform also needs a realistic v1 topology. It must be simple enough to operate early, while still leaving a clean path toward larger multi-tenant and multi-rack deployments.

Decision

Dataverket introduces Nett as a first-class platform service responsible for datacenter network automation.

Nett is split into two architectural categories:

  • Infrastructure-side Nett Datacenter fabric, routed underlay, inter-datacenter connectivity, and device-facing automation.

  • Provider-side Nett Tenant-facing logical networks, IP allocation, VPN products, DNS integration, and service exposure primitives.

The infrastructure-side part should further separate at least these internal subdomains:

  • fabric topology and port intent
  • L2 segmentation such as VLANs and trunk/access profiles
  • L3 routing and edge policy
  • inter-datacenter transport and site-aware routing
  • network drift detection and rollout safety

Nett owns the declarative lifecycle of:

  • switch port configuration
  • VLANs and trunk/access profiles
  • routed uplinks and L3 gateways
  • tenant logical networks
  • VPN endpoints and related edge policy
  • load balancer and service IP pools
  • IPAM and DNS integration points

Nett does not become the source of truth for physical inventory. Physical devices, racks, links, and port identities remain part of shared infrastructure inventory managed by Sentral and consumed by Nett.

Topology model

The v1 platform topology is split into four logical domains:

  1. Out-of-band management network BMCs, switch management, router management, and emergency access paths.

  2. Provisioning network PXE/iPXE, Talos installer boot, discovery, and early bring-up traffic.

  3. Underlay transport network Stable node-to-node transport between hypervisors, Kubernetes nodes, storage systems, and network appliances.

  4. Tenant/service networks VLAN-backed isolated networks for workloads, services, ingress, and platform products.

  5. Inter-datacenter transport Controlled connectivity between datacenters for control-plane traffic, replication, failover, and service synchronization.

Each datacenter is treated as an explicit failure domain in the topology and inventory model.

Isolation model

The v1 isolation model is:

  • VLANs for segmentation by default
  • VRFs where separate routing domains are required
  • BGP for routed edges, service advertisement, and future scale-out

This deliberately avoids starting with EVPN/VXLAN as a requirement. Overlay networking may be added later, but is not part of the initial control plane contract.

Configuration model

Nett uses a vendor-neutral intent model with vendor-specific drivers.

The workflow is:

  1. Sentral stores desired network state.
  2. Nett validates the request against topology, policy, and capacity.
  3. Nett renders vendor-specific configuration from the normalized intent.
  4. Nett applies config through a driver appropriate to the target device.
  5. Nett records realized state, errors, and drift signals.

Drivers may use:

  • SSH/CLI
  • REST API
  • NETCONF
  • RESTCONF

The intent model must not expose vendor syntax to API consumers.

Validation and rollout safety

Because Nett can affect critical shared infrastructure, intent application must be treated as a safety-sensitive workflow.

The first implementation must support:

  • validation of intent against known topology and policy
  • dry-run or rendered-change review before rollout where practical
  • staged rollout for sensitive changes
  • explicit failure handling when real device state does not match expected inventory or intent assumptions
  • drift visibility after rollout

Intent that cannot be validated or safely rolled out is not ready for production application.

Test strategy implications

Nett must be testable at several levels:

  • model and validation logic in software-only tests
  • rendered configuration tests
  • virtualization or lab-based integration tests where possible
  • hardware-in-the-loop validation for sensitive or vendor-specific behavior

The platform should assume that intent-model correctness and device-driver correctness are separate things that both need testing.

Routing and edge model

The v1 routed model is:

  • BGP-capable edge or core routers for north-south routing
  • routed service IP advertisement for Kubernetes and public services
  • VPN termination at the network edge, not on random worker nodes
  • public/private address pools managed as allocatable resources
  • routed inter-datacenter connectivity for control-plane and service failover traffic

The network model must support two or more datacenters connected through explicit inter-site routing rather than assuming a single flat location.

Service boundaries

Nett is responsible for network intent and network configuration rollout.

The infrastructure-side and provider-side parts of Nett may initially ship together, but they should not be modeled as one undifferentiated domain. The infrastructure side protects the datacenter fabric; the provider side exposes safe tenant-facing capabilities built on top of that fabric.

Nett is also responsible for modeling and automating inter-datacenter connectivity required for:

  • control-plane communication
  • replication traffic
  • service failover paths
  • site-aware routing policy

It is not responsible for:

  • Kubernetes CNI internals
  • application ingress configuration above the network edge
  • certificate issuance
  • hardware power control

Those remain owned by Plattform, Tjeneste, Identitet, and Maskin respectively.

Consequences

  • dvnet now has a clear service owner: Nett
  • network changes become part of normal orchestration rather than external manual work
  • inventory quality becomes critical, because wrong topology data will produce wrong config
  • a vendor support matrix is now required for implementation
  • Dataverket can start with VLAN and BGP primitives and delay more complex overlays
  • multi-datacenter routing becomes a first-class requirement rather than an afterthought
  • safe rollout and validation now become mandatory parts of Nett rather than optional engineering polish

Decision Outcome

Proposed. This ADR records the current preferred direction and still needs acceptance before it becomes binding.

More Information

  • supported switch and router vendors for v1
  • IPAM and DNS source of truth
  • VPN technology selection
  • load balancer implementation model
  • inter-datacenter routing and failover policy

Audit

  • 2026-03-14: ADR proposed.