Proxmox Bonding: Active-Backup vs LACP for Network Resilience

Setting Up Bonded Network Interfaces on Proxmox VE: How to Choose Between Active-Backup and LACP

You've installed Proxmox, your VMs are running, but now you need a more resilient network than the default single-NIC setup — so which bonding mode actually makes sense for your hardware? This guide walks through configuring both active-backup (failover) and 802.3ad LACP (link aggregation) modes on Proxmox VE, with practical guidance on when to pick each one based on what switch you have and how much throughput you need.

Key Takeaways

Bonding mode — Active-backup needs no special switch support; LACP requires an 802.3ad-capable switch for load balancing across ports
Failover behavior — active-backup provides instant failover with one working link, while LACP distributes traffic but can lose all connectivity if the wrong port fails during reconfiguration
Throughput ceiling — a single bonded pair gives you roughly double your NIC speed under ideal conditions regardless of mode; adding more ports scales linearly in LACP only
Configuration path — both modes work via /etc/network/interfaces on any Proxmox version, though the web UI offers direct control starting with 8.x

What Bonding Actually Does for You

A bonded interface combines two or more physical NICs into a single logical link. On Proxmox this means VM and container traffic can flow across multiple cables to your switch instead of being funneled through one port — reducing the blast radius when a cable gets pulled, an SFP fails, or you need extra bandwidth for replication between nodes in a cluster without upgrading individual NICs.

The two modes that matter most on Proxmox are:

Active-backup (mode 1) — One link carries traffic while others sit idle; if the primary fails, a backup takes over
802.3ad LACP (mode 4) — Multiple links carry traffic simultaneously with load distribution across all active ports

There's also round-robin and other modes available through bonding.ko, but they're rarely worth the complexity on Proxmox unless you have a specific reason to use them.

How to Choose Between Active-Backup and LACP

The decision usually comes down to three factors: what your switch supports, how much throughput you need beyond a single link's capacity, and whether losing all traffic during failover is acceptable for the setup phase.

Factor	active-backup (mode 1)	802.3ad LACP (mode 4)
Switch support required	No special configuration	Must enable LACP on ports, set to aggregator mode
Load balancing across links	No — only one active at a time	Yes — distributes flows via hash algorithm
Failover behavior	One link fails → another takes over immediately (sub-second)	Port removed from aggregation group; brief reconvergence (~5s with default miimon=100ms)
Max throughput scaling	Scales only if you add more bonded pairs or use multiple bridges	Scales linearly up to the number of NICs in the bond
Complexity	Simple — configure once and forget it	Moderate — switch config must match, verify with `ethtool` later

For a homelab running Home Assistant OS on Proxmox alongside Docker containers in LXC, active-backup is almost always sufficient unless you're doing heavy storage replication or backing up to an external NAS over the same bond. For a small datacenter with multiple nodes sharing iSCSI targets and Ceph traffic on separate VLANs (see Configuring VLANs on Proxmox with Linux Bridges for that part), LACP starts paying dividends around 5 Gbps of aggregate throughput.

Configuring Active-Backup Bonding via the CLI

The most reliable path across all versions is editing /etc/network/interfaces directly — it works whether you're on Proxmox VE 7.x, 8.x or 9.x and survives web UI changes in future releases.

First, identify your NICs:

ip link show | grep -E '^[0-9]|eth|enp'
# Example output:
# 2: eno1 <BROADCAST,MULTICAST> mtu 1500 ...
# 3: eno2 <BROADCAST,MULTICAST,UP,RUNNING> mtu 1500 ...

Edit the network config. Here's a complete example bonding eno1 and eno2:

cat > /etc/network/interfaces << 'EOF'
# The loopback interface
auto lo
iface lo inet loopback

# Physical interfaces — no IP, they're enslaved to bond0
auto eno1
iface eno1 inet manual
    bond-master bond0
    bond-mode active-backup
    bond-miimon 100

auto eno2
iface eno2 inet manual
    bond-master bond0
    bond-mode active-backup
    bond-miimon 100

# The bonded bridge (replace with your subnet)
auto vmbr0
iface vmbr0 inet static
    address 192.168.1.5/24
    gateway 192.168.1.1
    bridge-ports bond0
    bridge-stp off
    bridge-fd 0

# DNS and search domain (optional, managed by systemd-networkd in newer releases)
dns-nameservers 192.168.1.1
EOF

Apply the changes:

systemctl restart networking.service
ip addr show vmbr0 | grep 'inet'
bondinfo=$(cat /proc/net/bonding/bond0); echo "$bondinfo" | head -5
# Verify both slaves are up with active-backup mode
echo "Active Slave:"; echo "$bondinfo" | grep 'Current Active Slave:'

With miimon=100, the bond polls every 100 ms — so if you unplug one cable, failover happens in roughly that time. That's fast enough for most VM workloads and won't drop your RDP sessions to a Linux guest noticeably.

Configuring LACP (802.3ad) Bonding via the CLI

The structure is nearly identical — only bond-mode changes:

