Load Balancing Router: How It Works and What It Does Not Do

Most people buy a load balancing router expecting one of two things that it will not deliver. The first is that two connections will combine into one faster connection. The second is that when a link fails, work in progress will carry on without noticing.

Neither is how load balancing works. It is still the right purchase for a large number of offices, but only once you know what it does.

What a load balancing router does

A load balancing router connects to two or more internet links and distributes traffic across them. In practice, distribution happens per session, not per packet.

When a device on your network opens a connection, the router assigns that connection to one of the available links, usually through a hashing algorithm based on source and destination addresses. UniFi's documentation describes this as session stickiness: a given session stays on the same WAN until it ends, even if other links are available. Most multi-WAN implementations behave this way, and for good reason. Splitting a single session across two links means two different public IP addresses, which breaks anything the far end expects to arrive from one place.

So the picture is one browser tab over the fibre line, a file sync over the second connection, someone else's video call over the fibre again. Total capacity across the office goes up. Each individual session runs at the speed of the one link it was assigned.

Why a single download does not get faster

This is the most common disappointment, and it follows directly from session stickiness.

Two 100 Mbps lines under load balancing do not give you a 200 Mbps download. The download is one session, it is hashed to one link, and it runs at up to 100. What you get is the ability to run that download on one line while twenty other people work on the other, without them competing.

Load balancing raises aggregate capacity for many concurrent users. It does not raise the ceiling for any single transfer. If your requirement is one large flow going faster, or one video stream needing more upload than any single link provides, load balancing is the wrong mechanism and bonding is the right one.

Why failover is not invisible

The draft version of this topic that circulates widely claims a load balancing router "maintains active sessions" during failover. It does not, and the distinction matters enough to be worth spelling out.

When a link carrying live sessions fails, those sessions were pinned to it. They go down with it. The router will route new connections over the surviving link, and it will do so automatically and quickly, but the connections that existed on the dead link have to be re-established.

What that looks like in practice depends on the application. A web page reloads and the user barely registers it. A file transfer restarts. A VoIP call drops and has to be redialled. A VPN tunnel renegotiates. A live video stream stops and the encoder reconnects, which viewers see.

Failover timing varies by implementation and detection method. Cold failover, where the backup link is not active until needed, is the slowest. Keeping the backup link up shortens the switch. Either way the public IP changes, and session-sensitive applications drop. Only a bonded tunnel that spans multiple links with a persistent address in front of them lets an in-progress session survive one link failing, because the session never sees the change.

None of this makes load balancing bad. It makes it a mechanism with a defined limit, and the limit is where the buying mistakes happen.

Where load balancing is the right answer

The draft this article replaces got this part right, and it is worth stating plainly. Load balancing fits environments where:

Many users generate many small sessions. An office of thirty people browsing, emailing, using cloud applications and joining calls is exactly the shape load balancing handles well. Sessions are numerous, individually modest, and short lived enough that the occasional re-establishment is unremarkable.

A brief interruption is acceptable. If a reconnect costs someone a second of annoyance rather than a lost transaction or a broken broadcast, failover behaviour is adequate.

You want the second line earning its cost. A pure failover setup leaves the backup idle. Load balancing uses both, which changes the economics of paying for a second connection.

Traffic is continuous but predictable. Steady office load rather than large scheduled bursts.

Typical fits: IT and software offices, clinics and diagnostic labs, retail with POS terminals, schools and colleges, and small to medium offices generally. In these settings load balancing gives you most of the resilience benefit without the cost or configuration of a bonded deployment.

Where it is the wrong answer

Live video and broadcast. A stream is a single sustained session. It gets no benefit from distribution and it dies with its link. This needs bonding.

Voice, if calls dropping is unacceptable. Load balancing plus session persistence keeps a call on one consistent path, which prevents mid-call path changes, but it does not save the call if that path fails. If dropped calls are a business problem rather than an irritation, bonding is the answer.

One large flow that needs to go faster. Covered above. Wrong mechanism.

Persistent VPN tunnels to head office. These renegotiate on failover. Whether that matters depends on what runs inside the tunnel.

Sites where no single link is adequate on its own. If your minimum requirement exceeds what any one of your connections delivers, distributing sessions across them does not help. Every session is still capped by the link it lands on.

Application-based routing, which is the underrated feature

Most load balancing routers let you override the hashing and route specific traffic down a specific link. This is usually more valuable than the load balancing itself, and it is the feature buyers use least.

