Configure SpeedFusion VPN to Prefer Primary WANs and Add Secondary WANs as Needed

Product Discussion
1

We have a fleet of 20 vessels equipped with MAX BR2 Pro 5G routers running dual cellular (AT&T + Verizon) and Starlink, which are bonded using Dynamic Weighted Bonding (DWB) over a SpeedFusion VPN connection to a SpeedFusion Hub on shore.

The cellular plans allow unlimited usage, but Starlink usage is limited.

I’m looking for a way to deprioritize Starlink so it’s only used when either (or both) of the cellular connections is congested or failed.

EXISTING FEATURES THAT I DON’T THINK SOLVE THE PROBLEM

(click the triangle to expand)

SpeedFusion RTT Threshold (a.k.a. Congestion Latency Level)

If cellular had a significantly lower latency than Starlink, then DWB would naturally prefer cellular to Starlink, but that isn’t the case in practice. Starlink latency is often comparable to cellular. Just to confirm, I even tried adjusting the RTT Threshold from the default (Medium) to Low so it more aggressively prefers lower latency connections, but it didn’t help.

SpeedFusion Max Latency Diff or Cut-off Latency

Again, if cellular had a significantly lower latency than Starlink, then using the Max Latency Diff parameter would cause Starlink to be not just unfavored, but completely suspended, until both cellular connections’ latency got high enough that the difference between cellular latency and Starlink latency was below the Max Latency Diff threshold.

Or I could configure the WAN Connection Priority inside the SpeedFusion Profile settings such that both Cellular connections were Priority 1 and Starlink was Priority 2, and then specify a Cut-off Latency (“Maximum round trip time before this connection is temporarily suspended”) on the Cellular connections.

Aside from the fact that Starlink doesn’t have consistently higher latency than cellular, these features also don’t quite do what I want: If cellular gets congested and its latency goes up, using either of these settings would cause the cellular connections to be completely suspended, resulting in all traffic going to Starlink, instead of allowing the cellular connections to share the load as best they can. It would end up disabling the two cellular connections at the worst possible time – when demand is high and we need all possible WAN connections.

If instead these features functioned as “Enable Priority 2 WAN when the latency of Priority 1 WAN exceeds threshold”, then that would work. But it’s currently implemented as “Disable Priority 1 WAN when latency of Priority 1 WAN exceeds threshold”, which is quite different and not helpful.

WAN Priority on Dashboard

I can modify the priority of WAN connections and set both Cellular 1 and Cellular 2 to Priority 1 and Starlink to Priority 2, but this means:

  • The cellular connections would need to be fully failed (not just congested or degraded) before Starlink would kick in;
  • Cellular 1 & 2 would both will need to be detected as fully failed before it would use Starlink. I’d like Starlink to kick in when at least one cellular connection fails;

If I set both Cellular 1 and Cellular 2 to Priority 1 and Starlink to Priority 2 and enable “Independent from Backup WANs” on one cellular link, then this would allow Starlink to be used when that one cellular link is fully down, but not when it’s congested or degraded. And this would only work for one cellular or the other, not both, because if I enable “Independent from Backup WANs” on both cellular links, Starlink would always be enabled.

WAN Connection Priority within a SpeedFusion VPN Profile

I can modify the priority of WAN connections and set both Cellular 1 and Cellular 2 to Priority 1 Starlink to Priority 2, and specify a Cut-off Latency for Cellular 1 & 2), but similar to above:

  • Cellular 1 & 2 would both will need to be detected as degraded (or fully failed) before it would use Starlink. I’d like Starlink to kick in when at least one cellular connection degrades or fails;
  • And again, I don’t want to suspend cellular when it gets congested – I just want to enable/add Starlink to the pool.
Overflow within a SpeedFusion VPN Profile

I can change the SpeedFusion VPN Traffic Distribution Mode from DWB to Overflow (this option can only be seen via the “SpeedFusion VPN Traffic Distribution Mode” button in support.cgi), set both cellular lines to Overflow Precedence 1, and set Starlink to Overflow Precedence 2.

But the traffic distribution mode for same-precedence links is not documented (I asked about it here), so I assume it uses basic bonding (round-robin) – not DWB – which will give bad performance.

Overflow within an Outbound Policy

I can create two SpeedFusion VPN subtunnels:

  1. Set Cellular 1 & Cellular 2 at Priority 1, Starlink disabled, and set SpeedFusion Mode to DWB.
  2. Set Cellular 1 & Cellular 2 & Starlink all at P1 and set SpeedFusion Mode to DWB.

Next create an Outbound Policy configured to use Overflow as its algorithm.

The problem is that Overflow within an Outbound Policy only allows you to prioritize WAN connections, not VPN connections.

