Will the current 6-second link-failure detection time for SpeedFusion Connect be reduced in future updates?
As discussed in this thread - (Hot Failover - not failing over fast enough), I haven’t been able to achieve hot failover faster than around 6 seconds with SFC. This delay forces me to keep all WANs bonded constantly to avoid signal degradation during live-streamed events, which isn’t always efficient or necessary.
It would be great to know if this can be added to the roadmap.
Its one of the reasons why many use their own hosted FusionHubs or ask other hosting partners to help by providing SpeedFusion Hosting as a service (we do this at Venn globally).
However, you can use latency cut off as a way to achieve what you want. Put all WANs in the SFC tunnel, then set the latency cut off on all WANs.On the ones you want to use in the tunnel set them at a sensible level, on the WANs you don’t want to use set the cut off lower than they can achieve. This affectively removes them from active use in the tunnel - whilst keeping them available to be used in the tunnel.
When the primary WANs fail (or their latency rises above the cut off values set), since all active WAN latencies will be over the cut off value, the other WANs will be used. And you’ll have hot failover that reacts as fast as the latency measurement.
Hi Martin,
Thanks for the reply here and for the workaround.
I did give that a go, and found that I still experienced the same 6 second failover, even with the settings you suggested.
I was testing this on a Google Meet call however, what would be the best way to test this failover in real-time?
Would be nice to see Peplink be a bit more transparent about these services.
Best share some screenshots with your settings so we can review them.
This is indeed a very good way of setting WAN interface priorities in Speedfusion tunnels which I used a lot on much appreciated suggestion of Martin.
For SFC with its 6s failure detection there is one big drawback: when your preferred link is saturated, the traffic will be re-routed over the “backup WANs”: the ones with the unreachable low latency limit. This causes a drop in the traffic of the preferred but saturated WAN, which might in turn cause again a drop in its latency or packet loss, causing again (after 6s) a switch back to this preferred interface and thus a 6s endless switching loop…
