One cable, many separated networks
A VLAN adds a 4-byte 802.1Q tag (VLAN ID, 1–4094) to the Ethernet frame. Switches and hosts treat traffic with different tags as if it flowed through physically separate networks — devices in VLAN 10 don't directly see devices in VLAN 20, even though they share the same switch and the same uplink cable.
A port carrying several tagged VLANs at once (e.g. the uplink from a Proxmox host to a switch) is called a trunk. A port permanently assigned to a single VLAN, delivering untagged traffic to an end device, is an access port. Untagged traffic lands in the port's native VLAN (PVID).
A VLAN is layer-2 separation. For segments to communicate, traffic must pass through a router or firewall (layer 3) — the natural place for rules and access control between zones.
Tag on the bridge, not on sub-interfaces
Proxmox offers two approaches to VLANs. The recommended and most maintainable is the VLAN-aware bridge: a single vmbr0 bridge with VLAN support enabled covers all segments, and you assign the VLAN number per machine in the NIC configuration.
- VLAN-aware bridge: one bridge for all VLANs, tag set in the "VLAN Tag" field of the VM/container NIC. Clean, scalable and easy to audit.
- Traditional sub-interfaces: separate interfaces
eno1.10,eno1.20and a separate bridge per VLAN. It works, but the configuration multiplies quickly. - What to avoid: tagging inside the guest while also tagging on the host — accidental double tags (QinQ) are a classic source of "the network just won't work".
On the switch side, the port to the host must be a trunk passing all the VLAN IDs in use. This is the most common point of failure: the host tags correctly, but the switch drops unknown VLANs.
A VLAN-aware bridge step by step
Enable the VLAN-aware bridge in the UI (Node → System → Network → select vmbr0 → "VLAN aware") or directly in /etc/network/interfaces:
| Element | Configuration |
|---|---|
| VLAN-aware bridge | bridge-vlan-aware yes + bridge-vids 2-4094 |
| VLAN for a VM | Hardware → Network Device → VLAN Tag = e.g. 10 |
| VLAN for an LXC container | Network → VLAN Tag in the interface config |
| Management address in a VLAN | sub-interface vmbr0.99 with the host IP |
| Check the tags | bridge vlan show |
For uplink redundancy, bond the links into a bond (LACP 802.3ad) and put the VLAN-aware bridge on the bond instead of a single NIC — you get both link-failure resilience and full VLAN segmentation at once.
Keep the Proxmox management network in a different VLAN from production VM traffic. It's a simple change that significantly reduces the attack surface on the host interface and the cluster.
VLAN rules on a Cumulus Linux switch
The NVIDIA SN4700 switch (Spectrum-3, 32× 400 GbE ports) ships by default with Cumulus Linux. That's a favourable scenario: Cumulus uses the exact same VLAN-aware bridge model as Proxmox, so you configure both ends of the trunk almost identically. On 5.x releases the standard CLI is NVUE (nv set); older versions used NCLU (net add), and underneath it always runs ifupdown2 with the /etc/network/interfaces file — the very same one used by Proxmox.
Assume a typical layout: port swp1 goes to the Proxmox host and should be a trunk carrying VLAN 10 (production), 20 (storage), 30 (DMZ) and 99 (management), while ports swp10–swp12 are access ports for a physical storage server (bare metal) sitting next to it, in VLAN 20. That way the VMs on Proxmox and the physical storage sit on the same L2 network (VLAN 20) and reach each other directly — without a router.
The access ports are an optional example for physical devices in the same VLAN (here: bare-metal storage in VLAN 20). If a given VLAN holds only virtual machines on Proxmox, you don't configure any access ports — the swp1 trunk alone is enough, since a VLAN "lives" on the network, not on the host.
By default, a port added to br_default becomes a trunk passing every VLAN on the bridge — exactly what a Proxmox host with a VLAN-aware bridge needs. Untagged traffic lands in the native VLAN (1 by default); management (VLAN 99) travels tagged, because on the host side it is received by the vmbr0.99 sub-interface.
For redundancy, bundle two ports into an LACP bond and add it to the bridge (with two SN4700 switches in MLAG — called CLAG on Cumulus — you configure the bond the same way on both):
Prefer editing the file directly? The same trunk in /etc/network/interfaces (ifupdown2 syntax, shared with Proxmox) looks like this:
Finally, verify the tags on both ends of the link. The universal bridge vlan show command works on both the switch and the Proxmox host; natively in NVUE you'd use:
The VLAN list and native VLAN must match on both ends of the trunk. Since Proxmox management arrives on the tagged vmbr0.99, keep VLAN 99 in the tagged set (bridge-vids) — don't set it as the untagged/PVID on the switch port, or you'll lose access to the host right after nv config apply.
What to keep in mind
- Switch trunk: a missing VLAN ID on the trunk is the most common cause of a "silent" network. Check the switch port configuration first.
- Native VLAN / PVID: decide deliberately what happens to untagged traffic. A native-VLAN mismatch between host and switch leads to hard-to-spot traffic leaks.
- MTU: the VLAN tag adds bytes to the frame. With jumbo frames (storage, Ceph) make sure the MTU is consistent across host, bond, bridge and switch.
- Proxmox firewall: a VLAN isolates layer 2, but rules between zones are still worth enforcing on the firewall — Proxmox has a built-in one that works per VM/container.
A VLAN is logical isolation, not encryption. For truly sensitive segments combine VLANs with a firewall and — where necessary — with physical separation or traffic encryption.
We'll design your Proxmox network
Trunks, VLAN-aware bridges, LACP bonds, management segmentation and the firewall — we'll move your network logic from VMware to Proxmox VE cleanly and safely.
⚡ Free consultation → LXC containers in Proxmox