How to Configure Network Bonding on Linux

Network bonding combines multiple physical network interfaces into a single logical one — used for failover redundancy, aggregated throughput, or both, depending on which bonding mode is selected.

Step 1: understand the common bonding modes before choosing one

mode=active-backup  — one interface active, the other standing by
                       purely for failover; no throughput gain
mode=802.3ad (LACP)  — link aggregation requiring switch-side
                        support; combines bandwidth of all links
mode=balance-rr      — round-robin across interfaces; needs no
                        special switch config but can reorder packets

Choosing the wrong mode for your actual goal (redundancy vs. throughput) is the most common source of “bonding isn’t doing what I expected.”

Step 2: check available interfaces

nmcli device status

Step 3: create the bond

sudo nmcli connection add type bond con-name bond0 ifname bond0 bond.options "mode=active-backup,miimon=100"

miimon=100 checks link state every 100ms — necessary for the bond to actually detect a failed link and fail over promptly.

Step 4: add physical interfaces as bond members

sudo nmcli connection add type ethernet slave-type bond con-name bond0-port1 ifname eth0 master bond0
sudo nmcli connection add type ethernet slave-type bond con-name bond0-port2 ifname eth1 master bond0

Step 5: configure the bond’s IP addressing

sudo nmcli connection modify bond0 ipv4.addresses 192.168.1.50/24 ipv4.gateway 192.168.1.1 ipv4.method manual

Step 6: bring the bond up

sudo nmcli connection up bond0
sudo nmcli connection up bond0-port1
sudo nmcli connection up bond0-port2

Step 7: verify bond status and active member interface

cat /proc/net/bonding/bond0

This shows which interface is currently active (for active-backup mode), link state for each member, and overall bond health — the primary place to check when troubleshooting.

Step 8: test failover, for active-backup or LACP modes

sudo nmcli device disconnect eth0
cat /proc/net/bonding/bond0

Confirm the bond fails over to the remaining interface and connectivity is maintained — testing this deliberately, before relying on it in production, is worth the few minutes it takes.

Step 9: coordinate LACP mode with switch-side configuration

For mode=802.3ad specifically, the switch ports the bonded interfaces connect to must be configured as an LACP-aggregated port group on the switch side too — a bond configured for LACP without matching switch configuration will not work correctly, and can behave worse than no bonding at all.

Why choosing the bonding mode deliberately matters more than the setup steps themselves

The actual configuration commands are nearly identical across modes — what differs is what each mode is for. Active-backup trades away throughput gains entirely in exchange for simplicity and zero switch-side dependency; LACP gets real throughput gains but requires the network team to configure the switch correctly too. Picking based on your actual goal, rather than defaulting to whichever mode a tutorial happened to use, is what determines whether the bond actually solves the problem you set out to solve.

A middle option: adaptive load balancing without switch configuration

mode=balance-alb

balance-alb (adaptive load balancing) sits between the simplicity of active-backup and the throughput of LACP: it distributes outgoing traffic across all bond members based on current load, without requiring any switch-side aggregation configuration at all — the switch simply sees each interface as independent, and the bonding driver handles distribution and failover on the Linux side entirely. This makes it a genuinely useful option specifically when you want some real throughput benefit but don’t control or can’t get changes made to the switch configuration LACP would require — the tradeoff is that it can’t achieve LACP’s full aggregate bandwidth in every traffic pattern, since it’s working around switch limitations rather than coordinating with the switch directly.

Choosing which interface is preferred after a failover recovers

sudo nmcli connection modify bond0 bond.options "mode=active-backup,miimon=100,primary=eth0"

For active-backup specifically, the primary option designates a preferred interface that the bond switches back to once it recovers from a failure, rather than staying on whichever interface happened to take over during the outage — useful when one link is known to be meaningfully faster or more reliable (a 10Gbit primary NIC versus a 1Gbit backup, for instance) and you want the bond to prefer it whenever it’s actually available rather than treating both members as equally interchangeable.

Confirming LACP rate negotiation matches on both ends

sudo nmcli connection modify bond0 bond.options "mode=802.3ad,miimon=100,lacp_rate=fast"

lacp_rate controls how frequently LACP control packets are exchanged with the switch — slow (the default, once every 30 seconds) versus fast (once per second), affecting how quickly a failure is actually detected and the bond reconfigures around it. A mismatch between the Linux bond’s configured rate and the switch’s own LACP timer expectation is a real, specific source of an LACP bond that technically comes up but behaves unreliably under real failure conditions — worth confirming explicitly with the network team alongside the aggregation configuration itself, not just assumed to match by default. ethtool eth0 on each member interface also confirms the physical link is actually negotiating the speed and duplex setting you expect, independently of anything the bonding driver itself reports, which is worth checking directly whenever bonded throughput comes in noticeably below what the sum of the member links’ rated speeds should allow — a member interface silently auto-negotiated down to a slower speed is a common, easy-to-miss reason a bond underperforms despite every configuration setting looking correct on paper.

Related:

Sources: