Network interface bonding (often called link aggregation) is a mature Linux feature that lets you combine multiple physical NICs into a single logical interface. For system administrators, developers, and business operators running VPS or on-premises servers, bonding is a practical way to achieve redundancy, increase throughput, and control traffic distribution. This article explains the underlying principles, real-world application scenarios, trade-offs between modes, example configuration snippets, and purchase considerations so you can make informed deployment decisions.

Principles: How Linux Bonding Works

At its core, bonding aggregates several Ethernet interfaces into one logical device (commonly named bond0, bond1, etc.). The kernel module responsible is bonding (or the netlink-based equivalent in recent iproute2 workflows). Bonding operates in different modes that determine how traffic is balanced and how failover is handled.

Common Bonding Modes

• mode=0 (balance-rr) — Round-robin transmit across slaves. Simple, can increase throughput for single TCP flows only in special switch setups. Requires switch support and careful MTU/ordering considerations.
• mode=1 (active-backup) — Only one NIC active; others standby. Provides seamless redundancy without requiring switch support. MAC moves to the active slave on failover.
• mode=2 (balance-xor) — Transmit based on XOR of MAC/IP, distributing flows by hash. Works with most switches but per-flow rather than per-packet balancing.
• mode=4 (802.3ad) — LACP (Link Aggregation Control Protocol). Requires switch and NIC LACP support. Provides aggregation with dynamic negotiation and is ideal for both bandwidth and redundancy.
• mode=5 (balance-tlb) — Adaptive transmit load balancing; receives on single slave, but transmit load is balanced based on relative speed.
• mode=6 (balance-alb) — Adaptive load balancing extends TLB with receive load balancing via ARP negotiation; switch support not required.

Health Monitoring and Tuning

Bonding uses monitoring options such as miimon (link state monitoring in milliseconds) and arp_interval/arp_ip_target for ARP-based monitoring in ALB. Common parameters:

• miimon=100 — Poll every 100ms to detect link loss.
• updelay / downdelay — Delay before declaring a link up/down to avoid flapping.
• xmit_hash_policy — Selects hashing algorithm (layer2, layer2+3, layer3+4) affecting distribution of flows in hashing-based modes.
• lacp_rate — In 802.3ad, set to fast or slow to adjust LACP PDU periodicity.

Practical Configuration Examples

Below are practical examples for both modern iproute2 and traditional distro-specific configs. Replace interfaces names (eth0, eth1) with your server’s NIC names (e.g., ens3, enp1s0).

Quick iproute2 Example (Transient, immediate)

This uses netlink to create a bond on-the-fly for testing:

modprobe bonding
ip link add bond0 type bond mode 802.3ad miimon 100 lacp_rate fast
ip link set eth0 master bond0
ip link set eth1 master bond0
ip link set eth0 up
ip link set eth1 up
ip link set bond0 up
ip addr add 192.0.2.10/24 dev bond0
ip route add default via 192.0.2.1

To see bonding status:

cat /proc/net/bonding/bond0

Debian/Ubuntu (/etc/network/interfaces) Example

auto bond0
iface bond0 inet static
    address 192.0.2.10
    netmask 255.255.255.0
    gateway 192.0.2.1
    bond-mode 802.3ad
    bond-miimon 100
    bond-lacp-rate fast
    bond-slaves eth0 eth1

CentOS/RHEL (/etc/sysconfig/network-scripts/ifcfg-*) Example

# /etc/sysconfig/network-scripts/ifcfg-bond0
DEVICE=bond0
TYPE=Bond
NAME=bond0
BONDING_MASTER=yes
BOOTPROTO=static
IPADDR=192.0.2.10
PREFIX=24
GATEWAY=192.0.2.1
BONDING_OPTS="mode=802.3ad miimon=100 lacp_rate=fast"

/etc/sysconfig/network-scripts/ifcfg-eth0
DEVICE=eth0
BOOTPROTO=none
ONBOOT=yes
MASTER=bond0
SLAVE=yes

