Link Aggregation for Home Labs: What LACP Actually Does

You bought a second network cable, bonded two ports on the NAS, and expected twice the speed. Then the file copy finished in exactly the same time as before. Nothing is broken. Link aggregation was never designed to do what most home-lab guides imply it does.

This guide covers what link aggregation actually delivers and why a single transfer stays capped. It explains when bonding ports is worth the effort. It also covers the setting that fixes uneven traffic, and the feature that really does speed up a one-to-one copy.

What Link Aggregation Actually Does

Link aggregation bundles two or more physical links into one logical connection. It raises total bandwidth across many simultaneous flows and keeps the connection alive if one cable fails. It does not make any single transfer faster.

Two devices connected by one cable share one point of failure and one speed ceiling. Add a second cable between the same two devices without configuring anything. You create a Layer 2 loop instead of extra capacity.

Link aggregation is the mechanism that turns those parallel cables into something useful. The switch and the host agree that a set of ports behaves as one interface. Traffic spreads across the members, and a failed cable drops out without interrupting the connection.

The redundancy half of that promise is the reliable half. If one cable, port, or transceiver dies, the remaining members carry the load immediately. No spanning tree reconvergence, no manual failover, no dropped sessions in most cases.

The bandwidth half comes with a condition that trips up almost every first-time builder. That condition is the subject of the next section.

Why LACP Will Not Double a Single File Transfer

A switch assigns each traffic flow to one member link using a hash. Every packet in that flow follows the same cable to avoid reordering. One file copy is one flow, so it stays capped at one link’s speed.

Packets that arrive out of order force the receiver to buffer and reassemble them. TCP handles this, but performance suffers badly. Splitting one conversation across two cables with different queue depths guarantees reordering.

Aggregation implementations avoid the problem by keeping each conversation on a single member. The device runs a hash over selected packet fields and uses the result to pick a link. Identical inputs produce an identical result every time, so a given flow always follows the same cable.

Copying one large file from a PC to a NAS opens one TCP connection. That connection hashes to one member link and stays there for the duration. Two bonded gigabit ports still deliver one gigabit for that copy.

This behavior is consistent across every vendor implementation. When only one pair of hosts communicates, the hash produces too little variation. In the worst case one link saturates while the others sit idle.

Our guide to bandwidth math and transfer time covers how to convert a link speed into a realistic copy duration. Run the numbers for one link, not the bundle, when you are estimating a single transfer.

LAG, LACP, EtherChannel, and Bonding Are the Same Idea

Link aggregation carries a different name on nearly every platform. Cisco calls it EtherChannel, Linux calls it bonding, and Windows calls it NIC teaming. LACP is the negotiation protocol; LAG is the resulting bundle.

The terminology is the single biggest source of confusion in this topic. Vendors named the same technology independently, and the standard itself moved between working groups. Searching for one term often misses documentation written under another.

Why the standard number changed

Link aggregation was first published as IEEE 802.3ad in 2000 and folded into the base Ethernet standard. The IEEE later recognized that aggregation is not fundamentally an Ethernet concept. In 2008 it moved out of the 802.3 group and was republished as 802.1AX.

Both numbers refer to the same technology. Linux still names its LACP bonding mode 802.3ad even though the current standard is 802.1AX. Treat the two as interchangeable when reading documentation.

Hash Policies Decide How Evenly Traffic Spreads

The hash policy sets which packet fields decide a flow’s link. Layer 2 hashing uses MAC addresses, while layer 3+4 adds IP addresses and port numbers. More fields mean more variety, which spreads flows more evenly.

Every aggregation implementation exposes a load-balancing or hash setting. The default is often the least useful option for a home lab. Changing it is usually the single highest-impact adjustment available.

The router-in-the-middle trap

This failure mode catches people who have already segmented their network. Put the NAS on one VLAN and your clients on another, then bond the NAS ports with layer 2 hashing. Every packet now carries the router’s MAC address as its source or destination.

The hash sees one MAC pair for all traffic and picks one link for everything. The second cable never carries a frame. Moving to layer2+3 or layer3+4 restores variety by hashing on the real client IP addresses.

