Skip to content

Network design

HybridOps uses a single-hub hybrid fabric with Google Network Connectivity Center (NCC) as the connectivity hub. The current shipped baseline uses a static Hetzner VyOS routed edge pair as the public face of the Site-A routed domain toward GCP. The on‑prem VyOS edge then attaches behind that static edge pair as a routed spoke/site-extension layer, while Azure remains a cloud-native routed spoke. The design is implemented and verified through repeatable platform runs with evidence capture.

Topology summary

  • On‑prem: Proxmox SDN provides VLAN-backed tenant networks for platform services and workloads, with a VyOS routed edge on Proxmox.
  • Edges: A static Hetzner VyOS edge pair currently terminates the GCP HA VPN hub underlay; the on-prem VyOS edge extends the same routed domain behind it. Multi‑WAN remains additive.
  • Hub: GCP HA VPN + Cloud Router terminate BGP peers and attach to NCC.
  • Azure: Azure VPN Gateway peers with GCP Cloud Router for transitive reachability and DR/burst placement.

Routing and address contract

Addressing, ASNs, tunnel link networks, and route filters are defined in the network routing contract.

Primary topology

flowchart TB
  subgraph OnPrem["On‑prem (Site‑A)"]
    direction TB
    EDGE1["VyOS (on-prem edge)"]
    SDN["Proxmox SDN (VLAN VNets)"]
  end

  subgraph Hetzner["Hetzner transit edge"]
    direction TB
    HEDGEA["VyOS edge-a"]
    HEDGEB["VyOS edge-b"]
    CTRL["Shared control host"]
  end

  subgraph GCP["GCP hub"]
    direction TB
    HAVPN["HA VPN"]
    CR["Cloud Router (BGP)"]
    HUBVPC["Hub VPC"]
    NCC["NCC (hub)"]
    HAVPN --> CR --> HUBVPC --> NCC
  end

  subgraph Azure["Azure spoke"]
    direction TB
    AZGW["VPN Gateway (BGP)"]
    VNET["VNet (AKS/AVD/workloads)"]
    AZGW --> VNET
  end

  EDGE1 -. IPsec+iBGP site extension .-> HEDGEA
  EDGE1 -. IPsec+iBGP site extension .-> HEDGEB
  HEDGEA -. IPsec+eBGP .-> HAVPN
  HEDGEB -. IPsec+eBGP .-> HAVPN
  AZGW -. IPsec+BGP .-> CR

Design intent

  • Routing is explicit and filtered. Only approved prefixes are exchanged.
  • Kubernetes pod/service CIDRs are not advertised by default; exposure uses ingress/LB patterns unless a routed use case requires otherwise.
  • DR and burst are controlled routing/policy events with evidence and rollback steps defined in runbooks.

References