Skip to content

Network Architecture

This page documents one shipped network reference topology. It exercises the HybridOps networking contract across Proxmox SDN, VyOS, Hetzner, GCP, and Azure. Proxmox SDN supplies on-prem segmentation, VyOS supplies the routed edges, and cloud-native routing services extend the same declared route and verification model across providers. EVE-NG is a separate Academy and validation workload within this implementation.

Current reference topology

This reference topology separates networking responsibilities this way:

  • On-prem core / segmentation
    Proxmox SDN provides VLAN-aware bridges, routed VNets, gateway IPs, DHCP, and inter-VLAN policy enforcement.

  • On-prem site extension
    A dedicated VyOS VM on Proxmox originates approved on-prem prefixes and extends the site into the routed WAN domain through dual tunnels.

  • Static WAN edge
    A Hetzner VyOS pair provides the fixed public face for Site-A, terminates the GCP HA VPN underlay, and hosts the shared control-plane services needed for DNS, observability, and decision logic.

  • Cloud routing hub
    GCP Cloud Router, HA VPN, and NCC provide the cloud-side routing hub.

  • Observability
    Observability remains isolated on its own subnet and is extended to the edge control-plane as a separate service layer.

  • Simulation / Academy EVE-NG stays in VLAN 50 and is used for simulations, training, and validation. It is not in the operational WAN path.

Topology overview

flowchart TB
    subgraph onprem["On-prem Site"]
      prox["Proxmox SDN core\nvmbr0 + routed VNets"]
      vyos["On-prem VyOS edge\nsite extension"]
      sim["EVE-NG simulation\nVLAN 50 only"]
      prox --> vyos
      prox -. simulation only .-> sim
    end

    subgraph hetz["Hetzner Site-A edge"]
      edgea["VyOS edge-a"]
      edgeb["VyOS edge-b"]
      ctrl["Shared control host\nPowerDNS / runner / control services"]
    end

    subgraph gcp["GCP hub"]
      hub["Cloud Router + HA VPN + NCC"]
    end

    vyos --> edgea
    vyos --> edgeb
    edgea --> hub
    edgeb --> hub
    ctrl --- edgea
    ctrl --- edgeb

On-prem VLAN allocation

VLAN VNet Subnet Gateway DHCP Pool Purpose
10 vnetmgmt 10.10.0.0/24 10.10.0.1 10.10.0.120-10.10.0.220 Management
11 vnetobs 10.11.0.0/24 10.11.0.1 10.11.0.120-10.11.0.220 Observability
12 vnetdata 10.12.0.0/24 10.12.0.1 10.12.0.120-10.12.0.220 Shared services / data
20 vnetdev 10.20.0.0/24 10.20.0.1 10.20.0.120-10.20.0.220 Development
30 vnetstag 10.30.0.0/24 10.30.0.1 10.30.0.120-10.30.0.220 Staging
40 vnetprod 10.40.0.0/24 10.40.0.1 10.40.0.120-10.40.0.220 Production
50 vnetlab 10.50.0.0/24 10.50.0.1 10.50.0.120-10.50.0.220 Validation / Academy

Design bands:

  • 10-19: platform plane
  • 20-29: development
  • 30-39: staging
  • 40-49: production
  • 50-59: validation / Academy
  • 60-99: reserved

Addressing model

Within each /24 on-prem subnet:

  • .1 is the routed gateway
  • .2-.9 are reserved for infrastructure services
  • .10-.99 are static assignments from NetBox IPAM
  • .100-.200 are DHCP allocations where enabled
  • .201-.254 remain reserved for future use

Static allocations should be consumed from NetBox/IPAM-backed outputs rather than copied into module or blueprint inputs by hand.

Routing boundaries

The current shipped routing model is:

  • Proxmox SDN owns east-west on-prem routing across the approved VLANs.
  • The on-prem VyOS edge originates approved on-prem prefixes into the Site-A routed domain.
  • The Hetzner VyOS pair presents Site-A to GCP with stable public endpoints.
  • GCP Cloud Router learns only the approved on-prem prefixes and does not learn validation-only or internal link networks.
  • EVE-NG remains out of the routed WAN baseline unless a controlled exercise explicitly attaches it through temporary, controlled interfaces.

Use the Network routing contract for ASNs, tunnel /30 allocations, and import/export boundaries.

DNS and control-plane boundaries

The current shared control-plane model is:

  • PowerDNS primary and control services on the shared Hetzner control host
  • optional on-prem secondary/resolver path for local resilience
  • DNS cutover through HyOps DNS routing modules and blueprints

This keeps naming, decision control, and runner execution separate from the data-plane edge appliances.

Validation pointers

For operator validation, use the HyOps runbooks rather than the old external repository walkthroughs:

Typical on-prem quick checks remain:

ip -d link show vmbr0
ip -o addr show | grep '10\\.'
iptables -t nat -L POSTROUTING -n -v
systemctl status dnsmasq

Typical HyOps state checks:

hyops state show --env <env> --module core/onprem/network-sdn
hyops state show --env <env> --module org/hetzner/vyos-edge-foundation
hyops state show --env <env> --module platform/network/vyos-edge-wan
hyops state show --env <env> --module platform/network/vyos-site-extension-onprem

Simulation boundary

EVE-NG remains important, but its role is deliberate:

  • Academy delivery
  • protocol and vendor interoperability exercises
  • failure simulation
  • tooling validation before promoting changes into the live HyOps path

That simulation surface should stay isolated from the operator baseline. Use ADR-0201 – EVE-NG Network Simulation Architecture and the EVE-NG HOWTOs for that work.

Maintainer: HybridOps
License: MIT-0 for code, CC-BY-4.0 for documentation unless otherwise stated.