LACP Link Aggregation: How It Works for Business Networks

If your network underpins leased-line connectivity or multi-site traffic, link aggregation is part of building a resilient backbone. AMVIA designs and manages that backbone end to end — see our business leased line connectivity work for how the WAN and LAN fit together.

What is LACP and why does it exist?

LACP is a standardised protocol for combining multiple physical network links into a single logical channel called a Link Aggregation Group (LAG), or port channel. It is defined in IEEE standard 802.3ad, now incorporated into IEEE 802.1AX. Both ends negotiate the group automatically rather than relying on manual setup.

Before LACP was standardised, switch vendors shipped proprietary aggregation methods that only worked between equipment from the same manufacturer. LACP solved that interoperability problem. As long as both ends support the 802.3ad standard, you can aggregate links across switches from different vendors — the basis for the per-flow bonding behaviour Microsoft documents for Windows Server NIC teaming.

How does LACP actually work?

When LACP is enabled on a switch port, the port enters a negotiation phase with the connected device. Both ends exchange LACPDUs (Link Aggregation Control Protocol Data Units) to confirm they are willing and able to form a group, and to agree which ports to include. Only confirmed-operational ports join the active LAG.

Once negotiation completes, the member ports behave as one high-speed link. To the rest of the network, the LAG looks like a single interface. Traffic is spread across the member ports using a hashing algorithm — typically based on source and destination MAC address, IP address, or port number, depending on the switch.

Active vs passive LACP mode

LACP supports two negotiation modes, and getting them right is the most common cause of a LAG that never forms:

• Active: the switch initiates negotiation, sending LACPDUs to the connected device. This is the setting we recommend on most deployments.
• Passive: the switch waits for the other end to start negotiation. Passive on both ends means negotiation never begins — at least one end must be Active.

LACP vs static link aggregation: which is better?

Link aggregation can be configured statically, without LACP — ports are manually assigned to a LAG with no negotiation. It is simpler, but it trades away the safety checks that protect a production network. For any business-critical link, we use LACP, not static bonding.

Static aggregation carries real disadvantages:

• No automatic detection of misconfiguration or cabling errors on member ports
• No automatic recovery when a member link fails — the switch keeps forwarding onto a path it believes is up, even when the far end is down
• Less reliable interoperability between non-identical equipment

LACP adds the overhead of protocol negotiation, but it gives you dynamic membership management: ports are only active when both ends confirm they work. That prevents the silent failure modes static aggregation can hide. For production business networks, LACP is the preferred approach.

What can and cannot LACP do?

LACP increases bandwidth and adds link-level redundancy between two devices, but it is not a magic doubling of speed and it does not protect against a whole switch failing. Understanding the boundary stops expensive design mistakes — particularly the assumption that bonding fixes single-flow performance.

What LACP does

• Increases total available bandwidth between two switches, or between a server and a switch, up to the combined capacity of all member ports
• Provides link-level redundancy — if one member port or cable fails, traffic continues across the remaining members with no manual intervention
• Enables standardised interoperability between switches from different manufacturers
• Recovers automatically — when a failed port returns, LACP re-negotiates and adds it back to the LAG

What LACP does not do

• It does not provide device-level redundancy. If one of the two switches in a LAG fails completely, the aggregated link fails regardless of how many ports were configured. For that you need resilient switch pairs and multi-site connectivity design.
• It does not increase the bandwidth of a single flow beyond one member port. A single TCP session uses one hash-selected path. Aggregated throughput only appears across multiple concurrent sessions.
• It operates at Layer 2. It does not bond internet connections from different ISPs at the WAN level — that needs channel bonding or SD-WAN, not LACP.

Where is LACP used in business networks?

The three most common deployments are switch-to-switch uplinks, server NIC bonding, and storage networks. Each suits LACP because traffic is naturally parallel — many concurrent flows that the hashing algorithm can spread across member ports for genuine aggregate throughput.

Switch-to-switch uplinks

The most common use is on uplinks between access switches and distribution or core switches. Instead of a single 1G or 10G uplink, two or four ports are bonded to widen the pipe between network layers. This matters where an access switch carries many users, or where large transfers move between segments. It is a core part of the managed IT infrastructure we deploy.

Server NIC bonding

Servers with multiple network interfaces can use LACP to present one aggregated link to the switch. This is common on file servers, hypervisors and storage systems where the network is the bottleneck. NIC bonding in LACP mode requires the switch to support LACP and to be configured to form a LAG with the server's interfaces.

Storage area network (SAN) connectivity

For iSCSI or NFS storage networks, LACP frequently aggregates bandwidth between storage arrays and the network. Storage traffic is highly parallel — many simultaneous I/O operations — which suits the per-flow distribution model LACP uses far better than a single-flow workload.

How should you configure LACP?

A working LAG comes down to four settings: the hash algorithm, the timer rate, the member-port count, and where you apply VLAN configuration. Get these right up front and the link is stable; get them wrong and you see uneven load or a group that silently never forms.

• Hash algorithm: pick one that spreads traffic evenly for your profile. IP-based hashing usually distributes better where there are many client IPs; MAC-based hashing can suit VLAN-heavy environments.
• Timer rate: LACP supports fast (1-second) and slow (30-second) PDU intervals. Fast timers detect failures sooner at the cost of a little overhead. On uplinks, fast timers are usually appropriate.
• Maximum member ports: IEEE 802.3ad allows up to 16 ports per LAG, of which a maximum of 8 can be active simultaneously; the rest are standby, ready to take over if an active member fails.
• VLAN configuration: a LAG inherits VLAN membership from its member ports. Apply trunk and access settings to the LAG interface, not the individual ports, to avoid inconsistent behaviour.

Does LACP need managed switches?

Yes — LACP requires managed switches at both ends of the link. Unmanaged switches, the kind found in small offices, do not support LACP and cannot join a LAG. For most small businesses that is rarely a limitation, since unmanaged switches typically serve desktop connectivity where a single Gigabit port per device is plenty.

For medium-sized businesses with server rooms, structured cabling and multiple switch layers, we recommend managed switches from Cisco Meraki, Ubiquiti or HPE Aruba that support LACP natively with straightforward configuration. This is the kind of resilient network we build alongside dedicated business broadband and connectivity — one provider, security-first, Microsoft-certified engineers. UK connectivity standards and provider data are tracked by Ofcom, the communications regulator.