The Multi-Wan failover functionality on the Flint 2 / GL-MT6000 appears to work correctly in terms of quickly switching from WAN1 to WAN2 when WAN1 is detected as "down".
However, when WAN1 comes back up, not all existing TCP/UDP streams are migrated from WAN2 back to WAN1.
From searching, it appears at one time (and possibly currently on other devices), there was an option called Forced Refresh Streams.
It's referenced in the latest Multi-Wan documentation under the Failover section:
Suffice to say, it looks like that option / functionality is needed (but missing) in order to have Multi-Wan failover (and then fail back) work as expected.
Can anyone shed any additional light on this? Is there a hidden setting somewhere in the Dashboard or in Luci that can achieve / force the desired functionality?
If the session has established, it cannot cut (fail) back to WAN1 from WAN2 if the WAN1 back to work.
The newly session can establish and go to WAN1 if the WAN1 back to work.
If cut (fail) it back, the session will be disconnected, and if the seesion is an audio-video conference connection, the connection will be dropped and reconnected, and the conference will be discontinued at that moment.
If you watch the live broadcast, if WAN1 back but it is intermittent and unstable, the video experience is too bad.
That is reason why the Multi-WAN will not cut (fail) back the WAN1 from WAN2 if the session is established, but the new session will go to WAN1.
Forced Refresh Streams has been removed for a long time, probably the docs has not removed, will update.
Thank you for the reply and thorough explanation — everything you said makes sense.
However, it would be nice to have Forced Refresh Streams back as an advanced option — maybe with a disclaimer like "Do not use unless you know what you're doing".
My particular use case does not involve any media or VOIP streaming, so having access to Forced Refresh Streams would solve my problem.
This is the second Flint 2 I have, and I really wanted to use it for this application, which requires 24/7 uptime AND high bandwidth usage. In this case, failing over to something like a secondary Starlink connection from a primary DOCSIS cable connection is better than having no secondary at all. But the need to fail back to the primary as soon as it's available again is absolutely paramount.
For now, I've had to switch over to a Ubiquity EdgeRouter X, which does indeed fail back the way I need.
Thanks again for your time and consideration on this matter.
So the TL;DR is if WAN1 dies, it will switch to WAN2 but will not switch back to WAN1 unless WAN2 dies or if the router is manually switched back to WAN1?
Is that accurate?
WAN2 will not switch back to WAN1 upon connection restore?
However I should mention that I'm not sure if NEW connections are established over WAN1 once it's back up. It's quite possible they may be.
For sure in my situation, existing TCP/UDP streams are not broken on WAN2 and migrated/reestablished on WAN1 once it's back up — and THAT is what I need.
For video conferencing, VOIP, etc, sure, it would be disruptive.
But for applications (P2P, etc) that account for those kinds of connection breaks, it's not disruptive at all.
And that's my point / issue — it would be nice if the option was made available to the end user. Default it to off, but having it available would allow me to continue to use my new Flint 2 in this case.
Anyway, I'm in a pre-production environment and can't really afford the time to swap out devices again just to test if NEW connections are established over WAN1 once it's back up. As indicated, I need current connections automatically broken on WAN2, allowing for them to reestablish themselves over WAN1.
No.
After the restore of WAN1, the newly established session/link will switch to WAN1.
The old sessions that have been established will continue to work in WAN2 first.
When the session is over, WAN2 will not be used, and subsequent new sessions are in WAN1.
This is to ensure that the originally established session will not be suddenly disconnected, which will affect the work or business.
In addition, if WAN1 is restored but not stable, so for the sake of conservatism, the session already established on WAN2 will continue connected until the session ends.
