Skip to content

VLAN Allocation Strategy

Status: Accepted — Defines a hierarchical VLAN scheme to isolate environments, management, observability, and lab traffic while leaving headroom for future expansion.

Context

HybridOps.Studio requires network segmentation to:

  • Isolate environments (development, staging, production)
  • Separate management traffic from workload traffic
  • Enable observability across all environments
  • Support network testing without impacting operations
  • Scale to additional environments without redesign

An initial flat network approach (single bridge, no VLANs) prevented proper isolation and made it difficult to apply environment-specific security policies.

Decision

Implement VLAN-based segmentation with hierarchical numbering:

VLAN Subnet Purpose
10 10.10.0.0/24 Management (GUI, SSH, IaC)
11 10.11.0.0/24 Observability (metrics, logs, dashboards)
12 10.12.0.0/24 Shared services / data (PostgreSQL, Redis, platform deps)
20 10.20.0.0/24 Development
30 10.30.0.0/24 Staging
40 10.40.0.0/24 Production
50 10.50.0.0/24 Lab/Testing (EVE-NG, experiments)
60–99 Reserved Future expansion

Proxmox acts as a VLAN-aware bridge with Layer 3 routing (see ADR‑0102 – Proxmox as Layer 3 Router).

Rationale

Ranges vs sequential numbering

  • VLAN 10–19: Platform plane (management, observability, shared services/data)
  • VLAN 20–29: Development (room for dev-specific segments)
  • VLAN 30–39: Staging (room for staging-specific segments)
  • VLAN 40–49: Production (room for prod-specific segments)
  • VLAN 50–59: Lab/Testing (isolated experiments)

Why dedicated VLANs instead of a single shared network

  • Environment isolation can be enforced via firewall
  • Blast radius of incidents is reduced
  • Traffic patterns are easier to reason about and observe
  • Network policies can evolve per environment without global impact

Why a specific Lab VLAN

  • Lab traffic (EVE‑NG, simulations) is isolated from all operational workloads
  • Experiments and chaos tests can be run without impacting production‑style services
  • Aligns with the separation between testing and operations in real environments

Why a shared services / data VLAN (VLAN 12)

  • Centralises stateful dependencies (for example PostgreSQL and Redis) behind a consistent trust boundary.
  • Prevents environment VLANs (dev/stage/prod) from implicitly becoming “shared service” networks.
  • Simplifies firewall policy: workloads can be granted least-privilege access to data services without broad inter-environment reachability.
  • Improves DR posture by treating stateful services as a dedicated tier with explicit replication and backup controls.

Consequences

Positive

  • Clear environment isolation with firewall enforcement (see ADR‑0103 – Inter‑VLAN Firewall Policy)
  • Management plane separation improves security posture
  • Unified observability without compromising isolation (see ADR‑0401 – Unified Observability with Prometheus)
  • Separates shared stateful services from workload VLANs, making access control and audit boundaries clearer.
  • Scales to additional environments without renumbering
  • VLAN numbers are self-describing and easy to recall
  • Separates shared stateful services from workload VLANs, making access control and audit boundaries clearer.

Negative

  • Requires VLAN-aware switching if extended beyond a single Proxmox host
  • More complex to reason about than flat networking
  • Firewall rules must be maintained for inter‑VLAN communication

Neutral

Alternatives Considered

Flat networking (single bridge)
Rejected. No isolation between environments. Increases the risk of lateral movement and accidental cross‑environment access.

By‑function VLANs (Windows/Linux/Management)
Rejected. Mixes development, staging, and production workloads within the same VLAN, which prevents environment-specific policy enforcement.

Highly granular VLANs (service‑per‑VLAN)
Rejected for this phase. Excessive operational overhead for current scope. Reserved ranges allow for future refinement if justified.

Implementation

References

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