“Impossibly Low Latency Cut-off” Workaround

As described in Quicker SpeedFusion Connect link failure detection times - #2 by MartinLangmaid, I could:

Put all WANs in Priority 1 inside the SpeedFusion profile. Set a reasonable Latency Cut-off for Cellular 1 & 2, but an unreachably low Latency Cut-off on Starlink.

In normal usage, Cellular 1 & 2 are used (with DWB! Yay!), but If both cellular connections fail or their latencies spike, we fall into this case described in the WAN Connection Priority tooltop: “If all the connections in the same priority group have been suspended, the best connection in that group will be selected, ignoring the cut-off latency values.” Thus, Starlink is pulled in.

The problem is that this suspends the cellular connections instead of keeping them active and adding Starlink. Furthermore, it can lead to a flapping loop: Quicker SpeedFusion Connect link failure detection times - #7 by PeterDedecker

POSSIBLE SOLUTIONS

I think this use case requires Peplink to implement a new feature. Here are some suggestions.

Before I post these in the Feature Request forum, I’d like to know everyone’s thoughts on whether this is indeed not currently possible, and if not, which of these features sounds the most useful (and/or easiest for Peplink to implement):

1. Enable DWB for 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.

Then, when I set both cellular lines to Overflow Precedence 1 and set Starlink to Overflow Precedence 2, it will use DWB between Cellular 1 & 2, and only send overflow traffic to Starlink when both cellular links are congested.

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.

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.

If it did, I could make use of it as described in the section “Overflow within an Outbound Policy” above.

Related Posts:

3 Likes
2

+1 This could be a useful feature I would use at times

3

You can avoid the flapping by setting the link failure detection time to <1s (extreme). Cause some additional overhead, but makes it way more stable and actually prefers the WANs with reasonable cut-off latencies above the WANs with unreasonably low cut-off latencies. The later ones only kick in when the first ones are saturated.

You can also play a bit more by creating subtunnels and introducing some variation in the cut-off latencies for the prefered WAN interfaces and distributing your traffic over these tunnels using outbound policies. Then the kicking in of the secondary WAN-interfaces will happen more gradually.

3 Likes
4

But indeed, it would be a nice feature.

5

Can you expand on this?

I can create multiple subtunnels, each with its own WAN Priorities and WAN Cut-off Latencies (and subtunnel bandwidth limits, if I want).

Are you suggesting using a single outbound policy to distribute traffic between these multiple subtunnels? If so, which traffic distribution mode would I use? The only traffic distribution modes that can split traffic across multiple VPN tunnels (either at once and/or in sequence) are: Weighted Balance, Persistence, and Priority.

Or are you suggesting creating multiple, cascading outbound policies with “When No Connections are Available" set to “Fall-through to Next Rule,” and each policy would distribute traffic over a single subtunnel? And if so, how do I get a subtunnel to fully fail so it cascades to the next outbound rule? And wouldn’t that cause session disconnections when a rule fall-through occurs?

Or are you suggesting segmenting traffic by importance (basically, QoS) and sending traffic over different subtunnels according to its importance using outbound policies – one subtunnel per policy?

6

2. Introduce a “Virtual Latency Penalty / RTT Offset” Parameter for Individual WANs in DWB

This would be nice.

More generally, I’d want this latency “fudge factor” policy at the WAN level so it works for both outbound policies as well as DWB tunnels.

Personally, I’d bet that it implementing it as a “floor” instead of an offset would yield better and more predictable results. For example, if the floor is 100 ms, then the min RTT will always be 100 ms (even if the observed latency happens to be lower).

1 Like
8

A real distribution of traffic looks best to me. Weighted Balance could indeed distribute traffic over those subtunnels, although that wasn’t my first idea on this question.

A cascading approach wouldn’t work, as you said, as the subtunnel will never fail.

Manual segmentation would be my preferred option. This can indeed introduce some QoS aspects. E.g. the most important (but preferably not heavy) traffic can be routed over the subtunnel with the lowest cut-off latency on the primary WAN. This will offload part of this high-priority traffic over the secondary WAN without interruption. It will also lower the load on the primary WAN, lowering the chances that the (higher) cut-off latencies on the primary WANs in the other subtunnels are exceeded.

I never configured it this way, but it seems a nice approach to me, given previous experiences.

9

@Zakk_Stewart @PeterDedecker @DaveZ I’ve posted this as a feature request here: Allow SpeedFusion to Prefer Low-Cost WANs and Overflow to Secondary WAN(s) When Congested

3 Likes
10

Were currently trying to help in a situation where this would be used.
The idea would be to utilize cellular connections as long as 11Mbps can be achieved, and when it can’t introduce a satellite WAN to be bonded, or used as a supplement to the available cellular throughput.

2 Likes