Network Bonding (LACP) in Proxmox VE: Setup Guide

Introduction

A Proxmox VE host with a single network cable has a single point of failure. Pull that cable, or lose the switch port it's plugged into, and every VM and container on that node drops off the network at once — even though the host itself is still running fine. For a homelab that might mean a dropped Plex stream. For a small business running invoicing, file shares, or a hypervisor cluster's own management traffic, it means downtime that didn't need to happen.

The fix most enterprise networking teams reach for is bonding (also called link aggregation, NIC teaming, or — when done against a switch — LACP). Instead of one physical NIC feeding one bridge, you combine two or more physical NICs into a single logical interface. Lose one link and traffic keeps flowing over the survivor, usually without a single dropped ping.

Proxmox VE has first-class support for Linux bonding built into both the web GUI and the underlying /etc/network/interfaces configuration. This guide covers what bonding actually does, which of the seven supported modes to pick for your situation, and how to build a bonded interface step by step — through the GUI and by hand — then verify it's actually protecting you before you trust it in production.

What You Will Learn

What network bonding is and how it differs from a VLAN-aware bridge or SR-IOV
The seven bond modes Proxmox VE supports, and which ones actually need switch-side configuration
How to create a bond through the Proxmox web GUI
How to create and edit a bond directly in /etc/network/interfaces
How to attach a bond to a Linux Bridge (including a VLAN-aware bridge) so VMs can use it
How to verify bond status and actually test failover before you rely on it
Common misconfigurations that make a bond look fine until the moment it isn't

What Is This Feature?

Bonding takes two or more physical network interfaces — say eno1 and eno2 — and presents them to the rest of the system as one interface, typically named bond0. The kernel's bonding driver decides how traffic gets spread across the underlying NICs and, critically, what happens when one of them goes down.

Proxmox VE supports the standard Linux bonding modes:

balance-rr (mode 0) — Round-robin. Packets go out sequentially across each slave NIC. Gives load balancing and fault tolerance, but out-of-order packet delivery can hurt some workloads.
active-backup (mode 1) — Only one NIC is active at a time; the other sits idle until the active link fails, then takes over. No special switch configuration needed. This is the safest default if your switch doesn't support LACP.
balance-xor (mode 2) — Distributes traffic across slaves based on a hash of source/destination MAC (or IP, depending on the hash policy). Requires static switch-side link aggregation, but not LACP negotiation.
broadcast (mode 3) — Transmits every packet out every slave. Maximum fault tolerance, minimum efficiency. Rarely used outside specific fault-tolerance testing.
802.3ad / LACP (mode 4) — The industry-standard dynamic link aggregation protocol. NICs and switch negotiate the aggregation automatically. This is the mode most production deployments want, if the switch supports it.
balance-tlb (mode 5) — Adaptive transmit load balancing. Balances outgoing traffic based on current load per slave, no switch configuration required. Incoming traffic still goes to a single active NIC.
balance-alb (mode 6) — Adaptive load balancing. Extends balance-tlb with receive load balancing achieved through ARP negotiation, still without needing managed-switch support.

The distinction that trips people up most is between modes that require the switch to know a bond exists (balance-xor, 802.3ad) and modes that don't (active-backup, balance-tlb, balance-alb). Get this wrong — for example, configure 802.3ad on the Proxmox side while the switch ports are just plain access ports with no port-channel or LAG group defined — and you won't get an error. You'll get a bond that appears "up" but silently drops or duplicates a chunk of your traffic.

Why Would You Use It?

The most common driver is redundancy. If a NIC dies, a cable gets unplugged, or a switch port flaps, active-backup or LACP bonding keeps the host reachable and VMs online with no manual intervention. For a single-node homelab this means you stop losing your whole setup to a bad Ethernet cable. For a clustered Proxmox VE deployment, it protects the corosync and migration traffic paths from a single link failure taking a node out of quorum.

The second driver is throughput. Modes like balance-rr, balance-xor, and 802.3ad can spread traffic from multiple simultaneous connections across several physical NICs, which is useful if you're pushing more traffic than a single 1GbE or 10GbE link can carry — for example, several VMs doing simultaneous backups to a PBS server, or NFS/iSCSI storage traffic sharing a link with VM traffic.