A more fundamental point applies here too. If inter-VLAN traffic passes through a router with a single gigabit interface, that router is the bottleneck. No amount of bonding on the NAS changes it. Our VLAN basics guide covers how inter-VLAN routing works.

Understanding why MAC addresses matter here helps. Our guide to MAC addresses and OUI lookups explains the Layer 2 addressing the default policy depends on.

When Link Aggregation Actually Helps a Home Lab

Link aggregation pays off when many separate flows cross the same link at once. A NAS serving several clients, a hypervisor running many virtual machines, or a busy switch uplink all qualify. A single-client copy does not.

Use this table before buying a second cable. Match your actual traffic pattern to the row that fits, rather than assuming more cables always means more speed.

Notice that the last row applies to every home lab. Even when the bandwidth benefit is zero, the redundancy benefit stands on its own. A bonded uplink survives a chewed cable or a failed port without any manual intervention.

What Actually Speeds Up a Single NAS Transfer

SMB Multichannel opens several parallel connections between one client and one server. Each connection takes a different network path, so a single copy uses every adapter. It solves the exact problem link aggregation cannot.

SMB Multichannel is built into SMB3 and needs no switch configuration at all. The client detects that multiple paths exist between itself and the server, then opens a session over each one. A single file copy becomes several parallel streams.

Synology documents the distinction plainly in its own knowledge base. It treats Multichannel and link aggregation as separate answers to separate problems. Both TrueNAS and Windows support it, and modern macOS enables it by default.

The configuration detail people miss

Multichannel needs the client to see truly distinct paths. On many platforms that means putting each network interface on its own subnet. Two adapters on the same subnet often collapse to a single preferred path.

Disable any existing LACP bond first. Aggregation and Multichannel work against each other when both are active on the same ports. Give each interface a static address, then confirm the client opens more than one connection.

Other options worth considering first

• One faster link. A single 2.5 GbE or 10 GbE port beats two bonded gigabit ports for every workload. It also costs less to configure.
• Multiple parallel transfers. Copying several files at once with a tool that opens separate connections spreads traffic across a LAG naturally.
• NFS with nconnect. Linux clients can open multiple connections to one NFS server, achieving a similar result to Multichannel.

Hardware You Need for Link Aggregation at Home

You need a managed switch that supports LACP and a device with two or more identical network ports. Every member link must match in speed and duplex. Unmanaged switches and most ISP routers cannot do this.

The switch is the non-negotiable part. Look for LACP, 802.3ad, or LAG in the specification rather than the word managed. Some budget smart switches support static LAG only, which this guide covers later.

On the host side, the requirements are stricter than people expect. Links must run at the same speed and duplex to join the same bundle. Mixing a gigabit port with a 2.5 GbE port does not produce a 3.5 gigabit bundle.

• Managed switch with LACP. UniFi, TP-Link Omada, MikroTik, and Netgear smart-managed lines all support it at home-lab prices.
• Two or more matching ports on the host. Most NAS units ship with two, and server motherboards frequently have four.
• Ports on the same switch. Spanning a bundle across two separate switches needs stacking or MLAG, which is uncommon at home.
• Matching VLAN configuration. Every member port needs identical VLAN membership, or traffic drops depending on the hash.

Setting Up Link Aggregation Step by Step

Configure the switch side first, then the host side, then verify. Create a LAG group on the switch with LACP active mode. Bond the matching ports on the host, then confirm both ends report the link as aggregated.

The order matters less than the verification. Many builds appear to work while actually running on one cable. Checking both ends is the step that separates a working bundle from a silent single link.

1. Create a LAG or port-channel group on the switch containing the intended member ports.
2. Set the group to LACP active mode rather than static or passive on at least one side.
3. Apply identical VLAN membership and tagging to every member port in the group.
4. Create the bond on the host, selecting LACP mode and a suitable hash policy.
5. Assign the IP address to the bond interface, never to the individual member ports.
6. Confirm the switch reports the group as aggregated and the host reports both members active.
7. Unplug one cable and verify traffic continues, then plug it back in.

On Linux, TrueNAS, and Proxmox

