Network Bonding With LACP: Combining Failover and Bandwidth

1. Why a single network port is not enough

Servers with only one active network card are completely exposed to a cut cable, a failed network card, or a dead switch port, regardless of how redundant storage or power supply happen to be. Especially on database servers or application servers that need to stay reachable at all times, this kind of single point of failure in network connectivity is an often overlooked risk, addressed far less consistently than redundant power supplies or RAID arrays.

Linux bonding, implemented via the bonding kernel driver, combines two or more physical network interfaces into a single logical interface that appears externally as a regular network card. Depending on the chosen mode, the bond either provides pure failover protection, with one interface standing by as backup, or genuine load distribution across multiple physical links, increasing usable bandwidth compared to a single connection.

2. Bonding modes at a glance: active-backup, LACP, and friends

The Linux bonding driver supports seven modes, of which three matter most in practice. Mode 1, active-backup, runs only one interface active at any given time, while the remaining interface stays purely as a spare and takes over if the active connection fails. This mode requires no special switch configuration, since from the switch's perspective only a single MAC address is ever active on a port, making it the simplest and most robust choice for pure redundancy.

Mode 4, 802.3ad, also known as LACP, negotiates a genuine aggregation of several links into a link aggregation group with the connected switch via the Link Aggregation Control Protocol. Unlike active-backup, LACP actively distributes traffic across all participating links, delivering both failover protection and aggregated bandwidth, but only if the switch itself supports LACP and has been configured accordingly. Balance-rr, mode 0, also distributes packets across all links using round robin, but without negotiating with the switch, which in practice often causes packet ordering issues and makes it unsuitable for most production scenarios.

# Check the available bonding mode and current status of a bond
cat /sys/class/net/bond0/bonding/mode
cat /proc/net/bonding/bond0

3. Switch configuration: why LACP does not work without a counterpart

LACP is a negotiation protocol between two endpoints, so the connected switch absolutely needs a matching port channel or link aggregation group configuration that groups the same physical ports into a logical unit. Without this counterpart configuration, the server still sends LACP control packets but never receives a reply, and the bond stays in a state where individual slave interfaces are marked as not aggregatable, even though the bond itself appears active.

The LACP rate also has to match between server and switch: fast mode sends a control packet every second, slow mode every thirty seconds. A mismatch usually does not cause a complete aggregation failure, but it significantly delays detection of a failed link, which is an underestimated risk especially on database servers with strict availability requirements. Just as important is a consistent hash policy on both sides, since otherwise switch and server use different criteria for load distribution and the aggregation effectively provides no benefit.

4. Bond configuration with netplan on Ubuntu servers

On modern Ubuntu Server installations, network configuration is managed by default through netplan, which translates YAML definitions into systemd-networkd or NetworkManager. An LACP bond is defined as its own interface type that references the participating physical interfaces and explicitly sets the bonding parameters, in particular mode, LACP rate, and the hash policy used for load distribution.

The transmit-hash-policy determines which criteria outbound packets are distributed across the individual physical links by. layer2 relies only on MAC addresses and often leads to unbalanced load distribution when there are few communication partners, while layer3+4 additionally factors in IP addresses and ports, delivering noticeably more even distribution for servers with many parallel TCP connections, such as database or web servers.

# /etc/netplan/01-bond0.yaml
network:
  version: 2
  ethernets:
    enp1s0:
      dhcp4: no
    enp2s0:
      dhcp4: no
  bonds:
    bond0:
      interfaces: [enp1s0, enp2s0]
      addresses: [192.168.10.20/24]
      parameters:
        mode: 802.3ad
        lacp-rate: fast
        mii-monitor-interval: 100
        transmit-hash-policy: layer3+4
      routes:
        - to: default
          via: 192.168.10.1

5. MII monitoring and fast failure detection

