LACP — Link Aggregation Control Protocol

Why link aggregation

A single network link has a finite bandwidth ceiling — for example, 1 Gbps on a typical Ethernet port. Two problems arise from this:

Throughput ceiling. When the traffic demand exceeds what one physical link can carry, the only option is a faster NIC (Network Interface Card) — which may not exist, may be expensive, or may require replacing the switch as well.
Single point of failure. If the cable is cut, the port fails, or the NIC (Network Interface Card) dies, the entire connection is lost.

Link aggregation solves both problems by combining multiple physical links into one logical link. The result is higher aggregate bandwidth and fault tolerance: if one member link fails, the remaining links continue to carry traffic.

This technique is also known as NIC bonding (Linux terminology) or NIC teaming (Windows terminology).

What is LACP

LACP (Link Aggregation Control Protocol) is the standardised protocol for negotiating and maintaining link aggregation between a device and a switch. It was originally published as IEEE (Institute of Electrical and Electronics Engineers) 802.3ad and later moved to IEEE 802.1AX.

LACP allows both ends of a connection to:

Discover which physical ports are eligible for aggregation
Agree on which ports to bundle together into a LAG (Link Aggregation Group)
Monitor the health of every member link
Automatically remove a failed link and redistribute traffic

Without LACP, link aggregation is still possible (static LAG), but there is no protocol-level failure detection — a failed link may go unnoticed until upper-layer timeouts fire.

How LACP works

Prerequisites

Both the device (server, NAS, router) and the switch must support LACP. The switch ports that participate in the LAG must be configured to allow it.

LACPDU exchange

LACP operates by exchanging LACPDUs (LACP Data Units) — special Ethernet control frames — between the two ends. Each LACPDU contains:

Field	Purpose
System priority	Determines which side’s preferences take precedence
System ID	The sender’s MAC (Media Access Control) address
Port priority	Tie-breaking when more ports are eligible than allowed
Port number	Identifies the physical port
Key	Groups ports that are allowed to aggregate together
State flags	Active/passive, aggregation, synchronisation, collecting

Negotiation flow

Both sides begin sending LACPDUs on every LACP-enabled port.
Each side inspects the received LACPDUs and matches ports by key — only ports with the same key on each side can form a LAG.
The sides synchronise: they agree on which ports are collecting (accepting inbound frames) and distributing (sending outbound frames).
Once synchronised, the LAG is up and traffic flows across all member links.

Timers

LACP supports two timer modes:

Fast (short timeout): LACPDUs sent every 1 second. A link is declared down after 3 missed PDUs (3 seconds). Used when fast failover is critical.
Slow (long timeout): LACPDUs sent every 30 seconds. A link is declared down after 90 seconds. Lower overhead but slower failure detection.

Diagram

Without LACP:

┌──────────┐       1x 1 Gbps       ┌──────────┐
│  Server   │ ────────────────────► │  Switch   │
└──────────┘                        └──────────┘
  Single link: 1 Gbps max, no redundancy.


With LACP (2x bonded):

┌──────────┐     Link 1 (1 Gbps)   ┌──────────┐
│  Server   │ ────────────────────► │  Switch   │
│  (bond0)  │ ────────────────────► │  (LAG)    │
└──────────┘     Link 2 (1 Gbps)   └──────────┘
  Logical: 2 Gbps aggregate throughput
  + automatic failover if one link dies.

Bandwidth distribution

A common misconception is that bonding two 1 Gbps links gives a single connection 2 Gbps of speed. It does not.

Traffic is distributed across member links using a hash function. The hash input is typically one of:

Source + destination MAC address (Layer 2)
Source + destination IP address (Layer 3)
Source + destination IP + TCP/UDP port (Layer 3+4) — best distribution

Because the hash is deterministic, a single flow (one TCP connection between two endpoints) always maps to one link. It never gets split across links mid-stream. This means:

Single-flow throughput stays at the speed of one member link (e.g., 1 Gbps).
Aggregate throughput across many concurrent flows increases up to the sum of all member links (e.g., 2 Gbps with two links).

This is why LACP is most beneficial when many clients or many flows are involved.

LACP modes

Mode	Behaviour
Active	The device proactively sends LACPDUs to initiate negotiation.
Passive	The device only responds to LACPDUs received from the other end.
Static	No LACP at all — links are bonded by configuration only (no negotiation).

At least one side must be in active mode for LACP to establish. Two passive sides will never form a LAG because neither initiates.

Static LAG (sometimes called “EtherChannel” on Cisco gear without LACP) is riskier: there is no protocol-level health monitoring, so a partially failed link (e.g., one direction of a fibre goes dark) can silently black-hole traffic.

Linux bonding modes

Linux implements link aggregation through the bonding kernel module. It supports several modes, not all of which use LACP:

Mode	Name	Description	Switch config needed?
0	balance-rr	Round-robin: packets are sent across links in sequence. Simple, but can cause out-of-order delivery.	Yes
1	active-backup	Only one link is active at a time; the others are standby. Failover is automatic.	No
2	balance-xor	Hash-based distribution (XOR of source and destination MAC). Deterministic link selection.	Yes
3	broadcast	Every packet is sent on all links. Used for fault tolerance, not throughput.	Yes
4	802.3ad	LACP. Full protocol negotiation and monitoring as described above.	Yes
5	balance-tlb	Adaptive Transmit Load Balancing — outgoing traffic is distributed by load; incoming uses one link.	No
6	balance-alb	Adaptive Load Balancing — like mode 5 but also balances incoming traffic by ARP (Address Resolution Protocol) manipulation.	No

Mode 4 (802.3ad / LACP) is the most common choice when the switch supports it, because it combines protocol-negotiated bundling with hash-based distribution and fast failure detection.

When LACP matters — and when it does not

Good use cases

NAS (Network-Attached Storage) serving many clients — many concurrent flows benefit from aggregate bandwidth.
Proxmox / hypervisor cluster inter-node traffic — VM migration and storage replication generate multiple flows.
High-traffic servers — web servers, database replicas, or backup targets with many simultaneous connections.

When it is unnecessary

Single-node homelab with light traffic — a single 1 Gbps link is rarely saturated by one or two users.
Devices with 2.5 Gbps or 10 Gbps ports — a single fast link often provides more bandwidth than two bonded slower links, with less complexity.
Laptop or desktop use — typically one connection at a time; LACP provides no benefit.

Edmondo's Vault

Explorer

LACP