cat > /etc/network/interfaces << 'EOF'
auto eno1
iface eno1 inet manual
    bond-master bond0
    bond-mode 802.3ad
    bond-miimon 100
    bond-lacp-rate fast

auto eno2
iface eno2 inet manual
    bond-master bond0
    bond-mode 802.3ad
    bond-miimon 100
    bond-lacp-rate fast

auto vmbr0
iface vmbr0 inet static
    address 192.168.1.5/24
    gateway 192.168.1.1
    bridge-ports bond0
    bridge-stp off
    bridge-fd 0

dns-nameservers 192.168.1.1
EOF

Restart networking and verify the LACP negotiation:

systemctl restart networking.service
cat /proc/net/bonding/bond0 | grep -E 'Slave|LACP'
# Expected output includes both slaves with state "up" and LacpAggregator status
ethtool eno1 | grep Aggregated
ethtool eno2 | grep Aggregated

The bond-lacp-rate fast option tells each port to exchange LACP PDUs every second rather than the default 30 seconds — useful when you want faster detection of partner link changes. It's a minor detail but worth setting explicitly if your switch supports it (most managed switches do).

Configuring Bonding via the Web UI

If you'd prefer not to edit config files, Proxmox VE 8.x and later let you configure bonds through Datacenter → System → Network:

Create a new bond interface by clicking "Add" in the network tab
Select your two physical NICs as slaves — order doesn't matter for active-backup; it does affect initial load distribution under LACP (the first port tends to get slightly more traffic)
Choose mode = 802.3ad or mode = active-backup from the dropdown
Assign vmbr0 as a bridge on top of bond0, set your address and gateway

The UI writes /etc/network/interfaces for you — but I still recommend verifying the file afterward because there are edge cases where it omits bond-miimon or sets an unexpected default. A quick check after saving is worth the thirty seconds:

grep -A 10 'iface bond0' /etc/network/interfaces

Verifying Your Bond Is Working Correctly

Don't skip verification — I've seen too many "bonded" setups where only one port was actually active. Here's a checklist you can run after any configuration change:

Active-backup mode:

# Check which slave is currently carrying traffic
cat /proc/net/bonding/bond0 | grep 'Currently Active Slave'

# Force failover to test (swap the primary)
ip link set eno2 down && ip link set eno1 up
sleep 3; cat /proc/net/bonding/bond0 | grep -E 'Slave|Active'

LACP mode:

# Verify both ports are aggregating with your switch's LACP partner
ethtool -S eno1 | grep lacp_state
ethtool -S eno2 | grep lacp_state

# Watch for link state changes in real time — useful after a cable swap or reboot
tail -f /var/log/syslog | grep bond0

A quick sanity check: if your switch shows both ports active and aggregated (look at show lacp neighbor on Cisco, or equivalent on other vendors), you're good. If only one port is aggregating while the other sits idle in LACP mode, double-check that both ports have identical speed/duplex settings — mismatched MTUs are another common cause of silent failures under bonding.

A Practical Gotcha: Storage Traffic and Bond Selection

One thing people miss when they first set up bonded interfaces on Proxmox is how the Linux routing table interacts with multiple active links in LACP mode. If your storage (iSCSI, NFS, or Ceph) lives on a different subnet than your management network, you may want to pin that traffic to specific NICs using policy-based rules:

# Pin iSCSI traffic (10.20.30.x/24) through eno2 specifically
ip route add 10.20.30.0/24 dev eno2 src <eno2-ip> table storage_table
echo "from 10.20.30.0/24 lookup storage_table" >> /etc/sysctl.conf

# Apply immediately (requires sysfs-writeable kernel)
sysctl -p

This prevents the hash-based load balancer from occasionally sending a ZFS replication stream back through eno1 when you need it on eno2, which can cause transient latency spikes that show up as "stutter" in your storage benchmarks. I've seen this bite people running automated backup scripts across bonded links — the fix is simple once you know to look for it.

A Tradeoff Worth Naming: LACP Speed vs Switch Dependency

LACP gives you more throughput, but only if your switch supports 802.3ad correctly and all ports are configured identically (speed, duplex, VLAN membership). An active-backup bond on a $50 managed switch will outperform an improperly-configured LACP setup on a cheap unmanaged one — because in the latter case you might end up with both links "active" but sending traffic to different MAC addresses and dropping packets silently.

For homelab setups using consumer switches like Netgear GS324TP or even older Cisco SG300 models, I usually recommend starting with active-backup unless throughput is genuinely a bottleneck. You can always migrate to LACP later — the bonding mode change itself takes about two minutes and involves editing one line in /etc/network/interfaces.

Conclusion

Bonded interfaces on Proxmox VE are straightforward once you know which mode matches your hardware, but verifying that verification after configuration saves hours of troubleshooting down the road. Pick active-backup for simplicity and guaranteed failover; choose LACP when throughput matters more than switch compatibility. If networking is new territory for you, start with Configuring VLANs on Proxmox with Linux Bridges first — bonding works best when your bridge topology is already clean. For the next step after getting your bond up and running, consider automating regular health checks so you catch degraded links before they become outages: Automate Proxmox VE with Ansible Full VM Playbooks ties nicely into this setup.