By default, the bonding driver monitors the availability of individual slave interfaces via MII monitoring, which polls the physical link status of the network card at a configurable interval. The mii-monitor-interval parameter, set to 100 milliseconds in the example above, determines how quickly a link failure gets detected, though overly aggressive values under 50 milliseconds can occasionally trigger false alarms on brief, harmless link flaps in practice.

As an alternative, the bonding driver supports ARP monitoring, which sends targeted ARP requests to defined destination addresses to check not just the physical link status but actual reachability through each slave. This approach additionally catches problems MII monitoring misses, such as a misconfigured switch port that shows link electrically but does not forward traffic, though it is more complex to configure and unnecessary for most standard scenarios.

6. Monitoring bond status during production operation

The file /proc/net/bonding/bond0 provides the full status of an active bond, including the currently used mode, the MII status of each individual slave, and, for LACP, additional aggregation details such as partner MAC address and aggregator ID. A slave marked as down despite apparently intact physical cabling often points to a switch side misconfiguration and should be checked there first, before questioning the local configuration.

For ongoing monitoring in production environments, it is worth integrating bond status into a central monitoring system, for example via a node exporter for Prometheus that regularly evaluates the number of active slaves and their state. An alert should already fire the moment a single slave fails, even if the bond as a whole remains functional, since an unnoticed single link operation silently defeats the redundancy it was set up to provide.

# Show full status including LACP partner information
cat /proc/net/bonding/bond0

# Extract the number of active slaves for a simple monitoring script
grep -c "MII Status: up" /proc/net/bonding/bond0

7. MLAG: when even the switch itself must not be a single point of failure

Classic LACP bundles several physical links, but it assumes all participating ports terminate on a single switch, which turns the switch itself into the remaining single point of failure. Multi-Chassis Link Aggregation, MLAG for short, solves this by having two physically separate switches coordinate with each other so they present themselves to the server as a single logical LACP partner, even though the bond's two cables terminate on different devices.

From the Linux server's perspective, nothing changes in the bonding configuration itself, mode 4 with the same parameters still applies, since all coordination between the two switches happens over a proprietary, vendor specific synchronization channel that stays invisible to the server. For production server clusters with strict availability requirements, MLAG is well worth the investment, since it makes failover protection continuous from the network card through the link all the way up to the switch itself, instead of breaking down right before the actual network backbone.

8. Common misconfigurations and how they silently undermine failover

The most common mistake is a mismatch between the switch side port channel configuration and the local bonding mode: if the server is configured for LACP while the switch treats the ports as a static EtherChannel without LACP negotiation, the bond may still work, but it behaves unpredictably during link failures, since both sides make different assumptions about the state of the aggregation.

A second classic mistake is bundling network cards of different speeds or different duplex modes into a single bond, which most modes either implicitly cap to the slower interface, or, in combination with LACP, some switches reject entirely. Also underestimated is choosing the wrong hash policy: using layer2 while all traffic passes through a single upstream router with a fixed MAC address means all traffic effectively lands on only one of the physical links despite the bundling, failing to deliver the expected combined bandwidth in practice.

9. Which mode makes sense when: a practical decision guide

For environments without control over switch configuration, or with a strict need for maximum simplicity, active-backup remains the most pragmatic choice, since it works without any switch side adjustment while still providing complete failover protection against the loss of a single link or switch port. Where higher bandwidth is needed in addition to redundancy, for example on storage networks with high throughput demands, there is no way around LACP, provided the switch infrastructure supports it and the configuration is carefully coordinated between the network and server teams.

Broadcast and balance-rr modes have little practical relevance in modern production environments, since they either create unnecessary redundancy overhead or, in the case of balance-rr, can cause packet ordering issues that particularly disrupt TCP based applications like database connections. For the vast majority of production Magento hosting environments, the combination of 802.3ad with a layer3+4 hash policy delivers the best balance of failover protection, bandwidth, and predictability.

10. Summary

11. FAQ: Network Bonding