Many deployments have a mix of low-cost primary WANs and higher-cost backup WANs. Operators often want traffic to remain on the primary WANs under normal conditions and only use the backup WAN when additional capacity is needed due to congestion or failure.
Example:
- Cellular 1: Unlimited data allowance
- Cellular 2: Unlimited data allowance
- Starlink: 50 GB/month allowance
Desired behavior:
- Under normal conditions, traffic is distributed across the two cellular links using dynamic weighted bonding (DWB).
- If one (or both) cellular links becomes congested or fails completely, additional traffic is automatically shifted to Starlink.
- When the cellular congestion subsides, traffic automatically shifts back to the cellular links and Starlink usage returns to a minimum.
Current behavior:
- The closet you can get to the desired behavior is to put all WAN links in a SpeedFusion tunnel with DWB as the traffic distribution algorithm. But then – obviously – DWB distributes traffic across all available WANs, including Starlink, even when the cellular links have sufficient available capacity.
I enumerated all the creative workarounds I could think of to achieve this (Configure SpeedFusion VPN to Prefer Primary WANs and Add Secondary WANs as Needed) but they all have shortcomings and don’t fully achieve the desired behavior. (Please read that post carefully before suggesting a workaround or existing solution here, because I believe I have enumerated all possible workarounds and why they fall short.)
Therefore, I request that Peplink implement one or more of the following features:
1. Use DWB to distribute traffic among same-precedence links in SpeedFusion Overflow mode
Modify the within a SpeedFusion VPN Overflow algorithm to use DWB (or allow the user to choose what traffic distribution algorithm is used) for WAN links that have equal Overflow Precedence.
2. Introduce a “Virtual Latency Penalty / RTT Offset” Parameter for Individual WANs in DWB
Allows the user to specify a “Virtual Latency Penalty” or “RTT Offset” to be added to expensive WAN connections (Starlink), so the DWB algorithm will prefer the lower-cost (cellular) connections, all other things being equal. It keeps the algorithm the same, but just gives it a slight (or strong) push toward favoring the cellular connections.
As suggested by DaveZ, implement this at the WAN level so it works for both Outbound Policies and VPN tunnels, and offer the option to set it either as an offset or as a floor.
3. Support VPN links when using Overflow within an Outbound Policy
The Overflow algorithm within an Outbound Policy currently only allows you to prioritize WAN connections, not VPN connections. However, other Outbound Policy algorithms (Priority, Weighted Balance, etc.) do allow you to use VPN connections, so Overflow could too.