The New Backup Bottleneck: LACP vs. Load Balancing in a 10Gb World

So your backups are dragging and your boss wants more bandwidth. Classic. The idea sounds simple enough: bond some 10Gb links with LACP and boom, double the speed. Problem solved, right?

Not exactly. And if you’re running a VMware environment, especially with iSCSI in the mix, it’s worth slowing down and thinking this one through. Because LACP isn’t the magic switch people often think it is.

LACP: Not the Speed Boost You’re Hoping For

LACP (Link Aggregation Control Protocol) sounds great on paper. Combine two 10Gb interfaces and you get 20Gb of bandwidth. Except… that’s not really how it works.

Here’s the deal:

• LACP groups links together, sure, but it assigns each network flow to one link based on a hash (usually source/destination IP or MAC).
• That means any single connection, like a VM backup job, is still limited to one link — so 10Gb max.
• You can have multiple connections using different links, but one connection isn’t going to magically span both and hit 20Gb.

So yes, you technically have 20Gb total bandwidth across the bundle, but individual sessions won’t benefit unless there are multiple simultaneous flows — and even then, it depends on how the hashing works out.

VMware Already Has Something Better

If you’re running vSphere Enterprise Plus with Distributed Switches, you’ve already got a better tool: load-based teaming (LBT).

LBT doesn’t require any switch config. No bonding, no special port channel setup. It just watches the uplinks and shifts traffic to the NICs that have less going on. It’s automatic, simple, and — most importantly — it actually works.

Some real-world upsides to LBT:

• No messing around with physical switch configs
• More flexibility during maintenance or network changes
• Still gets you balanced traffic and failover support

LACP adds extra complexity for no real gain in most VMware environments. Especially when LBT already gives you smart load balancing across multiple NICs without all the fuss.

iSCSI + LACP = Not a Great Mix

If you’ve got iSCSI traffic in play — especially with Nimble or PowerStore storage — avoid LACP altogether.

iSCSI is designed to use multipathing, where you have multiple NICs and paths configured to handle traffic in parallel. It works well when set up properly and can make full use of your 10Gb links.

LACP, on the other hand, breaks this. It masks the individual NICs and hides them behind a single logical link. That defeats the point of multipathing and can actually slow things down — or worse, cause weird failures and dropped packets.

A better approach for iSCSI:

• Use separate VLANs and dedicated uplinks
• Pin specific NICs to specific paths
• Let the storage and OS handle multipath routing

You’ll get full link utilization, better failover, and way less hassle.

Backups Still Slow? LACP’s Not the Fix

If this whole conversation started because backups are slow, LACP probably isn’t going to help.

Here’s why:

• Backup jobs are usually a single connection — they won’t exceed the bandwidth of a single link
• Most of the time, your backup target is the real bottleneck, not the network path
• If you’re going through the host instead of directly accessing the SAN, you’re adding unnecessary hops

If you want to speed up backups, look into:

• Direct SAN access: Mount snapshots directly on the backup proxy and pull data straight from storage
• Faster NICs: Upgrade your hosts and backup servers to 25Gb — seriously, the jump from 10 to 25 is huge
• Jumbo frames: If your gear supports it end-to-end, this can improve throughput
• More IO threads: Make sure your backup software is using parallel jobs where possible

Keep It Simple

The common theme from experienced VMware folks? Don’t overcomplicate things.

LACP has its place — usually in older or very specific setups — but in most modern VMware environments, it’s just not worth it. The extra configuration, the limited benefit, and the potential for weird issues make it more trouble than it’s worth.

Instead:

• Use multiple uplinks
• Let VMware handle traffic balancing internally
• Keep storage traffic separate and properly multipathed
• Upgrade your hardware if you’re hitting real throughput ceilings

Here’s a quick cheat sheet:

If you’re running 10Gb NICs and trying to squeeze more out of them, LACP might seem tempting. But it’s not the fix you’re looking for.

Stick to the tools built for the job. VMware’s built-in load balancing is smarter, more flexible, and avoids the quirks and limitations that come with LACP. And if you really need more speed — there’s no substitute for upgrading to 25Gb where it matters.

No network trick is going to beat faster hardware and well-thought-out design. Simple wins, every time.