Curious to hear folks thoughts on the importance of individual WAN timeout and recovery configuration when it comes to SFC tunnels, given two possible scenarios:
Scenario 1 - WAN 1 and WAN 2 have equal priority (priority 1) within the SFC tunnel.
Scenario 2 - WAN 1 set to priority 1 and WAN 2 set to priority 2 within the SFC tunnel.
The followup question, what impact does WAN smoothing have on this? My understanding was that if you had equal priority on 2 links, with WAN smoothing enabled, that it shouldn’t matter if one link goes down even undetected because WAN smoothing essentially means whichever packet reaches the SFC cloud first takes priority. Unfortunately in practice this hasn’t been perfect - Starlink still causes blips on video calls. I’ve adjusted my SFC-Streaming tunnel to use WAN 2 priority, since that link is pretty stable, but just wondering if I’ve maybe not got my link-down detection not set aggressive enough and if maybe that was my problem when both links were set to equal priority somehow.
You need a more skilled/experienced person than me to really answer your question, but if this helps: Using SFC, I use Starlink as my WAN 1 and a slower but more reliable (fewer frequent, short drops) WISP as WAN 2. They are both set to priority 1 and I do no WAN smoothing, and it’s basically perfect. I fiddled with WAN smoothing just a bit and it made things worse for me.
I’m on Teams and Zoom much of the day, and often watch the status of both WAN links in real time. I see Starlink drop for a few seconds, and the WISP just “ramps up” instantly. There is no noticeable effect in the call or meeting. My system is now more reliable than that of my colleagues using Verizon Fios or Comcast cable with stock (ISP-supplied) routers.
If you want seamless failover you need to have both links at the same priority. (otherwise the health check must fail before the second link is used)
I have found that Wan Smoothing “medium” was needed to have no distortion of the audio stream in zoom calls during starlink drops. (the low setting would have a second or two of distorted audio) Each protocol is different, test your options, pull the cable on the flaky link during a call to check.
I have also started to use “fastest response” as the last default outbound policy rather than priority. With that setting all new TCP connections will get sent out both WAN links, and if Starlink is in its “down but not detected yet” state, the new sessions will pick the other WAN link. and after the 10 second detection timeout switch the established sessions.