It's worth being clear about what bonding does not do: a single TCP stream between two hosts will not automatically go faster because you bonded two NICs together. Standard hash-based load balancing keeps a given flow pinned to one physical link so packets don't arrive out of order — the benefit shows up in aggregate throughput across many simultaneous connections, not in a single file transfer's speed.

Bonding is also a different tool from two other Proxmox VE networking features you may have already read about: a VLAN-aware bridge segments traffic logically over a link you already have, and SR-IOV hands a VM a slice of NIC hardware directly for near bare-metal throughput to a single guest. Bonding operates one layer below both of those — it's about how many physical wires feed the bridge in the first place, and what happens when one of them fails. In practice, a bonded pair of NICs feeding a VLAN-aware bridge is a very common combination: redundancy at the physical layer, segmentation at the logical layer.

Prerequisites

A Proxmox VE host with at least two physical network interfaces available for the bond (a dedicated management NIC can stay separate if you prefer)
Root or a user with sufficient privileges to edit host networking (Sys.Modify permission at minimum)
Physical cabling from both NICs to your switch — for 802.3ad/LACP or balance-xor, both cables must land on ports that are part of the same LAG/port-channel/EtherChannel group on the switch
If you're using LACP: administrative access to your switch to create the LAG group, or confirmation from whoever manages it that it's already configured for the ports you're using
Out-of-band access to the host (IPMI, iKVM, or physical console) is strongly recommended before you touch networking, in case a mistake takes you off the network

Step-by-Step Tutorial

Step 1: Plan your bond mode and gather NIC names

Decide which mode fits your environment before you touch anything:

Unmanaged switch, or you don't control switch-side configuration → active-backup
Managed switch, LACP available, and you want both redundancy and aggregate throughput → 802.3ad
Managed switch without LACP support but with static link aggregation → balance-xor
You want load spreading with zero switch configuration and can accept asymmetric behavior on inbound traffic → balance-tlb or balance-alb

Identify the interface names for the NICs you're bonding. In the Proxmox GUI, go to Node → System → Network and note the names (typically eno1, eno2, enp3s0, etc. under modern predictable naming). You can also run:

ip -brief link show

from the host shell to list every physical interface and its current state.

Step 2: Create the bond through the Proxmox GUI

In the web UI, select your node, then go to System → Network.
Click Create → Linux Bond.
In the dialog, set:
- Name: Proxmox will suggest bond0 — leave it unless you already have one.
- IP address / Subnet mask: leave blank if this bond will feed a bridge (the bridge holds the IP, not the bond). Set an IP only if the bond itself is meant to carry management traffic directly.
- Slaves: check the two (or more) physical NICs to include, e.g. eno1 eno2.
- Mode: choose from the dropdown — Active-Backup, LACP (802.3ad), Balance-XOR, etc.
- Hash policy: only relevant for 802.3ad and balance-xor. layer2+3 is a reasonable default; use layer3+4 if you need finer-grained distribution across many connections to the same pair of hosts.
Click Create. The bond now shows up in the interface list with a status of "Pending changes" (indicated in yellow) until you apply it.

Step 3: Create the bond by editing /etc/network/interfaces (CLI method)

If you prefer editing the config directly, or you're scripting a deployment, open the file:

nano /etc/network/interfaces

Add a stanza like this for an 802.3ad/LACP bond:

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

For active-backup, the stanza is simpler and needs no hash policy:

auto bond0
iface bond0 inet manual
    bond-slaves eno1 eno2
    bond-miimon 100
    bond-mode active-backup
    bond-primary eno1

bond-primary is optional for active-backup — it tells the driver which NIC to prefer as active when both are healthy, which matters if one link is faster or has a shorter path than the other.

Step 4: Attach the bond to a bridge

The bond itself doesn't carry an IP in most setups — it feeds a Linux Bridge, which is what your VMs and the host's own management interface actually connect to. Edit (or create, via GUI Create → Linux Bridge) the bridge stanza so its bridge port is the bond, not a raw NIC:

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

If you're also using VLANs, add bridge-vlan-aware yes to the same stanza — bonding and VLAN-aware bridges compose without any special handling. The bond doesn't know or care about VLAN tags; it just moves frames, tagged or not, across whichever physical link is currently selected by the bonding driver.

Step 5: Apply the configuration and verify

From the GUI, click the Apply Configuration button at the top of the Network panel — Proxmox VE uses ifupdown2, which can apply most network changes live without a reboot. From the CLI, the equivalent is:

