Linux LACP bonding: configuration, verification, and troubleshooting

Linux LACP bonding combines multiple ethernet interfaces into a single logical link, giving you more aggregate bandwidth and automatic failover between physical NICs. It uses the IEEE 802.3ad standard, with both sides (server and switch) negotiating which links are active and how traffic gets distributed. This post covers what LACP actually does, when to choose it over the other Linux bonding modes, how to configure it on a modern Linux server, and how to verify it's working.

What is link aggregation and LACP?

Link aggregation combines multiple physical network connections into one logical channel. It serves two purposes: increasing total available bandwidth across the link group, and providing automatic failover if any single member link goes down.

LACP, the Link Aggregation Control Protocol, is the dynamic version of link aggregation defined by IEEE 802.3ad. Instead of relying on static configuration on both ends, LACP exchanges control packets called LACPDUs between the server and the switch. The two sides negotiate which links join the aggregation, monitor each link's health, and bring members in or out of the group as conditions change.

In a Linux context, LACP runs as mode 4 (802.3ad) of the kernel bonding driver. The driver creates a logical interface (typically bond0) that owns the IP address, while physical interfaces like eth0 and eth1 become subordinates of the bond. From the OS perspective there is one network interface. From the wire perspective there are multiple parallel ethernet links.

A few things LACP specifically does not do, that people often expect:

• A single TCP connection still travels over one physical link. LACP balances flows, not packets within a flow. Two bonded 1 GbE links won't make a single download go faster than 1 Gbps.
• LACP requires a switch that supports 802.3ad. It won't form a bond against an unmanaged or non-LACP switch.
• All member links must run at the same speed and duplex. You can't bond a 1 GbE port with a 10 GbE port.

Linux bonding modes: when to use LACP

The Linux bonding driver supports seven modes. Most production deployments use one of three.

Mode 1: active-backup

One member interface is active, the others sit idle. If the active one fails, another takes over within a few hundred milliseconds. No switch configuration is needed, which makes this the right choice when the switches are outside your control or don't support 802.3ad. You get redundancy but no extra bandwidth.

Mode 4: 802.3ad (LACP)

All members carry traffic. The bonding driver and the switch use LACP to negotiate the active set and detect failures. Outgoing traffic is balanced across members using a hash policy you configure. This is the standard choice for dedicated servers connected to managed switches when you want both redundancy and additional bandwidth for multi-flow workloads.

Mode 6: balance-alb

Adaptive load balancing in both directions, without requiring switch support. The driver intercepts ARP responses to rewrite MAC addresses and distribute incoming traffic. It works, but it's fragile compared to LACP. Use it only when configuring the switch side is genuinely impossible.

Decision rule:

• No managed switch, or you only need failover: mode 1 (active-backup).
• Managed switch, multiple flows, want both bandwidth and redundancy: mode 4 (LACP).
• Managed switch is impossible but you need both directions balanced: mode 6 (balance-alb).

Modes 0 (balance-rr), 2 (balance-xor), 3 (broadcast), and 5 (balance-tlb) exist but are rarely the right choice on modern hardware. Pick mode 1 or mode 4 unless you have a specific reason not to.

Configuring LACP bonding on Linux

On modern Ubuntu and Debian systems, LACP is configured via netplan. On RHEL, CentOS Stream, AlmaLinux, and Rocky Linux, use NetworkManager via nmcli or by editing the underlying connection files.

Netplan (Ubuntu, Debian)

Drop the following into /etc/netplan/01-lacp.yaml:

network:
  version: 2
  renderer: networkd
  ethernets:
    eth0:
      dhcp4: no
    eth1:
      dhcp4: no
  bonds:
    bond0:
      interfaces: [eth0, eth1]
      addresses: [10.0.0.5/24]
      gateway4: 10.0.0.1
      parameters:
        mode: 802.3ad
        lacp-rate: fast
        mii-monitor-interval: 100
        transmit-hash-policy: layer3+4

Then apply with netplan apply. The key parameters:

