A multi-WAN router on a yacht looks simple from the helm: Starlink is up, the cellular modems are up, everything just works. The part owners and captains rarely see is the logic deciding which link carries which packet, and that logic is the difference between a video call that survives a dropped satellite link and one that hangs mid-sentence.
Cave Group designs around Crestron control and marine networking for superyachts and custom vessels — see the marine page for the full capability list. This article is about the layer underneath that package: the WAN algorithm choices that determine whether a failover event is invisible or disruptive, and the questions worth putting to whoever designs or commissions your network.
Priority, Overflow, and Persistence are not the same thing
Peplink's routers support several distinct load-balancing algorithms, and they solve different problems. Understanding which one is active matters more than how many WAN links are connected.
Priority routes all traffic to the preferred link as long as it's healthy, and only moves to a lower-priority link once the top connection fails — Peplink describes this as routing "through the healthy link that has the highest priority in the list," with lower-priority links used "only... if the current connection fails." This is the mode most captains expect: Starlink first, cellular second, nothing shared unless something breaks.
Overflow is a bandwidth-management mode, not a redundancy mode. It keeps traffic on the top link only until that link saturates, then spills the excess onto a lower-priority connection — per Peplink, "the highest priority link will route traffic as long as it has not been congested. Once it saturates, the lower priority links start routing traffic." That's useful for cost control when a cellular link is metered, but it does nothing to protect a call if the primary link drops outright rather than filling up.
Persistence is the setting Peplink specifically positions around keeping a session alive across a network change. Peplink's own description is specific: it is built to "eliminate session termination issues for HTTPS, e-banking, and other secure websites" by keeping a given session's traffic routed through the same connection, by source or destination IP, until the session ends. Without a persistence rule in place, a mid-call switch between Priority's primary and backup link can force the session to renegotiate — ask your integrator whether that renegotiation is what would show up to an owner as a frozen or dropped call on your specific setup.
A separate mode worth knowing about is SpeedFusion bonding, which Peplink positions for use cases that combine multiple links into one data pipe rather than simply failing between them — the company describes it as suited to "transferring a few documents or driving real-time POS data, video feeds, and VoIP conversations" across bonded connections. Bonding and simple failover are not interchangeable, and a system that only fails over between links will behave differently under load than one that actively bonds them.
Ask your integrator which algorithm governs each traffic type on the boat — guest streaming, crew VoIP, bridge data — rather than assuming "multi-WAN" means every scenario is already handled the same way.
Test failover at the dock, not at sea
A router configured correctly on paper should still be proven before the vessel leaves port. The test is straightforward in concept: with a video call or streaming session active, degrade or disconnect the primary link (pull the Starlink dish's power, or disable it in the router) and watch whether the active session survives the switch or drops.
Run that test against each link in turn, not just the primary. Peplink's commercial vessel guidance frames this layered approach directly: single-cellular routers suit small, near-shore vessels, while a dual-cellular router paired with SpeedFusion is recommended for offshore support vessels that are "usually on a mission offshore, and there is no way that the connections can go down." Whether that same layered approach fits a particular superyacht's link mix — Starlink primary, cellular secondary, or something else — is a design question to resolve with your integrator rather than assume; the point that carries over is that no handoff between links should be assumed to work until it has been watched happen, dock-side.
Document the result. A failover test log — which link was pulled, what traffic was active, what happened to the session — belongs in the same handover package as the network diagram and credentials, and it's something a captain or ETO should be able to ask for by name rather than take on faith.
What should never cross between guest Wi-Fi and the bridge
Segmentation matters as much as failover logic. Ask your integrator to confirm, in writing, that guest and crew Wi-Fi traffic, onboard entertainment, and general internet browsing sit on a separate network segment from any bridge, navigation, or vessel-operations traffic. A guest device that can reach bridge equipment — even accidentally, through a flat network with no VLANs — is a risk worth raising directly during design and handover, regardless of how good the WAN failover logic is. Ask for the VLAN map in writing, and ask what, specifically, is allowed to cross between segments. The answer you want to hear is "nothing, by default."
A documentation checklist for handover
Before accepting a vessel from a yard or an integrator, consider asking for:
- The WAN priority and algorithm configuration — which mode (Priority, Overflow, Persistence, or bonded SpeedFusion) governs which traffic type, in writing, not just configured in the router.
- A VLAN map showing how guest, crew, entertainment, and bridge/OT traffic are separated.
- A dated failover test log showing each link pulled individually with session behavior recorded.
- Administrative credentials and a documented support/escalation path for remote diagnosis.
None of this replaces a proper survey by a marine integrator, but it gives an owner or captain the right questions to put to whoever designed the system. For related reading on refit sequencing and legacy equipment removal, see our yacht refit technology playbook, and for the broader connectivity stack this sits inside, see our Starlink Maritime connectivity guide.
If you're planning a new build or a refit, a dock-side failover test and a documented VLAN map are reasonable things to require from any integrator before departure — Cave Group designs marine networking and Crestron control as part of its marine capability, and these are the kinds of questions worth putting to whichever integrator you work with.