Open vSwitch Bond and VLAN Trunk on Proxmox

Open vSwitch on Proxmox gives you a programmable datapath with LACP bonding, internal VLAN interfaces and RSTP, but it also enforces a rule that trips up almost everyone the first time: OVS and Linux networking primitives must not be mixed. A brief outage caused by adding a Linux VLAN onto an OVS bond is a rite of passage. This article covers the supported combinations, working /etc/network/interfaces examples, and how to verify the datapath before a VM depends on it.

The rule you must respect

OVS and Linux bonding, bridging and VLANs must not be mixed. Do not add a Linux VLAN to an OVS bond, and do not add a Linux bond to an OVS bridge. Everything inside a given stack must belong to that stack: OVS ports come from ovs_bonds, OVS VLANs from ovs_options tag=, and OVS bridges from ovs_type OVSBridge.

Bond plus bridge plus internal ports

auto lo
iface lo inet loopback

auto eth0
iface eth0 inet manual
    ovs_mtu 9000

auto eth1
iface eth1 inet manual
    ovs_mtu 9000

auto bond0
iface bond0 inet manual
    ovs_bridge vmbr0
    ovs_type OVSBond
    ovs_bonds eth0 eth1
    ovs_options bond_mode=balance-tcp lacp=active other_config:lacp-time=fast
    ovs_mtu 9000

auto vmbr0
iface vmbr0 inet manual
    ovs_type OVSBridge
    ovs_ports bond0 vlan50 vlan55
    ovs_mtu 9000

auto vlan50
iface vlan50 inet static
    ovs_type OVSIntPort
    ovs_bridge vmbr0
    ovs_options tag=50
    address 10.50.10.44
    netmask 255.255.255.0

auto vlan55
iface vlan55 inet static
    ovs_type OVSIntPort
    ovs_bridge vmbr0
    ovs_options tag=55
    address 10.55.10.44
    netmask 255.255.255.0
    ovs_mtu 9000

Two details are easy to get wrong. First, the bridge must list every port in ovs_ports even though each port already names the bridge — the cross-reference is required and the configuration silently fails to come up without it. Second, tagged internal ports carry the host's own traffic (cluster communication, storage in the example above), so a mistake in the tag puts management traffic on a VLAN nobody is watching.

Bond without a switch that speaks LACP

auto bond0
iface bond0 inet manual
    ovs_bridge vmbr0
    ovs_type OVSBond
    ovs_bonds eth0 eth1
    ovs_options bond_mode=balance-slb vlan_mode=native-untagged

auto vmbr0
iface vmbr0 inet manual
    ovs_type OVSBridge
    ovs_ports bond0 vlan1

auto vlan1
iface vlan1 inet static
    ovs_type OVSIntPort
    ovs_bridge vmbr0
    ovs_options vlan_mode=access
    address 192.168.3.5
    netmask 255.255.255.0
    gateway 192.168.3.254

balance-slb hashes by source and load rather than negotiating LACP, so it works against an unmanaged switch — at the cost of per-flow pinning, since a single flow never exceeds one member link.

Enabling RSTP and verifying

up ovs-vsctl set Bridge ${IFACE} rstp_enable=true

ovs-vsctl show
ovs-vsctl get Bridge vmbr0 rstp_status
for port in eth0 eth1 eth2 eth3; do
  echo "== $port"; ovs-vsctl get Port $port rstp_status
done
ovs-appctl bond/show bond0
cat /proc/net/bonding/bond0

ovs-appctl bond/show is the decisive check for bonding: it reports which members are active, the hash distribution and whether LACP negotiated. A bond that shows members as active but carries no LACP state means the switch side is misconfigured, and balance-tcp will silently behave like balance-slb until that is fixed.

MTU consistency

If you enable 9000-byte frames, every interface in the path — members, bond, bridge, internal ports, switch ports and the peer — must agree, and the internal ports are easy to forget. Verify end to end with ping -M do -s 8972 between nodes before assigning storage to the network. A half-configured jumbo frame deployment shows up as mysterious slowness rather than an outright failure, exactly as described for overlay networks in VXLAN MTU fragmentation and jumbo frames.

OVS also changes the failure profile of the host: a misconfigured bridge can strand the management interface. Keep serial or IPMI console access available before editing /etc/network/interfaces remotely, and stage changes so that reverting is a reboot rather than a rescue.

For the MTU behaviour of bridged and overlay traffic on the same host, see VXLAN MTU and fragmentation.

原文链接：https://pve.proxmox.com/wiki/Open_vSwitch