From: Michael K. <mic...@ip...> - 2019-10-04 20:34:40
|
Replying to my previous post. A wan-failover-track.script would also be handy to determine other conditions where you may to want it to return to the primary link e.g. there are calls in progress. This isn’t a problem for Wireguard as its usually quick enough to converge to not affect calls but I may be forced to use other VPN protocols which would. Regards Michael Knill On 28/9/19, 7:23 am, "Michael Knill" <mic...@ip...> wrote: Thanks Lonnie (I knew who you meant) and David Lonnie you are correct and I'm afraid that the old, iffy DSL primary links is in fact our new National Broadband Network on our old copper cabling ☹ Thanks David, you do make some good points. Actually accessing the system is no problems as I use VPN when on failover to access the Astlinux box and I can ping the Primary test IP Address for testing the Primary link. I'm afraid that something like no ping failures in the last 10 minutes wouldn't really cut it e.g. there are often bursts of packet loss during the day. Maybe in the last 30 minutes but hmm. Could there be a separate wan-failover-track.script which is tested prior to switching back to the Primary. If not there, switch back as normal, if result is 0, switch back as normal, if result is 1 then don't switch back for another Secondary delay? This would allow the checking complexity to be abstracted away from the failover code itself. Regards Michael Knill On 28/9/19, 5:05 am, "Lonnie Abelbeck" <li...@lo...> wrote: > On Sep 27, 2019, at 1:49 PM, David Kerr <da...@ke...> wrote: > > I'm sure that you meant to address that to Michael. Yes ... egg on face :-) David, (correct this time) you make good points and why I'm dragging my feet a little on this request. I think Michal Knill has some old, iffy DSL primary links and 4G/LTE is the secondary failover. Another thought would be an optional "ping over time" test while on secondary to only return when the primary has been clean (like no ping failures in last 10 minutes). Though looking at the code my head hurt thinking about implementing something like this. :-) Lonnie > > But to add my two cents here... I am very nervous about switching the network over to Secondary/Failover without an automatic mechanism to switch back. It may be fine 99% of the time but what if the secondary link fails? Even if the primary link was working fine, without a way to switch back automatically you could find yourself unable to connect from remote site. > > • If the secondary link is more reliable than the first, then why not swap them (make EXTIF eth1, EXT2IF eth0)? > • If you do want to switch over to Secondary for extended period then you would need some fancy firewall rules to make sure you could still at least login by ssh or get to the web interface from the Primary interface. This is necessary to make sure replies go back to the interface that incoming request arrived on, and not the default route. It is doable but non-trivial. I have implemented something similar to ensure that I can always get to my box over the Secondary link, even if Primary is the default route. > • Or, when you switch to Secondary link you move the "do I have internet connection" test from the primary to the secondary... in other words switch back to the primary not when the primary is back up again, but rather when the secondary fails. So the switch to failover is active until such time as the failover fails. > > David. _______________________________________________ Astlinux-devel mailing list Ast...@li... https://lists.sourceforge.net/lists/listinfo/astlinux-devel _______________________________________________ Astlinux-devel mailing list Ast...@li... https://lists.sourceforge.net/lists/listinfo/astlinux-devel |