Proxmox VE SDN with VLAN, VXLAN and EVPN zones

Start the decision with the physical network you already run, because that determines which zone types are cheap to operate. Ask whether you control the switch ports that carry traffic from each Proxmox VE node, and whether you can trunk tagged VLANs to every host through your normal change process. If you do, a VLAN zone is usually the simplest fit for tenant separation, since each tenant maps to a tagged network that your switches already understand. If tenants must carry their own tags inside a provider tag, evaluate QinQ, but confirm with your switch vendor that the hardware, MTU and tag handling support double tagging before you commit to it.

Next, count the tenants and write down the isolation promise you make to each of them. With VLAN-based zones, every tenant consumes identifiers on every trunk, so the tenant count sets the size of the design and the usable ID range must be confirmed in your switch configuration and in the SDN documentation for your Proxmox VE version. Then state precisely what the promise covers. Separate broadcast domains may be enough for internal teams, while tenants who must never reach each other, even through shared gateways, need additional controls. Those controls, including the distributed firewall, are covered in a sibling section and should be scoped now, not after tenants are live.

Choose VXLAN when the underlay is hard to change. If the switches belong to a network team with long change cycles, or the nodes sit across routed segments where trunking every VLAN is impractical, VXLAN carries tenant Ethernet inside UDP over the IP network you already have. The underlay then needs IP reachability between nodes and enough MTU for encapsulation overhead. The cost is a larger troubleshooting surface and an MTU plan that must hold on every path, so test the path MTU between all nodes before you create the zone.

EVPN is worth its added control-plane complexity when you need dynamic MAC and IP advertisement across many nodes, or when the tenant networks must integrate with a routed fabric that already speaks BGP. For a small cluster with few tenants, plain VXLAN is often easier to run and to debug. If you adopt EVPN, confirm that your team can operate BGP sessions and route policy. Treat IPAM and DHCP integrations as technology previews for this purpose: do not make them the only mechanism that keeps tenant addressing correct without a tested fallback.

Decide the zone type before creating any guests, because it constrains VNet and subnet design. A VNet belongs to a zone, so changing the zone later usually means rebuilding networks, re-attaching guest NICs and re-addressing workloads. Record the decision in a short design note: zone type, VLAN or VNI ranges per tenant, MTU, subnet plan, where gateways live, and who owns the switch configuration. Validate that record on a non-production cluster first. The no-subscription repository is described for testing and non-production use, so it suits that validation, while production clusters should use the enterprise repository with a valid subscription.

An SDN change in Proxmox VE is a cluster-level operation with per-node effects. Proxmox VE clusters use a multi-master design in which every node can perform all management tasks, and the Proxmox Cluster File System replicates configuration to all nodes in real time. The zones, VNets and subnets you define are therefore shared by the whole cluster. The network devices those definitions need, such as VLAN-aware bridges, VLAN subinterfaces or VXLAN tunnel endpoints, are still built on each host. A successful save on one node shows that the configuration replicated, but it does not show that every host applied it. Plan the change around that gap and treat the cluster-wide save as the first step of verification.

A practical routine starts with the apply itself. Confirm that the change finished without errors on each node, including the node where you made the edit. Then check each node's network state directly. On every host, confirm that the bridges, VLAN tags or VXLAN devices for the affected zone exist and match the intended configuration, and compare the output across nodes. Exact commands and apply behavior depend on your installed version, so confirm them in the administration guide for that release before you write the runbook. Next, test guest connectivity from more than one node. Place test guests on the VNet on different hosts and check gateway reachability, traffic between them and paths that leave the VNet. A path may work from one host and fail from another, especially where traffic crosses tunnels between nodes.

Record every change in change control before you close it. Capture the configuration diff, the time of the apply, the nodes checked, the method used for each check, the connectivity test results and the name of the person who approved the change. Note which nodes were healthy before the change, because a change made while a host is already out of sync is hard to diagnose later. Record the rollback path as well: which configuration to restore, in what order, and how you will confirm each node returned to its prior state. Keep this record with your cluster documentation so the next engineer can see what the network looked like before and after the change.

This is where verification connects to high availability. When a node fails, HA recovery restarts its guests on surviving nodes, and those guests keep working network access only if the target node has applied the SDN configuration correctly. A node with a stale or failed network apply can restart a guest that boots but cannot reach its network, which can look like a successful recovery in the HA view. Proxmox VE HA needs at least three cluster nodes for reliable quorum, shared storage for guests and watchdog-based fencing so a failed node is reset before its guests are recovered elsewhere. After each SDN change that touches a VNet used by HA-managed guests, run a planned failover test in a maintenance window and confirm that the guest starts on another node with working connectivity. Decide in advance who owns that test and what blocks the next change if it fails.