ifreload -a

Confirm the bond came up and check which slave is currently active:

cat /proc/net/bonding/bond0

This shows the bonding mode in effect, the MII status of each slave, and — for active-backup — which interface is currently the active one. You should see something like:

Bonding Mode: fault-tolerance (active-backup)
Currently Active Slave: eno1
MII Status: up

Slave Interface: eno1
MII Status: up

Slave Interface: eno2
MII Status: up

Also confirm the interface is up at the link level:

ip link show bond0

and, if you used 802.3ad, verify LACP is actually negotiated (not just link-up) by checking for Aggregator ID entries in the same /proc/net/bonding/bond0 output — every slave should share the same aggregator ID if the switch has actually formed the LAG.

Step 6: Test failover before you trust it

A bond that has never been failure-tested is a bond you're guessing about. With a VM or ping running against the host's management IP, physically unplug one of the bonded NICs (or disable the switch port) and watch for dropped packets:

ping -i 0.2 192.168.1.10

For active-backup, expect a handful of dropped pings during the failover window (typically under a second, governed by bond-miimon) and then full recovery. For 802.3ad, a well-configured LAG should show minimal to no loss since both links were already active. Re-check /proc/net/bonding/bond0 during the outage — the failed slave should show MII Status: down while the surviving slave keeps traffic flowing. Plug the cable back in and confirm the recovered NIC rejoins the bond (Linux bonding rejoins automatically once the link comes back up; it doesn't require manual re-enable).

Commands Explained

ip -brief link show — lists all network interfaces with a short summary of their state, useful for finding physical NIC names before you build a bond.
bond-slaves eno1 eno2 — declares which physical interfaces belong to the bond; order does not imply priority except when combined with bond-primary.
bond-miimon 100 — sets the link-monitoring interval in milliseconds. The bonding driver polls the link state of each slave every 100ms and reacts to a failure within roughly that window.
bond-mode 802.3ad — sets the bonding algorithm; this is the parameter that determines whether the switch needs to be configured to match.
bond-xmit-hash-policy layer2+3 — controls how outgoing traffic is distributed across slaves for hash-based modes (802.3ad, balance-xor); it has no effect in active-backup.
bond-primary eno1 — for active-backup only, sets which slave is preferred as the active link when more than one slave is healthy.
ifreload -a — Proxmox VE's ifupdown2 command to apply changes from /etc/network/interfaces without a full reboot.
cat /proc/net/bonding/bond0 — the authoritative source of truth for a bond's current mode, active slave, and per-slave link status.

Common Errors

Bond shows "up" but half your traffic disappears. Almost always a mode mismatch — 802.3ad or balance-xor configured on the Proxmox side against switch ports that were never grouped into a LAG/port-channel. Linux bonding modes that require switch cooperation don't fail loudly when that cooperation is missing; they just misbehave.
"Interface eno2 already in use" when creating the bond via GUI. The NIC is still referenced by an existing bridge or VLAN interface. Remove it from that configuration first, then add it to the bond.
Bond forms but LACP never negotiates (no Aggregator ID shown). Check that the switch ports are administratively enabled for LACP and not set to static/manual port-channel mode, which uses a different negotiation (or none at all).
Management access lost after applying changes. This is the classic risk of doing this over SSH/GUI rather than console. Prefer ifreload -a over a full network restart, and keep an out-of-band console session open the first time you change the interface a management IP depends on.
Corosync cluster traffic becomes unstable after moving it onto a bond. Corosync has its own built-in redundancy via multiple ring/link definitions and does not always behave well layered on top of certain bonding modes, particularly balance-rr's reordering behavior. Proxmox's own guidance is to prefer separate physical links for corosync rather than relying on a bond to protect cluster communication.

Troubleshooting

If a bonded interface isn't behaving as expected, work through these checks in order:

Confirm both physical links are actually up at the switch and cable level with ethtool eno1 and ethtool eno2 — look at the Link detected line.
Check the bonding driver's own view with cat /proc/net/bonding/bond0. If a slave shows MII Status: down but ethtool says the link is up, the problem is usually miimon polling being disabled or misconfigured, not the cable.
For 802.3ad specifically, confirm both peer switch ports report the same LAG/port-channel group and that spanning-tree isn't blocking one of them — a port stuck in STP blocking looks identical to a dead cable from the bond's perspective.
Check for duplicate MAC address issues if you're running balance-alb or balance-tlb behind a switch with strict port security or DHCP snooping — these modes manipulate ARP and MAC behavior in ways some switch security features flag as spoofing.
Verify the bridge is actually using the bond, not one of the raw NICs, by checking bridge-ports in /etc/network/interfaces — a common mistake is creating the bond correctly but leaving the bridge pointed at the original single NIC.
Roll back safely if you're locked out: boot to the console, edit /etc/network/interfaces back to the known-good single-NIC configuration, and run ifreload -a (or reboot as a last resort).

Best Practices

Match your switch configuration to your chosen mode before applying the Proxmox side — for 802.3ad and balance-xor, create the LAG/port-channel on the switch first so the bond negotiates correctly the moment it comes up.
Default to active-backup when you're not certain the switch is configured correctly, or when the switch is unmanaged. It's the only mode that is guaranteed correct with zero switch-side setup.
Keep corosync/cluster traffic on separate, dedicated links rather than layering it on top of a bond meant for VM traffic — use Proxmox's multi-ring corosync configuration for cluster redundancy instead.
Set bond-miimon explicitly (100ms is a sane default) rather than relying on defaults, so failover timing is predictable.
Label physical cables and switch ports before you start. When you're troubleshooting a bond at 2am, knowing which cable is eno1 versus eno2 without guessing saves real time.
Always test failover deliberately (unplug a cable, disable a switch port) in a maintenance window rather than assuming the bond works because it shows "up."
If you're bonding NICs of different speeds (e.g., a 1GbE and a 10GbE port), be aware most modes assume equal-speed links; mixed speeds work for active-backup but will produce uneven or unexpected results in load-balancing modes.

Frequently Asked Questions

Do I need a managed switch to use bonding in Proxmox VE?

No — active-backup, balance-tlb, and balance-alb all work with a plain unmanaged switch, since they don't require the switch to know a bond exists. Only 802.3ad (LACP) and balance-xor need switch-side link aggregation configuration.

Will bonding two 1GbE NICs give me 2Gbps for a single file transfer?

No. Hash-based load-balancing modes keep a single connection (flow) pinned to one physical link to avoid out-of-order packets. The extra bandwidth shows up when multiple simultaneous connections are in play — several VMs transferring data at once, for example — not within a single stream.

Can I bond NICs that are also used for SR-IOV virtual functions?

No — an SR-IOV-enabled physical function is meant to be passed through directly to guests via its virtual functions, which is a fundamentally different path than a bond feeding a Linux bridge. Pick one approach per physical NIC pair depending on whether you need redundancy for bridged traffic or raw passthrough performance for specific VMs.

What happens to a bond during a Proxmox VE upgrade or host reboot?

Nothing special — the bond configuration lives in /etc/network/interfaces and is brought up the same way any other interface is during boot, before Proxmox services start. It survives upgrades and reboots exactly like your bridge or static IP configuration does.

Should I bond the NICs used for Ceph or storage replication traffic?

Generally yes for redundancy, but treat throughput expectations carefully — for Ceph specifically, dedicated higher-speed links (10/25GbE) without bonding overhead are often preferred for the public/cluster networks, with bonding reserved for VM-facing bridges. If you do bond storage-network NICs, 802.3ad with a layer3+4 hash policy generally distributes iSCSI/NFS sessions more evenly than layer2+3.

Conclusion

Network bonding is one of the highest-value, lowest-cost changes you can make to a Proxmox VE host's resilience — it costs a second NIC and a bit of cabling, and it turns a single point of failure into something that can survive a dead port, a bad cable, or a flapping switch link without anyone noticing. The GUI makes basic setup straightforward, but the part worth doing carefully is matching your bond mode to what your switch actually supports, and then proving the failover works by pulling a cable yourself rather than assuming it will. Once that's confirmed, a bonded interface is something you can genuinely stop thinking about — which is exactly the point.

Vormox is an independent virtualization management platform built on Proxmox VE. Proxmox® and Proxmox VE® are trademarks of Proxmox Server Solutions GmbH. Vormox is not affiliated with, endorsed by, or sponsored by Proxmox.

How to Configure Network Bonding (LACP) in Proxmox VE for NIC Redundancy