Skip to content

LACP — Trivia & Interesting Facts

Surprising, historical, and little-known facts about Link Aggregation Control Protocol.

LACP was standardized because proprietary solutions were incompatible

Before IEEE 802.3ad (2000), every vendor had their own link aggregation technology: Cisco had EtherChannel (PAgP), Nortel had Multi-Link Trunking, and 3Com had something else entirely. None of them interoperated. LACP was standardized so that a Cisco switch could form a link bundle with a Juniper switch, though in practice many engineers still use static (non-LACP) aggregation on single-vendor links out of habit.

LACP uses a "slow" and "fast" timer, and the wrong choice can cause outages

LACP sends control PDUs (LACPDUs) at either 1-second intervals ("fast") or 30-second intervals ("slow"). In fast mode, a link failure is detected in 3 seconds (3 missed PDUs). In slow mode, detection takes 90 seconds. Many default configurations use slow mode, meaning a failed link can continue receiving traffic for up to 90 seconds before LACP removes it — an eternity for production traffic.

The hashing algorithm determines whether your LAG actually distributes traffic

Link aggregation doesn't split individual flows across links — it hashes each flow to one specific link. If the hash algorithm uses only source/destination MAC and all your traffic goes between two devices, 100% of traffic hits one link. Choosing the right hash (L3+L4, source+destination IP+port) is critical. A 4-link LAG with bad hashing can perform worse than a single link for specific traffic patterns.

LACP system priority determines who makes decisions, and almost nobody configures it

Each LACP participant has a system priority (default 32768). The system with the lower priority number becomes the "actor" that decides which links are active. If both sides use the default, the system with the lower MAC address wins. In practice, almost nobody changes this value, and most engineers don't realize that the "other side" may be making all the link selection decisions.

MC-LAG was the industry's answer to the single-switch-failure problem

Standard LACP requires all links in a bundle to terminate on the same switch, creating a single point of failure. Multi-Chassis LAG (MC-LAG) distributes a LAG across two physical switches that appear as one LACP peer. Every vendor implemented their own version: Cisco vPC, Arista MLAG, Juniper MC-LAG, and they are all different enough to cause confusion. This fragmentation drove the adoption of EVPN multi-homing as a standards-based alternative.

If a fiber in a LAG member loses its receive strand but transmit still works, LACP may not detect the failure because LACPDUs are sent and received independently on each member. Traffic hashed to that link is transmitted successfully but responses are lost. This scenario is why Unidirectional Link Detection (UDLD) or similar protocols are recommended alongside LACP.

A misconfigured LAG is worse than no LAG at all

If one side thinks it has a LAG (bundled ports) but the other side sees individual ports, traffic entering the "LAG" side is hashed across multiple ports, but the non-LAG side treats each port independently. The result is duplicate frames, MAC flapping, and possible spanning tree disruptions. This misconfiguration is common enough that LACP's active negotiation — which prevents unilateral bundling — is its single most valuable feature.

IEEE 802.3ad specifies a maximum of 8 active links in an aggregation group, but allows up to 8 additional standby links for redundancy (total 16 member ports). The standby links remain in LACP negotiation but don't carry traffic until an active link fails. In practice, most LAGs use 2-4 links, and 8-link bundles are rare outside of storage networks and data center spine-leaf interconnects.

The Linux bonding driver supports seven modes, and only one is LACP

Linux's bonding driver (bond0) supports modes 0 through 6: balance-rr, active-backup, balance-xor, broadcast, 802.3ad (LACP), balance-tlb, and balance-alb. Only mode 4 is actual LACP. Mode 0 (round-robin) sounds appealing but causes out-of-order packets that destroy TCP performance. Mode 1 (active-backup) wastes half the bandwidth. Choosing the right bonding mode is a surprisingly consequential decision for Linux servers.