Proxmox VE SDN: Zones, VNets and Overlay Networks

Before SDN, adding a network to a Proxmox cluster meant editing /etc/network/interfaces on every node and hoping nothing drifted. The SDN stack centralises that: a zone defines the isolation technology, a VNet is the logical network inside it, and subnets add gateway and DHCP scope. Configuration lives in /etc/pve/sdn, replicated across the cluster, and it has been fully supported since Proxmox VE 8.1. This guide covers the zone types that matter and the mistakes that cost the most time.

Choosing a zone type

• Simple - an isolated bridge per node with no cross-node connectivity; genuinely useful for NAT or routed lab networks.
• VLAN - 802.1Q tagging on an existing Linux or OVS bridge, giving consistent segmentation across nodes.
• QinQ - stacked tags (802.1q or 802.1ad) where the zone owns the service VLAN and the VNet owns the inner tag; the physical switches must support it.
• VXLAN - layer 2 over UDP with a static peer list, for stretched clusters on routed IP fabrics.
• EVPN - VXLAN plus a BGP control plane via FRRouting, so peer discovery and inter-VNet routing come from the fabric instead of a manual list.

At the node level, remember the VNet is just a bridge; the bonding and VLAN work still happens underneath, as described in Proxmox VE Networking: VLAN-Aware Bridge and LACP.

Creating zone, VNet and subnet from the CLI

pvesh create /cluster/sdn/zones --zone myvlanzone --type vlan --bridge vmbr0
pvesh create /cluster/sdn/vnets --vnet myvnet1 --zone myvlanzone --tag 10
pvesh create /cluster/sdn/vnets/myvnet1/subnets   --subnet 10.100.10.0/24 --gateway 10.100.10.1   --dhcp-range start-address=10.100.10.100,end-address=10.100.10.200
pvesh set /cluster/sdn

The --tag is the VLAN ID for VLAN/VXLAN zones and the inner tag for QinQ. Nothing takes effect until the SDN configuration is applied -- pvesh set /cluster/sdn in the CLI, or Apply in Datacenter > SDN > Options. Assigning a VNet to a VM before applying it is the most common "network does not exist" report.

VXLAN specifics: MTU and peers

pvesh create /cluster/sdn/zones --zone vxzone1 --type vxlan   --peers 10.0.0.1,10.0.0.2,10.0.0.3 --mtu 1450
pvesh create /cluster/sdn/vnets --vnet prod-net --zone vxzone1 --tag 100100

VXLAN adds encapsulation overhead, so the zone MTU must be lower than the underlay MTU: 1450 on a 1500-byte fabric, 8950 on a jumbo-frame fabric. Every VTEP must reach every peer in the list; asymmetric or missing peer entries produce inter-node silence that looks like a broken bridge.

EVPN with an FRR controller

pvesh create /cluster/sdn/controllers --controller evpnctl --type evpn   --asn 65001 --peers 10.0.0.1,10.0.0.2,10.0.0.3
pvesh create /cluster/sdn/zones --zone evpnzone --type evpn   --controller evpnctl --vrf-vxlan 4000
pvesh set /cluster/sdn
pmxconfig ? ; # verify with:
vtysh -c "show bgp l2vpn evpn summary"

The VRF VXLAN ID must differ from every VNet's tag, and --exitnodes is required when you want inter-VNet routing to leave through specific nodes.

Verification

• ip -d link show type bridge on each node - the VNet bridges should exist with the expected VLAN filtering.
• bridge fdb show dev vxlan* - remote MACs should appear, proving tunnel learning works. If you need to reach a routed segment, the FHRP patterns in Proxmox VE Linux bridge VLAN configuration handle the gateway side.
• For simple zones, remember the built-in dnsmasq must be running, or disable it and supply DHCP elsewhere.

Related reading on this site: Proxmox VE Networking: VLAN-Aware Bridge and LACP and Proxmox VE Network: VLANs on Linux Bridges.

原文链接：https://pve.proxmox.com/pve-docs/chapter-pvesdn.html