VLAN-aware bridge vs traditional bridge with vlan interfaces — which one for a mixed workload cluster?

[atlas32]

Hi all,

I'm setting up a new 3-node PVE 8.x cluster and I'm going back and forth on the
networking design. Hardware is generic 2x10GbE per node, LACP bond to a pair of
stacked switches.

I need to host VMs in roughly 12 different VLANs (mix of prod, dev, DMZ, mgmt).

Two options I'm evaluating:

1) Single VLAN-aware bridge (vmbr0) on top of bond0, then set the VLAN tag
directly on each VM's NIC in the GUI.

2) Traditional setup: bond0 -> bond0.10, bond0.20, ... -> one bridge per VLAN
(vmbr10, vmbr20, ...).

Option 1 is obviously cleaner and scales better, but I've read scattered reports
of issues with multicast / IGMP snooping on VLAN-aware bridges, and some people
still recommend option 2 for "production".

Is option 2 still relevant in 2026 with PVE 8.x, or is the VLAN-aware bridge now
the de-facto standard? Any gotcha I should know before committing?

Thanks

 

[g.fiore]

Following up on my own thread since I dug into this over the weekend, in case
it helps someone else hitting the same decision.

Short answer: in 2026, on PVE 8.x, VLAN-aware bridge (option 1) is the way to go
for 99% of cases. The old "one bridge per VLAN" pattern is legacy and only makes
sense in very specific edge cases.

Why option 1 wins:

- Scales linearly. Adding VLAN 250 doesn't require editing /etc/network/interfaces
and reloading — you just type "250" in the VM NIC config.
- Live migration is happier: VM NIC config is portable across nodes as long as the
bridge name matches.
- SDN integration (VLAN zones) builds on top of this model. If you ever move to
SDN, you're already aligned.

About the multicast / IGMP concerns: those reports were mostly from PVE 6.x days
and a couple of kernel regressions long since fixed. On current kernels, bridge
multicast snooping works fine. If you really run multicast-heavy workloads
(IPTV, some clustering protocols) you can still tune:

echo 0 > /sys/class/net/vmbr0/bridge/multicast_snooping

per-bridge, but it's rarely needed.

When option 2 still makes sense:

- You want strict isolation enforced at the bridge level (not just VLAN tagging) —
e.g. compliance reasons where "same bridge, different tag" is not acceptable.
- You're mixing bridges with very different MTUs.
- You need different STP / forwarding behavior per VLAN.

Config I ended up with (simplified):

auto bond0
iface bond0 inet manual
bond-slaves eno1 eno2
bond-miimon 100
bond-mode 802.3ad
bond-xmit-hash-policy layer3+4

auto vmbr0
iface vmbr0 inet static
address 10.0.0.11/24
gateway 10.0.0.1
bridge-ports bond0
bridge-stp off
bridge-fd 0
bridge-vlan-aware yes
bridge-vids 2-4094

Then in each VM NIC: bridge=vmbr0, VLAN Tag=<whatever>.

Hope this helps the next person Googling this.