Defining a subnet in Proxmox VE SDN tells the cluster which addresses exist. It does not settle who hands those addresses out, which system records them, or what happens when two tenants want the same range. Before you create VNets and subnets for your zones, make three decisions in writing: who assigns guest addresses, whether an external DHCP or IPAM system is the source of truth, and how overlapping address space will be handled across tenants. These choices affect the zone design, so they belong in the initial plan and should be settled before the first guest is attached. A VNet that isolates traffic at Layer 2 does not, by itself, make identical subnets safe to route or to resolve by name.

Start with address assignment. Guests can be configured statically by their owners, receive leases from a DHCP server outside the cluster, or use DHCP and IPAM components built into Proxmox VE SDN. Each option determines where lease records live and which service answers when a guest asks for an address. If an external system is the source of truth, the SDN subnet should not act as a second writer for the same ranges, or you will get conflicting records. Ask your network team who owns reservations, DNS registration and cleanup when a guest is retired. Also confirm that DHCP requests reach the guest after a live migration or an HA restart on any node that may host it, because a relay or broadcast domain that works on one node may not work on another.

Overlapping address space is the decision teams most often postpone. If two tenants both use the same private range, the cluster can keep their VNets separate at the bridge level, but the overlap becomes a problem as soon as a shared firewall, load balancer, monitoring host or DNS resolver sits in the path. Decide whether tenants receive unique ranges from a central allocation, whether NAT is applied at the edge, or whether each tenant gets a separate routing domain, and who approves exceptions. Confirm with your network design how the VXLAN or EVPN zone you select carries routes for overlapping prefixes. The answer depends on routing outside the cluster as much as on the subnet object inside it.

Some IPAM and DHCP components in Proxmox VE SDN may still be technology previews. Preview features can change between releases and may not cover every option you would use in production. Before you rely on them, confirm the current preview status, the supported features and any known limitations in the exact release you plan to run, and check those notes again before each upgrade. You have two sound paths: run the built-in components in production with a tested rollback plan, or keep an external system as the system of record and use the built-in components only where their support statement covers your use. Document which path you chose and the reason for it, so the decision can be reviewed when the release changes.

Turn these choices into a short addressing record before the first zone is created. Include the owner of each subnet, the system that issues each lease, the reservation process, the overlap policy and the steps for retiring addresses. Then test the design against real failure paths. Run a guest that renews its lease, migrate it to another node, restart it under HA and confirm that it keeps the expected address and name. Test what happens when the external IPAM or DHCP service is unreachable. If you bring in an implementation partner, ask for these tests to be listed as separate items in the written scope so the cost and effort of validation are visible before work starts.

Before you choose between Simple, VLAN, QinQ, VXLAN and EVPN zones, check what the vendor documents as supported for the exact Proxmox VE release you plan to run. Start with the Proxmox VE product overview, which describes the platform and what it integrates, including software-defined networking. Then read the introduction chapter of the Proxmox VE administration guide, which explains the cluster, storage and networking model that SDN builds on. Both come from Proxmox Server Solutions, and together they give you the baseline for what the platform is meant to do in production.

Next, locate the SDN chapter in the administration guide for your target version and read the release notes for that same release. Proxmox VE 9.0 shipped on Debian 13 on August 5, 2025, 9.1 followed on November 19, 2025, and 9.2 was released on May 21, 2026. Those dates tell you when each release arrived, but the release notes tell you what changed in SDN, such as zone types, VNet handling, subnet options or controller settings. Record the version, the Debian base it sits on, and any SDN change that affects the zones you are considering. If you plan to use a release not listed here, confirm the same points in its notes.

Then check the preview status of each component in the design. The topic scope identifies IPAM and DHCP as technology previews, so confirm that status in the SDN chapter for your version rather than relying on this summary. Apply the same check to every zone type, controller and integration you intend to use. For each component, record whether it is documented as supported, marked as a preview, or not covered, along with the section you read. If a component is a preview, decide whether the design still works without it, and accept in writing that its behavior may change before it is stable.

Write the answers into the design document. Include the Proxmox VE version, the date you checked, the preview status for each component, and the documentation sections you relied on. This page summarizes design choices and does not replace the vendor documentation. If this page and the documentation for your version disagree, the documentation governs, and the design should be updated to match. Repeat the same checks before any upgrade, because supported behavior and preview status can change between releases, and a design approved on one version needs a fresh review on the next.