Linux calls this bonding, and the LACP mode is mode 4, named 802.3ad. Red Hat’s documentation lists which bonding modes need switch configuration and which do not. Mode 4 requires an LACP-negotiated group on the switch, while active-backup needs none at all.

Set xmit_hash_policy to layer3+4 for most home-lab traffic. Add lacp_rate=fast so the bond detects a failed member in about three seconds rather than ninety. The switch setting must match.

The kernel bonding documentation describes each mode and hash policy in full. It also notes that layer3+4 is not strictly standards-compliant for fragmented traffic, which rarely matters in practice.

Verifying the bundle is real

On Linux, read /proc/net/bonding/bond0 and confirm both members show as active with a matching aggregator ID. On the switch, the LAG status should list every member port as bundled rather than individual.

Then test properly. Run two simultaneous transfers from two different clients and watch per-port throughput on the switch. One transfer alone proves nothing, which is why so many builds are declared broken when they are working correctly.

Static LAG Versus LACP: Why Dynamic Is Safer

A static LAG bundles ports with no negotiation between the two devices. Each side assumes the other is configured correctly, so a wiring mistake can silently drop traffic. LACP verifies the partner first and removes mismatched links.

Static aggregation looks simpler and occasionally is the only option on budget hardware. The risk is that it fails quietly rather than obviously. A static bundle stays active even when the far end is not configured to match.

Consider two ports on a switch bundled statically toward a second switch. On the far end, one port is a trunk and the other is an access port. Depending on the hash, a share of the traffic disappears with no error anywhere.

LACP eliminates that class of failure. The two devices exchange control frames and only bundle ports that agree on their parameters. A miscabled or misconfigured port never joins the group, so the problem surfaces as a port that will not bundle.

Static bundles also carry loop risk during configuration. A second cable between two switches becomes an active loop the moment it is plugged in, before the bundle exists. Our guide to spanning tree problems and fixes covers what happens when a Layer 2 loop forms.

Common Link Aggregation Mistakes in a Home Lab

Most home-lab link aggregation problems come from a small set of errors. Mismatched port speeds, a hash policy with too little variety, and wrong expectations cause most of them. Each has a clear fix.

• Expecting a single transfer to double. This is not a fault. Test with several simultaneous flows before concluding the bundle is broken.
• Leaving the hash policy at the layer 2 default. Traffic crossing a router collapses onto one link. Move to layer2+3 or layer3+4.
• Mixing port speeds in one bundle. Members must match in speed and duplex, or the slower port is excluded or drags the group down.
• Assigning IP addresses to member ports. The address belongs on the bond interface. Addresses on members produce unpredictable routing.
• Mismatched VLAN configuration across members. One untagged member in a tagged group drops traffic for whichever flows hash to it.
• Using static LAG on one side and LACP on the other. The bundle either never forms or forms partially, depending on the vendor.
• Ignoring the upstream bottleneck. A bonded NAS behind a single gigabit router uplink gains nothing for inter-VLAN traffic.

When a bonded link behaves oddly after setup, work through the physical layer first. Our network troubleshooting guide walks the full diagnostic sequence, and it applies to bonded interfaces the same as any other.

Frequently Asked Questions

These are the questions home-lab builders ask most about link aggregation. They cover speed expectations, hardware requirements, and the difference between the competing terms. Each answer stands on its own.

Related Tools and Resources

These NetworkCheckr tools support the planning side of a link aggregation build. The bandwidth calculator converts link speeds into real transfer times. The VLAN guide covers the segmentation layer that runs over the same uplink.

References

These are the primary sources behind the technical claims in this guide. They include the IEEE working group that owns the link aggregation standard. They also include the Linux kernel bonding documentation and vendor guidance.

1. IEEE 802.1 Working Group — Bridges and Bridged Networks: Link Aggregation (802.1AX revision draft). 1.ieee802.org
2. Linux Kernel Documentation — Bonding driver: modes, hash policies, and LACP parameters. kernel.org
3. Red Hat — Configuring a network bond: bonding modes and required switch configuration. docs.redhat.com
4. Synology Knowledge Center — What is SMB3 Multichannel and how is it different from Link Aggregation. kb.synology.com