/etc/sysconfig/network-scripts/ifcfg-eth1
DEVICE=eth1
BOOTPROTO=none
ONBOOT=yes
MASTER=bond0
SLAVE=yes

Troubleshooting Tips

• Always check /proc/net/bonding/bondX for current state and active slave details.
• Use ethtool to confirm link speed/duplex: ethtool eth0.
• On LACP, verify the switch side (port-channel) state. If the switch is misconfigured, the bond may not aggregate traffic.
• For per-flow balancing issues, check xmit_hash_policy and consider adjusting to layer2+3 for IP/port aware distribution.
• Inspect NIC driver and firmware: mismatched drivers across ports can prevent proper aggregation.

Application Scenarios: When to Use Which Mode

High Availability / Redundancy (Active-Backup)

If the goal is simple failover without requiring changes on the switch, active-backup (mode=1) is best. It provides predictable failover behavior and is tolerant of unmanaged switches (typical in VPS host environments where you control only the guest OS).

Bandwidth Aggregation (LACP / 802.3ad)

When you need real aggregated throughput for multiple simultaneous flows and you also manage the switch, mode=4 (802.3ad) is recommended. This is common in data centers and colocation where the top-of-rack switch can be configured for LACP.

Load Distribution Without Switch Support

Modes like balance-tlb and balance-alb can improve bandwidth utilization without switch changes, but they are limited by how the kernel balances traffic and sometimes by client-side behavior. Use them when you cannot modify the switch configuration.

Advantages and Trade-offs: Performance vs Redundancy

Bonding is not a one-size-fits-all solution. Understanding trade-offs will help you choose the correct mode.

• Performance (throughput): LACP can aggregate multiple flows effectively, but single TCP stream improvements are limited unless the switch supports per-packet balancing (rare). balance-rr can increase single-flow throughput but is fragile and requires matching switch behavior.
• Redundancy: Active-backup offers simple failover with minimal coordination. LACP also provides redundancy, but relies on proper switch config and LACP timers.
• Complexity: LACP requires switch configuration and coordination across network team and infrastructure. ALB/TLB may require ARP considerations and careful testing with clients.
• Deterministic Behavior: Hash-based modes (xor, layer2+3) provide deterministic per-flow mapping and are suitable when you want predictable pathing for certain traffic types.

Selection and Purchase Advice

When planning bonding on a VPS or dedicated server, consider the following:

• Provider capabilities: If you’re using a VPS provider, verify whether they expose multiple NICs and whether the hypervisor supports LACP. Many public VPS offerings expose a single virtual NIC; bonding inside the guest may only provide redundancy for virtual interface failover, not additional physical throughput.
• Switch support: For true aggregation (LACP), ensure the physical switch or virtual switch supports 802.3ad. On cloud or multi-tenant environments, consult the provider’s networking docs.
• NIC drivers and offloads: Ensure NIC drivers are up-to-date. Offload features (TSO/GSO/LRO) can affect bonding behavior — test with your workload and use ethtool to toggle offloads if necessary.
• Testing: Simulate failures and run multi-flow tests (iperf3 with multiple streams) to validate performance and failover characteristics before production deployment.
• Future growth: Choose NICs and plans that can scale. If you anticipate higher throughput, opt for multi-gigabit NICs and switches that support LACP. For VPS customers seeking reliable connectivity and performance, consider upgrading to plans with guaranteed network capacity.

Summary

Linux network bonding is a powerful, flexible tool for improving redundancy and, where supported, increasing throughput. Choose active-backup for simple, robust failover when you cannot change the switch configuration. Select 802.3ad (LACP) when you can coordinate with the switch and need aggregated bandwidth across multiple flows. Pay attention to tuning parameters such as miimon, xmit_hash_policy, and LACP rate for predictable behavior. Always verify driver compatibility, switch configuration, and test under realistic workloads before rolling out into production.

For those running services on VPS with high availability and predictable networking needs, consider service plans that expose required networking features. If you’re evaluating options, see VPS.DO’s USA VPS offering for scalable VPS plans and networking details: USA VPS at VPS.DO.