Failover Advanced Option
-
Curious if this would be an easy change? And if anyone else would like to see it..
It would be nice in my opinion if an option for trigger level would include "Packet Loss and High Latency"..
Im trying to speed up the failover just a bit without false triggering. Im a little spoiled with another commercial product out there that we use where I work. (failover happens within a second or two.)
-
I would be careful with an AND-style trigger here. In a real WAN problem you often see either loss or latency first, not both at the same time, so “packet loss and high latency” could actually delay failover instead of making it cleaner.
For avoiding false triggers, I would first tune the gateway monitor target and the dpinger thresholds/intervals per gateway. A very fast 1–2 second failover is possible in some setups, but on an Internet WAN it can also flap quickly if the monitor host or upstream path has a short hiccup.
-
@giuliafw70 Thanks!
I only use "Packet Loss" now and it seems to bring it in around 13 seconds which isn't the end of the world.. I figured though if I had an "and" option that I could dial down to tighter numbers for packet loss and during an actual outage the latency would increase at the same time triggering a bit sooner.. but I see your point.
During evening hours we tend to go up in latency to my first gateway to over 30ms. (its normally somewhere from 8ms to 12ms.) I do not want that by itself triggering an outage so would have to at least double that to stay away from false triggering.
Ill keep trying to tighten it up a bit more.
-
One practical way to get closer without an AND trigger is to separate the two problems: use packet loss as the actual trigger, then make latency less sensitive than the evening baseline. If your WAN normally sits at 8-12 ms but sometimes reaches 30 ms, I’d avoid setting the high-latency alarm anywhere near 30; use the dpinger advanced values per gateway and leave enough headroom that the monitor target itself does not become the flap source. Also worth testing with a monitor IP inside the ISP/upstream path versus a public resolver, because that choice can change the failover time more than the trigger label.
-
The default of 2 pings per second offers a reasonable detection time while not annoying the ping target. That said, I've also seen people operate with 20 pings per second and a 5 second time interval to achieve very fast failover detection.
It's a trade off. You can detect outages quickly, or you can be nice to your ICMP target. I generally recommend being nice to your target unless you have specific permission from the administrator.
-
Thanks everyone..
With a little playing I am down to 10 seconds which is not terrible even if we are on a Zoom call if it happens.
Every time I believe our ISP has to good of an uptime to worry about it someone runs over a telephone pole somewhere or a tree falls taking down a fiber route.. Lost power to the node just a few days ago and it is painfully obvious that the ISP needs to replace the battery there..
Ill keep messing with it.
