Part Twenty-Five: The Synthesis, SD-WAN and SpeedFusion
The topic
Every preceding topic describes a piece of how networks work. SD-WAN (software-defined wide-area networking) is the layer that ties them together for the wide area. Instead of treating the connection between sites and to the internet as a single fixed line, SD-WAN treats it as a pool of connections governed by intelligent software that decides, continuously, how traffic should use them. SpeedFusion is Peplink’s implementation, and its distinguishing capability is true bonding: not merely failing over from one link to a backup, but using all links simultaneously and letting a single session ride across several at once.
How it brings the fundamentals together
Walk back through this document and notice how the pieces converge at the SD-WAN edge:
- It is a router and a firewall and a gateway, doing Layer 3 forwarding and security policy in one place (Parts 14, 16, 17).
- It performs VLAN segmentation and inter-VLAN routing, often replacing the core switch entirely (Parts 10, 13).
- It runs BGP for stable internet identity while choosing paths by real-time performance rather than advertisement alone (Parts 1, 15).
- It bonds diverse WAN link types, fiber, cable, 5G, LEO satellite, into one resilient connection (Part 20).
- It delivers VPN connectivity that survives link failure and scales without a fragile hand-built mesh (Part 21).
- It can extend Layer 2 across the wide area for seamless roaming networks (Part 9).
- It applies traffic shaping and Zero Trust policy consistently at every edge (Parts 17, 19).
- It is run from centralized management that makes a thousand sites as visible as one (Part 23).
The difference it makes: failover vs. bonding
The single most important distinction to carry away: traditional redundancy is failover, a backup link that sits idle until the primary dies, at which point sessions break and restart on the backup. SpeedFusion bonding uses every link at once and lets a live session survive the loss of any individual link without interruption. The difference is “we have a backup in case we go down” versus “we do not go down.” That is the capability that lets West Networks tell a customer, truthfully, that a failed connection will be a non-event they never notice.
How a single session survives a link dying (and what the far end must do)
The mechanism is the key to the whole technology, so it is worth stating plainly. SpeedFusion builds a tunnel between two endpoints, your site and another point (a data center, a cloud instance, another site, or one of Peplink’s hosted endpoints). Traffic inside that tunnel is broken into pieces that can travel across all the member links at once, and the receiving end reassembles them in the correct order. Because the application’s session is bound to the stable tunnel, not to any one physical link, the loss of a link just means the remaining links carry the pieces; the session never sees the failure. Crucially, this requires two endpoints: there must be something on the other end terminating the tunnel and doing the reassembly. You cannot bond links with only one device, the far end (another Peplink device, or a Peplink-hosted SpeedFusion endpoint in the cloud) is doing the matching work. That is why the mammography solution needed “a matching device at the data center,” and why a single edge router by itself, with no tunnel partner, can only do failover and load-balancing, not true session-surviving bonding. The far end does not need to be anything exotic, but it does need to exist and be configured as the tunnel partner.
The most common first-deployment mistakes
The mistakes new SpeedFusion deployers make are consistent and avoidable:
- Overlapping subnets between sites. Two sites both on 192.168.1.0/24 cannot route to each other through the tunnel. This is the single most common one; a coherent, non-overlapping addressing plan (decided up front) prevents it.
- MTU/MSS not accounted for. The tunnel adds overhead, so traffic that assumes a full 1500-byte MTU stalls. The symptom is the classic “ping works, real traffic hangs.” Get MSS clamping right on the tunnel.
- Expecting bonding with only one endpoint. As above, no tunnel partner means no bonding. People sometimes expect a single device to bond links by itself and are surprised it only fails over.
- Bonding links that fail together. Two circuits from the same provider, or two that share the same physical path, do not give real redundancy. Diversity is the point.
- Putting everything on the tunnel, or nothing on it. Bonding has overhead and is not needed for ordinary web browsing; use it for the sessions that must not drop (voice, video, critical apps) and let other traffic use plain load-balanced links. Mismatching this wastes capacity or leaves critical traffic unprotected.
- Forgetting outbound policy / persistence for non-tunneled apps. Apps that break when their public IP changes need a persistence or enforced rule, as covered in the NAT and firewall sections.
How IPv6 behaves once everything runs over SpeedFusion
IPv6 actually gets easier inside a SpeedFusion deployment, for one core reason: the tunnel gives you a stable internal transport that is independent of whatever the carriers’ IPv6 prefixes are doing. The carrier-side churn that makes raw multi-ISP IPv6 painful (changing delegated prefixes, per-carrier delegation quirks, CGNAT) is hidden beneath the tunnel. You run stable internal IPv6 (ULA) across your sites over the tunnel, route it consistently, and let the global prefixes underneath change as they like. The same session-survival benefit applies to IPv6 traffic as to IPv4. The cautions from the IPv6 sections still hold (own your Router Advertisements, firewall both families, mind the larger headers in the MTU math), but the net effect is that SD-WAN turns IPv6’s multi-link messiness into the same clean, stable experience it gives IPv4.
What happens to all of this with a fully mobile fleet (SpeedFusion Connect)
A fully mobile deployment, vehicles, vessels, pop-up sites, mobile clinics, is where these fundamentals rearrange most interestingly. The concepts do not disappear; they relocate. VLANs still segment traffic inside each mobile unit (staff vs. payment vs. guest on a vehicle, exactly as in a building). Spanning tree still protects the small local switch in each unit, but the units do not bridge to each other at Layer 2, they each tunnel back independently, so there is no stretched-L2 loop risk across the fleet. Routing across the fleet is handled by the SD-WAN fabric and a hosted SpeedFusion endpoint in the cloud, so every mobile unit connects back to a consistent point regardless of where it physically is or which cellular towers it is using at the moment. The mobile unit bonds whatever it can see (multiple cellular carriers, plus satellite when out of coverage) so it keeps a stable connection while moving, and presents a consistent identity to the applications even as the underlying links change constantly. In short: inside each unit, the fundamentals are unchanged; across the fleet, SD-WAN replaces site-to-site wiring and stretched Layer 2 with independent tunnels to a common cloud endpoint, which is exactly what makes a network of things that are all moving behave like one coherent, stable network.
Why it matters, and the case study
The reason this matters is that the cloud emptied the building. When the servers and the people left for the cloud and for everywhere, the WAN became the most important and most fragile part of the network. SD-WAN exists to make that part dependable, scalable, visible, and affordable.
A representative example from the field: a mobile mammography unit serving rural communities needed to move large medical images from places with no wired internet, and earlier attempts with single cellular links and high-latency satellite had failed at any price. The answer was to bond five cellular connections into one reliable link with a matching device at the data center, creating connectivity that simply did not exist in the traditional toolkit. Every fundamental in this document was present, addressing, routing, NAT, firewalling, but the thing that made it work was the SD-WAN layer bonding diverse links into one resilient whole. That is the pattern, over and over: the fundamentals build the network, and SD-WAN is what makes the modern, distributed, cloud-bound version of it actually reliable.
Closing note
Networking fundamentals do not go out of date. Addressing, switching, routing, segmentation, and security are as relevant as ever, and every engineer should know them cold. What has changed is the center of gravity. The network used to be built around a powerful core inside a full building. It is now built around an intelligent, resilient edge connecting a distributed organization to a cloud. SD-WAN, and SpeedFusion specifically, is the layer where the timeless fundamentals meet that new reality. Master the fundamentals in this document, understand how each one evolves at the SD-WAN edge, and you can design, build, and defend the modern network with confidence.
Prepared by West Networks for the Peplink Summit. The networking fundamentals described here are vendor-neutral and apply universally; references to Peplink and SpeedFusion illustrate how the SD-WAN layer specifically implements these concepts. For deeper technical configuration, consult the relevant standards documents and Peplink’s official documentation.