You can pin VoIP to the most stable connection, send bulk backup traffic to the cheaper or less reliable line, keep POS terminals on the link with the better latency profile, and route guest Wi-Fi away from operational traffic entirely.

That last one solves a real problem. Guest and staff personal devices will consume whatever capacity is available. Directing them to a defined link means an office of phones streaming video cannot degrade the systems the business runs on.

Load balancing against the alternatives

Three mechanisms, and the difference is what each does with your links.

Failover keeps one link active and one in reserve. Simplest to configure, and the reserve capacity sits unused until something breaks. Sessions drop at the switch.

Load balancing uses all links at once, distributing sessions across them. Aggregate capacity rises, each session is capped by one link, and sessions drop when their link fails.

Bonding uses all links at once at the packet level, presenting them as one connection. A single session can exceed the capacity of any one link, and a session survives one link degrading or failing. Aggregate throughput lands below the arithmetic sum of the links because of protocol overhead, so plan with margin rather than adding your speed test results together.

The order of that list is roughly the order of cost and configuration effort. Buy the least complex mechanism that satisfies your actual requirement.

Replacing the manual hotspot habit

Plenty of Indian offices still handle outages by having someone tether a phone or move onto a hotspot. It is worth naming why that is worse than an automatic mechanism, because this is often the real comparison a buyer is making.

Manual switching depends on a person noticing, being present, and knowing what to do. It takes minutes rather than seconds. It usually covers one or two devices rather than the office. And it produces an unmanaged network path with no firewall policy behind it.

Automatic failover, even with sessions dropping, is a large improvement on that. This is the honest version of the draft's claim: load balancing does not maintain your sessions, but it does remove the human from the recovery path, and that is the change worth paying for.

What to check before buying

How many WAN inputs, and of what type. Count the links you have now and the ones you will add. Confirm whether cellular is supported natively, through USB, or not at all.

Failover detection method and timing. Ask how the device decides a link is down. Ping to a target, gateway reachability, and latency thresholds behave differently, and a link that is up but useless is the harder case.

Whether session persistence is configurable. Needed if you run voice or anything else that dislikes path changes.

Whether policy routing is available. The feature you will use most, per the section above.

Throughput with all features enabled. A device's routing figure and its figure with inspection and VPN active are different numbers.

Behaviour you can see for yourself. Ask for a demonstration where a link is physically disconnected during a call and a file transfer. What recovers, and how fast, tells you more than any specification sheet.

Where Benlycos hardware fits

For load balancing across two 4G connections, the Clover 2X is the unit in the Benlycos range positioned for that. Confirm the specifics of its WAN input types and management options against current documentation before specifying it, since the details below could not be verified from published product pages at the time of writing.

If your requirement turns out to be bonding rather than load balancing, which it will if live video, voice continuity or single-session capacity is involved, the relevant products differ. The Clover M2 Pro is documented as a 5G bonding router with dual onboard 5G modems for mission-critical applications. The Clover M2 Fusion is documented as a 4G and 5G hybrid bonding router with dual band 802.11ax. For mixed inputs, the Zifilink series accepts everything over USB interfaces, so wired broadband arrives through a USB to Ethernet adapter, cellular through USB dongles, and existing Wi-Fi through a USB Wi-Fi adapter, with LAN output. Zifilink 3X+ has three interfaces and Zifilink 5X has five.

The practical decision is the one this article opened with. If your traffic is many small sessions and a reconnect is tolerable, load balance. If any single session must survive a link failing, bond.

FAQ

What does a load balancing router actually do?
It distributes sessions across two or more internet links. Each new connection is assigned to one link and stays there for its duration. Total capacity across many users increases.

Will two connections give me double the speed?
No. Each session runs on one link, so a single download or upload is capped by that link's speed. Load balancing increases capacity for many concurrent sessions, not for one transfer.

Does load balancing keep my calls and sessions alive when a link fails?
No. Sessions pinned to the failed link drop and must re-establish. New connections move to the surviving link automatically. Only bonding, which spans links at the packet level behind a persistent address, allows an in-progress session to survive.

Load balancing or bonding for my office?
Load balancing for many users with many small sessions where a brief reconnect is acceptable. Bonding where a single session must not break, such as live video, VoIP continuity, or a transfer that needs more capacity than one link provides.

What is session stickiness?
The behaviour that keeps a session on the same WAN link for its whole life, usually decided by a hash of source and destination addresses. It exists because splitting one session across two public IP addresses breaks most applications.

Is load balancing better than switching to a hotspot manually?
Yes. Automatic detection and switching happen in seconds without anyone present, and the whole network is covered rather than one or two devices.