Tenant Networking #

A tenant’s network is a virtual overlay of its own, owned by the tenant fabric rather than by any physical VLAN, and default-deny toward every other tenant. The core router is only the perimeter: NAT, internet egress and tenant↔management policy, on one transit network. The model is decided in ADR-0001: Tenant Network Fabric.

Purpose #

Tenant networking provides:

• Isolation — Tenants cannot see each other’s traffic
• Controlled access — Explicit rules for shared services and the outside world
• Scalability — New tenants get a dedicated network with no physical reconfiguration
• Security boundaries — Limit blast radius of compromised workloads

The tenant network is an overlay, owned by the tenant compute domain #

A tenant network is a virtual overlay, not a physical VLAN. Its Layer 3 — the gateway, routing, and isolation — is owned by the tenant compute domain (the tenant fabric), not by the core router. Creating a tenant creates a virtual network; it does not require any change to physical switching.

This keeps a clean line between physical and virtual:

• Physical fabric carries only an undifferentiated underlay between compute members.
• Virtual fabric holds all tenant structure — each tenant’s subnet, gateway, and isolation boundary exist entirely in software and are defined in code.

Each tenant is an isolated routing domain. The gateway for a tenant’s subnet lives in the tenant fabric (an anycast gateway), so a tenant’s default route never leaves the compute domain until it reaches the perimeter.

The tenant fabric #

The tenant fabric is the logical tenant-network domain. It is currently realized on a single tenant hypervisor (a single-member fabric) and is designed to expand to additional members without redefinition — the boundary is the fabric, not any one host. See Tenant Hypervisors for the platform realization and the single-node-to-cluster trajectory.

Perimeter handoff #

The tenant fabric hands off to the core router at a perimeter transit boundary. The core router keeps no VLAN interface per tenant, does not route between individual tenants, and does not address tenant workloads; it sees only the transit network and provides perimeter services on it:

Aggregate tenant egress leaves the fabric on the transit network; the core router applies perimeter policy and NAT there.

Tenant DNS Zones #

Each tenant has a DNS zone scoped to its site:

tenant.site.deevnet.net

Examples:

• eds.mobile.deevnet.net — the EdS tenant on the mobile site
• tdemo.mobile.deevnet.net — the reference tenant

Services within a tenant use the pattern:

service.tenant.site.deevnet.net

Examples:

• service.eds.mobile.deevnet.net — the name in front of the workload
• app.eds.mobile.deevnet.net — the workload’s own name

Internal tenant records are owned by the tenant, written by the tenant’s own IaC into the tenant’s zone. The zone is its own, served by the substrate’s tenant authoritative service and kept separate from the substrate zone; the substrate resolver forwards queries for it ( Naming and Addressing → Two Naming Authorities). This aligns with the stateless-substrate model: rebuilding a tenant restores its own records.

Inter-Tenant Routing #

Default Policy: Deny #

Tenants cannot communicate with each other by default:

• Each tenant is a separate routing domain
• No routing between tenants
• Each tenant is an isolated security domain

Explicit Allow #

Cross-tenant communication requires explicit rules:

• Documented in IaC
• Reviewed for security implications
• Scoped to specific services and ports

Access to Shared Services #

Tenants may need access to substrate-level shared services. Access is granted at the perimeter, from the tenant transit network to services on the platform segment. Tenants never reach the management segment directly. See Shared Tenant Services.

Per-Tenant Addressing #

Each tenant network has its own subnet and gateway, owned by the tenant fabric:

• The tenant’s gateway (.1) is the fabric’s anycast gateway for that subnet
• Workload addresses are derived from the tenant’s index and applied at first boot, not leased. There is no DHCP on a tenant network
• The core router learns one aggregate route to the tenant overlay, so that the substrate’s operator networks can reach tenant workloads ( ADR-0018). It holds no per-tenant state: tenant traffic still arrives already SNATed by the fabric exit node, and per-tenant isolation is enforced inside the fabric

Tenant subnets, network identifiers, and routing-domain identifiers are allocated from a globally-unique plan so that additional fabric members can join later without collision.

Relationship to Substrate Networking #

Tenant networking is a virtual layer on top of Substrate Networking. The substrate provides the physical underlay and the perimeter (core router); the tenant fabric provides the virtual tenant networks that ride on top of it.

graph TB
    subgraph tenant["Tenant Fabric (virtual overlay)"]
        T["tenant A, tenant B, tenant C — each an isolated routing domain"]
    end
    subgraph transit["Perimeter Transit"]
        X["aggregate tenant egress"]
    end
    subgraph substrate["Substrate (physical + perimeter)"]
        S["Core Router: NAT, internet, policy"]
    end
    tenant -->|egress via| transit
    transit -->|perimeter policy at| substrate