Part Four: The Three Behaviors, Bonding vs. Hot Failover vs. Load Balancing
The topic
Peplink can do three fundamentally different things with multiple WANs, and conflating them causes most early design mistakes. They are not interchangeable, and each has a right use.
Load balancing spreads different sessions across different links. Session A goes out WAN 1, session B goes out WAN 2. No tunnel is required; it works on a standalone router. It increases aggregate capacity for many users, but a single session still lives and dies on one link.
Hot failover establishes a SpeedFusion tunnel on all active links but sends a session’s user traffic on only one link at a time. If that link fails, traffic is rerouted to another link’s tunnel in under a second, and session-persistent applications, a VoIP call, a video conference, a broadcast feed, keep running through the handoff without dropping. The user may not even notice.
Bandwidth bonding establishes the tunnel on all active links and splits a single session’s traffic across all of them simultaneously, combining their throughput. A single file transfer or video stream can use the sum of several connections. If a link fails, the remaining links carry on (with hot-failover behavior underneath), so bonding also gives you resilience for free.
 Hot Failover, the tunnel rides all links, traffic uses one at a time, and a link failure is a sub-second, non-disruptive handoff.
 Bandwidth Bonding, a single session is split across all active links and reassembled at the far endpoint.
How it works on Peplink
All three are configured on the SpeedFusion profile and its sub-tunnels (except plain load balancing, which is an outbound-policy behavior and needs no tunnel). The key conceptual split is between load balancing, which operates per-session and needs no partner, and the two tunnel behaviors (hot failover and bonding), which operate within a session and require a tunnel endpoint on the far side. Bonding requires reasonably comparable links to be worthwhile; bonding a 1 Gbps fiber with a flaky 5 Mbps cellular link will not give you 1.005 Gbps of useful coherent throughput, and certain combinations are simply not realistic to bond.
Why it matters
The choice maps directly to the customer’s actual goal. If the goal is “more total bandwidth for the office,” load balancing or bonding fits. If the goal is “this one video call must never drop,” hot failover (or bonding with the right protection) is the answer. If the goal is “this one giant transfer must go faster than any single circuit allows,” only bonding does it. Selling or configuring the wrong one produces a technically working setup that fails the customer’s real test.
Field note
The phrase to carry to customers is: traditional redundancy is failover, a backup link that sits idle until the primary dies, at which point sessions break and restart. Peplink hot failover keeps the session alive across the switch, and bonding uses every link at once. The difference is “we have a backup in case we go down” versus “we do not go down.” That is the sentence that wins the deal, and it is true.
From the field — HYROX Chicago 2025: The event bonded six Starlinks with cellular and ran automatic failover between them; athlete registration and live timing never dropped even as individual links wobbled. That is the difference a live event pays for, not “we have a backup” (failover) but “we don’t go down” (bonding with failover underneath).