Subject: PVE 8.4 LXC Network Failure in Tagged VLAN on LACP Bond (ARP Issue) - Host Cannot Communicate via bondX.<VLAN_ID>
Hello Proxmox Community,
I'm facing a networking issue with LXC containers on several nodes after updating them from Proxmox VE 8.1.x to 8.4.x. The problem seems specific to tagged VLAN traffic over an LACP bond.
Environment:
Proxmox VE: 8.4.x (Problem occurred after update from 8.1.x where this setup worked)
Multiple nodes affected.
Network Setup:
2x Physical NICs configured in an LACP Bond (bond1, mode 802.3ad, MTU 9000).
Linux Bridge vmbr1 built over bond1, configured with bridge-vlan-aware yes.
Multiple tagged VLANs are used for VMs and LXCs on vmbr1.
Switch side: Corresponding LAG is configured with LACP, trunk mode, relevant VLANs allowed, MTU 9000.
Problem Description:
LXC containers configured with static IPs and attached to vmbr1 with a specific VLAN Tag (e.g., VLAN 2040) cannot reach their gateway.
Pinging the gateway from within these LXCs fails with Destination Host Unreachable, indicating an ARP resolution failure.
Crucially: KVM VMs configured on the same host, same bridge (vmbr1), and using the same problematic VLAN Tag (e.g., 2040) work correctly and can reach the gateway.
The issue started consistently after updating the nodes to PVE 8.4.
Host Network Configuration (/etc/network/interfaces):
(Showing relevant structure and the specific VLAN sub-interface/bridge used for testing)
JSON:
# --- बॉन्डिंग ---
auto bond1
iface bond1 inet manual
bond-slaves <phys_nic1> <phys_nic2>
bond-miimon 100
bond-mode 802.3ad
bond-xmit-hash-policy layer2+3
mtu 9000
# --- VLAN Sub-interface Example (for the problematic VLAN) ---
iface bond1.<VLAN_ID> inet manual # e.g., iface bond1.2040 inet manual
mtu 9000
# --- VLAN-aware Bridge ---
auto vmbr1
iface vmbr1 inet manual
bridge-ports bond1
bridge-stp off
bridge-fd 0
bridge-vlan-aware yes
mtu 9000
# --- Attempted Workaround Bridge (also failed) ---
auto vmbr<VLAN_ID> # e.g., auto vmbr2040
iface vmbr<VLAN_ID> inet manual # e.g., iface vmbr2040 inet manual
bridge-ports bond1.<VLAN_ID> # e.g., bridge-ports bond1.2040
bridge-stp off
bridge-fd 0
mtu 9000
# (Other VLAN sub-interfaces and host management bridges/IPs omitted for brevity)
Troubleshooting Steps Taken:
Confirmed gateway is up and configured correctly for the relevant VLAN.
Confirmed switch LAG configuration (LACP active, trunk, specific problematic VLAN allowed on the LAG interface, MTU 9000).
Disabled PVE firewall for LXC network devices -> No change.
Restarted LXC containers -> No change.
Checked cat /sys/class/net/vmbr1/bridge/vlan_filtering -> Shows 1.
Workaround Attempt: Created a traditional bridge (vmbr<VLAN_ID>) over the specific VLAN sub-interface (bond1.<VLAN_ID>). Configured LXC to use this bridge with no VLAN tag. -> This also failed with the same ARP failure.
Host Connectivity Test (Focusing on the problematic VLAN, e.g., 2040):
Added temporary IP to bond1.<VLAN_ID> on the PVE host.
ping -I bond1.<VLAN_ID> <Gateway_IP> -> FAILED (100% packet loss).
Added temporary IP to the workaround bridge vmbr<VLAN_ID> on the PVE host.
ping -I vmbr<VLAN_ID> <Gateway_IP> -> FAILED (100% packet loss).
ping -I vmbr<VLAN_ID> <LXC_IP_in_same_VLAN> -> WORKED.
Conclusion:
The fundamental issue appears to be that the Proxmox VE host itself cannot communicate externally via its LACP bonded interface (bond1) within specific tagged VLANs after the update to PVE 8.4. This failure occurs even when testing directly via the bond1.<VLAN_ID> sub-interface. Since the host has no outbound L2/L3 connectivity in that VLAN via the bond, LXC containers using that path also fail. The fact that KVM VMs do work suggests a difference in how veth (LXC) vs tap (KVM) interfaces interact with the bond/VLAN stack in PVE 8.4, or that the underlying bond1.<VLAN_ID> failure is intermittent or conditional in a way that affects LXCs more readily.
Question:
Is anyone aware of regressions or known issues in Proxmox VE 8.4.x (or associated kernel / ifupdown2 / networking components) regarding tagged VLANs over LACP bonds, particularly ones that might affect LXC containers differently from KVM VMs or break host-level communication via VLAN sub-interfaces on bonds? Any advice on further diagnosing why the host fails to communicate via bond1.<VLAN_ID> would be greatly appreciated.
Thank you!
Results: