Part Eleven: Outbound Policy and WAN Load Distribution
The topic
Outbound policy is how a Peplink router decides which WAN a given flow should use, the traffic-shaping and steering layer that sits alongside SpeedFusion. Even before any tunnel is involved, the router has a rich set of algorithms for distributing traffic across multiple WANs, and these are configured per-rule, often by application, source, destination, or even country and SaaS service (the latter two only configurable through InControl 2).
The algorithms
- Weighted Balance — distribute traffic across available WANs by a configured load weight.
- Persistence — keep traffic from the same machine on the same WAN, so anything that breaks when its public IP changes (banking, some SaaS logins) stays put.
- Enforced — send traffic through a specified connection regardless of that connection’s health. Use deliberately; it does not fail over.
- Priority — use the healthy connection with the highest configured priority; fall to the next when it fails.
- Overflow — use the highest-priority healthy connection until it saturates, then spill new sessions to the next.
- Least Used — send new traffic to the healthy connection with the most available downlink bandwidth.
- Lowest Latency — periodically probe latency on all selected healthy links and route new traffic to the lowest-latency one.
How it works on Peplink
Rules are evaluated top-down, and you assign them by tag in InControl for fleet-wide consistency. Outbound policy and SpeedFusion work together: policy decides which traffic enters which sub-tunnel (or bypasses the tunnel entirely for ordinary browsing), and SpeedFusion decides how that traffic rides the member links inside the tunnel. SaaS and regional steering, sending Microsoft 365 or a specific provider out a particular path, is an InControl-only capability and a common reason to manage outbound policy centrally rather than per-device.
Why it matters
Outbound policy is where you reconcile “bond the critical stuff” with “don’t waste tunnel overhead on Netflix.” Persistence in particular solves a whole class of “the app logs me out randomly” complaints caused by a session’s public IP changing across links. Getting outbound policy right is what makes a multi-WAN site feel deliberate rather than chaotic.
Field note
Apps that break when their public IP changes need a Persistence or Enforced rule, the same lesson as the NAT and firewall sections of the fundamentals paper. When a customer reports random logouts on a multi-WAN site, suspect a missing persistence rule before you suspect the application.
A cost best practice from the SpeedFusion Whitepaper: use Overflow (or WAN priority) to put the affordable links first and let the expensive ones, metered cellular, pay-per-GB satellite, carry traffic only once the cheap links fill. On a site with fiber plus a cellular backup, this keeps the meter near zero in normal operation while still bonding everything in when demand spikes or the primary fails.
From the field — one mine, two policies: At a large mine site, corporate traffic was bonded back to headquarters over SpeedFusion while general user internet was simply load-balanced across the Starlinks, affordable links carried first. That is outbound policy doing its job: protect what matters on the tunnel, keep the cheap path busy, and don’t waste tunnel overhead on casual browsing.
Part Twelve: Layer 2 vs. Layer 3 over SpeedFusion
The topic
SpeedFusion can carry traffic two fundamentally different ways, and choosing between them is one of the most consequential design decisions in a multi-site Peplink deployment. A Layer 3 SpeedFusion tunnel routes between sites: each site keeps its own subnets, and the tunnel forwards packets between them like any routed link. A Layer 2 SpeedFusion VPN bridges sites: devices at different physical locations behave as if they are on the same local network segment, sharing one broadcast domain.
How it works on Peplink
A Layer 2 VPN makes remote devices appear local, which is exactly what you want for things like operating a printer or access point at another site, reaching a NAS, or server-to-server communication that assumes a shared segment. You can apply Layer 2 to the whole VLAN trunk (in which case all router traffic crosses the VPN and is treated as LAN traffic by the remote site) or to a single VLAN (in which case only that VLAN’s traffic is bridged). The recommended pattern for mixed networks is precise: do not enable the global Layer 2 checkbox and also enable Layer 2 on a specific VLAN in the router UI. Instead, for selective or mixed L2/L3, create a dedicated sub-tunnel and enable Layer 2 on it for the specific VLAN that needs bridging (for example, an IoT VLAN), and keep your routed traffic on separate Layer 3 sub-tunnels.
Because Layer 2 bridging extends a broadcast domain across the wide area, Spanning Tree (STP) matters: enable it on the L2 sub-tunnel to prevent loops across the bridged sites, and plan path cost and root bridge deliberately, exactly the spanning-tree discipline from the fundamentals paper, now applied across a tunnel instead of across a switch closet. And keep OSPF off the L2 segments; L2 bridges do not need a routing protocol, and running OSPF over a bridged segment invites trouble. OSPF belongs on your L3 sub-tunnels.
 A SpeedFusion bonded Layer 2 bridge (VLAN 3103) stretching one subnet across sites, so remote devices behave as if locally attached. The same head end advertises the block via BGP for direct public-IP access, a real mixed L2/L3 design (West Networks Visio library, 2023).
Why it matters
Stretched Layer 2 is powerful and occasionally necessary, but it carries the same risks across a tunnel that it carries in a building: a loop becomes a wide-area broadcast storm, and a misconfiguration takes down more than one site. The discipline is to bridge only what genuinely needs to be on the same segment (often a single VLAN), route everything else at Layer 3, and never blur the two by enabling global and per-VLAN L2 at the same time.
Field note
The most common L2 mistakes in the field are enabling global Layer 2 and per-VLAN Layer 2 simultaneously, forgetting STP on the bridged sub-tunnel, and unintentionally leaving OSPF enabled on an L2 segment. If a bridged deployment shows broadcast storms or intermittent reachability, check STP on the L2 sub-tunnel and confirm the root bridge and path costs are set correctly before anything else.
From the field — Sutter Health tertiary connectivity: A hospital needed fully diverse mission-critical backup, so the design ran SpeedFusion over Starlink, OneWeb, and 5G and carried the customer’s routing across a Layer 2 tunnel between the data-center and site routers. Bridging that one segment at Layer 2 let their existing routing run unchanged over the bonded, diverse WAN.
Part Thirteen: OSPF on Peplink
The topic
OSPF (Open Shortest Path First) is the interior routing protocol you will most often integrate with a Peplink edge, and the Networking Fundamentals paper covers what it is and how it floods link-state information to build a loop-free routed topology. On Peplink, OSPF is how the SpeedFusion edge participates in an enterprise’s existing routed network, advertising and learning routes dynamically rather than relying on static routes everywhere.
How it works on Peplink
You enable OSPF under Network > OSPF, place the relevant interfaces in an area (commonly area 0.0.0.0 on the LAN interface), and choose what to advertise, the LAN, specific VLANs, and the SpeedFusion routes. The important discipline, drawn straight from our Level 2 and Level 3 workshops, is to advertise OSPF only on the untagged LAN and the user VLANs that should be routed, over the Layer 3 sub-tunnel(s), and to keep OSPF off Layer 2 segments and off VLANs that are meant to be isolated (guest, IoT). Routes then propagate across the SpeedFusion L3 sub-tunnel so remote sites learn how to reach protected subnets dynamically.
OSPF over SpeedFusion integrates cleanly with enterprise firewalls. In our Level 3 work, a Peplink edge peers OSPF with a Palo Alto (or similar) so the firewall keeps doing inspection while SpeedFusion bonds the WANs underneath: you enable OSPF on the Peplink LAN interface, enable it on the firewall’s virtual router and the connecting interface, and verify adjacency with the firewall’s show ospf neighbor and Peplink’s OSPF status page, then confirm with a live traceroute from a remote site to a protected server.
 OSPF area 0.0.0.0 carried across a SpeedFusion tunnel: each side advertises its LAN/VLAN subnets and learns the other’s, so routes propagate dynamically over the bonded WAN (West Networks Visio library, 2023).
Why it matters
OSPF is what lets SpeedFusion drop into an existing routed enterprise non-disruptively. Rather than re-architecting the customer’s network, you peer the Peplink edge into their OSPF domain, advertise the right subnets, and let the bonded WAN become just another (much more reliable) path the routed network already understands. It is the difference between “rip and replace” and “add Peplink alongside what you have.”
Field note
When OSPF routes go missing or adjacencies flap over SpeedFusion, check three things: that OSPF is enabled only on the untagged and user VLANs over the L3 sub-tunnel (not on L2 segments), that multicast is permitted over the SpeedFusion policy (OSPF relies on multicast hellos), and that the SpeedFusion link-failure-detection sensitivity is not so aggressive that it tears down the path faster than OSPF’s adjacency timers expect. Allow OSPF’s protocol traffic (IP protocol 89) through any firewall in the path.
From the field — bonded broadcast with OSPF: A live-video boat build bonded three cellular bands (N25 + N41 + N77) over SpeedFusion and ran OSPF across the tunnel so the studio and the vessel exchanged routes dynamically as the bonded path came and went. OSPF over SpeedFusion let the broadcast network treat the bonded WAN as just another routed link.
Part Fourteen: BGP on Peplink
The topic
BGP (Border Gateway Protocol) is the protocol of the internet’s routing table, and the Networking Fundamentals paper covers it in depth, ASNs, eBGP versus iBGP, the private ASN ranges. On Peplink, BGP shows up in two distinct roles, and it helps to keep them separate in your head. First, as an enterprise integration tool, peering a Peplink edge with a customer’s firewall or core router to exchange routes. Second, as the mechanism behind stable public IP via SpeedFusion, the way West Networks (and Peplink-hosted infrastructure) presents a consistent public identity while bonding diverse links underneath.
How it works on Peplink
For enterprise integration, you configure BGP under Network > BGP, set the local AS number, and define the neighbor, the firewall or router’s IP and its AS, then peer. A common pattern from our Level 3 workshop: the Peplink runs AS 65101 and peers with a Palo Alto on AS 65102 (both private ASNs from the fundamentals paper’s table), they exchange route tables, and a prefix-list filters the advertisement so only a specific subnet is shared, for example advertising only a healthcare subnet like 10.10.10.0/24 across the link rather than the whole table. You verify by inspecting the BGP route tables on both ends.
For stable public IP, the principle from the fundamentals paper applies directly: West Networks holds its own ASN and IP space and announces it with BGP, so to the outside world we present a single, consistent front door, while underneath that announcement SpeedFusion steers our own traffic across multiple diverse links by real-time performance rather than by BGP’s slower topology-based logic. A customer can be given a stable public IP that lives on the SpeedFusion fabric (via SF + BGP, or via a FusionHub) so their inbound services keep one address even as the physical links beneath change.
 A clean dual-ISP BGP design: advertise one public block (VLAN 100) to two providers under their respective ASNs, reject everything else, and use BFD so a dead peer is detected in milliseconds. The customer keeps one stable public /24 no matter which ISP is carrying it (West Networks Visio library, 2023).
Why it matters
BGP is what makes Peplink a peer in a serious routed environment rather than a black box bolted onto the edge. The enterprise-integration role lets you slot a bonded WAN into a customer’s existing BGP design and control exactly which routes cross. The stable-public-IP role solves the multi-WAN problem that breaks inbound services: with several ISPs you have several public IPs that change independently on failure, and BGP-plus-SpeedFusion replaces that churn with one durable address.
Field note
Allow BGP’s transport (TCP 179) through any firewall in the path, and where SpeedFusion is behind another firewall, forward the SpeedFusion data ports as well. Use prefix-lists deliberately: the default instinct to “advertise everything” is exactly wrong in an integration scenario, where the customer usually wants only one or two subnets reachable across the peering, advertise the one public block and reject all else, as the dual-ISP design above does. Pair BGP with BFD (Bidirectional Forwarding Detection) so a dead peer or path is caught in milliseconds rather than waiting on BGP’s much slower hold timer; on a multi-WAN public-IP design that is the difference between a failover nobody notices and a minute of dropped sessions. Keep the public-IP story and the integration story separate when explaining it to a customer, because conflating them confuses everyone.
From the field — killing the MPLS single point of failure (Darthtech): A bank’s traditional MPLS edge was a single point of failure, one link or provider problem took a branch down. Replacing it with Peplink and SpeedFusion, with BGP for a stable public identity, gave diverse bonded WANs under one consistent front door, so a circuit failure became a non-event instead of an outage.