Proxmox VE Networking: VLAN-Aware Bridge and LACP

Proxmox VE uses the plain Linux network stack, which is why its networking is both flexible and easy to get subtly wrong. The three building blocks are a bridge (a virtual switch), an optional bond (NIC aggregation) and optional VLAN tags - and most "VLANs do not work" reports trace back to a mismatched switch port or an IP address placed on an untagged bridge while the traffic is actually tagged. This guide covers the two designs that cover almost every deployment, plus the safe-apply workflow that keeps the management path reachable.

The Three Building Blocks

The bridge normally holds the host IP and the physical NIC behaves as a port on that virtual switch. An IP in the 192.168.10.0/24 range on an untagged bridge does not put the host on VLAN 10 - the VLAN tag does, and nothing else.

Design 1: VLAN-Aware Bridge (one bridge, many VLANs)

iface enp1s0 inet manual

auto vmbr0
iface vmbr0 inet static
        address 192.168.1.10/24
        gateway 192.168.1.1
        bridge-ports enp1s0
        bridge-stp off
        bridge-fd 0
        bridge-vlan-aware yes
        bridge-vids 10 20 30

Set the VLAN tag on each VM or container NIC and the traffic is tagged transparently. The switch port must be a trunk carrying the same VLANs - if the switch side is an access port, nothing will work no matter what the host does.

Design 2: LACP Bond Feeding the Bridge

iface enp1s0 inet manual
iface enp2s0 inet manual

auto bond0
iface bond0 inet manual
        bond-slaves enp1s0 enp2s0
        bond-mode 802.3ad
        bond-miimon 100
        bond-lacp-rate fast
        bond-xmit-hash-policy layer3+4

auto vmbr0
iface vmbr0 inet static
        address 192.168.1.10/24
        gateway 192.168.1.1
        bridge-ports bond0
        bridge-stp off
        bridge-fd 0
        bridge-vlan-aware yes

Two expectations to set correctly: LACP gives aggregate capacity across many flows and link resilience, but a single TCP stream still tops out at one member link's speed unless the hash spreads it. Configure the switch LAG before applying the host change, otherwise the bond comes up with only one member active.

Applying Changes Without Locking Yourself Out

# the GUI writes to a staging file: /etc/network/interfaces.new
ifreload -a                    # apply staged config live (ifupdown2)
ip -brief link
ip -brief address
ip route
bridge link
cat /proc/net/bonding/bond0

Proxmox stages changes and lets you apply them in one transaction precisely because a bad bridge definition cuts your management access. Prefer the GUI's Apply Configuration button or ifreload over bouncing interfaces by hand, and always keep a console or IPMI path open when changing the bridge that carries the management IP.

Common Failures and Their Cause

• VLANs do not reach other devices: the switch port is access, not trunk; or the VLAN is missing from bridge-vids.
• Bond has one active member: the switch LAG is missing or in the wrong mode, or member NICs are on different switches without MLAG.
• Guests lose network after a change: the bridge's port list or PVID changed; verify with bridge vlan show.
• Host unreachable after adding a bond: the management IP was on the physical NIC, which is now a port of the bond - move the IP to the bridge.

Related reading: Linux bonding modes: LACP and active-backup, ESXi vSwitch, port groups, VLAN and teaming and NetBox IPAM for prefixes, VLANs and IP addresses.

原文链接：Proxmox VE wiki: Network Configuration