• mode: 802.3ad enables LACP.
• lacp-rate: fast sends LACPDUs every second instead of the 30-second default. Must match the switch setting.
• mii-monitor-interval: 100 polls link state every 100 ms.
• transmit-hash-policy: layer3+4 distributes flows by source/destination IP and TCP/UDP port. This produces better balance than the default layer2 policy for typical web and database traffic.

NetworkManager (RHEL, AlmaLinux, Rocky)

nmcli con add type bond ifname bond0 con-name bond0 \
  bond.options "mode=802.3ad,miimon=100,lacp_rate=fast,xmit_hash_policy=layer3+4"
nmcli con add type ethernet ifname eth0 master bond0
nmcli con add type ethernet ifname eth1 master bond0
nmcli con mod bond0 ipv4.addresses 10.0.0.5/24 ipv4.gateway 10.0.0.1 ipv4.method manual
nmcli con up bond0

Switch side

The switch needs a LAG group (often called a port-channel) configured to LACP active mode, with the same number of member ports as the bond. The exact syntax varies by vendor, but the requirements don't: the ports must be in the same VLAN, set to the same speed and duplex, and use LACP active mode on at least one side. Both sides active is the safest setup.

On Cisco IOS:

interface range gigabitethernet0/1 - 2
 channel-group 1 mode active
 channel-protocol lacp

On Aruba/ProCurve:

trunk 1-2 trk1 lacp

The lacp_rate setting on the switch must match the host. A mismatch here is one of the most common LACP configuration errors and causes intermittent flapping every 30 seconds.

Verifying and troubleshooting LACP

Check the live status of the bond on the Linux side:

cat /proc/net/bonding/bond0

Four things to look for in the output:

1. Bonding Mode: IEEE 802.3ad Dynamic link aggregation confirms mode 4 is loaded.
2. Each subordinate interface listed with MII Status: up and link failure count: 0.
3. A non-zero Partner Mac Address for each subordinate. All zeros here means the switch isn't sending LACP packets at all, either because the port isn't in a LACP-active LAG, or because the cable is in the wrong port.
4. Aggregator ID is the same on every member. Different IDs mean the members aren't actually combined, they're acting independently.

The fastest sanity check that bandwidth is being used is to run iperf3 with multiple parallel streams (iperf3 -P 8) from another host. If total throughput exceeds a single link's capacity, LACP is balancing correctly. A single-stream test showing the speed of one link is expected behaviour, not a bug.

The most common LACP problems and their causes:

• Partner MAC is all zeros: switch port isn't in a LACP-active LAG, or cables are mis-patched.
• Bond comes up but throughput is stuck on one link: the hash policy probably defaulted to layer2, which hashes only on destination MAC. Switch to layer3+4.
• Intermittent flapping every 30 seconds: lacp_rate mismatch between host and switch.
• One subordinate works but the other never carries traffic: speed/duplex mismatch, or the switch ports aren't in the same LAG group on the switch side.

When LACP isn't the right answer

LACP solves a specific problem: aggregating multiple links between one host and one switch (or one switch stack) to gain redundancy and per-flow bandwidth. There are scenarios where it isn't the right tool.

If you only need redundancy and the switches don't support 802.3ad, use mode 1 (active-backup) instead. It works with anything.

If you need to bond across two separate switches for chassis-level redundancy, standard LACP won't span two unrelated switches. You need Multi-Chassis Link Aggregation (MLAG), where two switches present themselves as a single logical LACP partner. Most enterprise switch vendors implement this under their own name: Cisco vPC, Arista MLAG, Juniper MC-LAG.

If you need a single flow to exceed one link's bandwidth, LACP cannot do this. The options are to use a faster physical link (replace 2x 10 GbE with 1x 25 GbE or 1x 40 GbE), or to use a different technology entirely. SR-IOV provides near-line-rate single-flow performance to virtual machines by giving each VM a hardware-accelerated virtual NIC, but it solves a different problem and has its own constraints. That's a topic for a separate post.

For most dedicated and colocation servers handling many concurrent connections, LACP remains the standard answer. Two bonded 10 GbE links with layer3+4 hashing comfortably handle 18+ Gbps of aggregate traffic across many flows while surviving a NIC or cable failure without dropping a packet.