In failover, are all WAN interfaces active/pingable? Is there a way to protect against bouncing?

One of the biggest issues I have with our current multi-wan router is that I cannot ping the secondary interface while in failover mode. Does the Peplink balance keep all ports ‘hot’, and simply make routing changes to divert traffic if a link is seen as ‘down’.

Another feature that interests me is a margin of safety to protect against interface bouncing. After failover, is there a setting for how long the primary interface has to be stable before switching back to it?

Thanks in advance!

Peplink can keep both primary and secondary link ‘hot’ and still route all traffic to primary link unless it is down. This is actually pretty simple to setup with Peplink - just a matter of choosing “Always-on” on both WAN link interfaces and make one simply outbound policy.

And yes by default Peplink will bring a WAN back if it passes health check 3 times in a row at 5 second interval. You can tune it longer or shorter to better fit your network.

Feel free to have a try on our web admin demo page here - you will be amazed by how easy it is.

There is a big bug in this logic: If a peplink has 2 WANs, both controlled by health checks, and 1 WAN goes down for repairs. This leaves only one WAN running. BUT, if it also has a momentary health failure (or is a little overloaded doing the work of two), the Peplink will actively turn the last WAN off also. This leaves zero WAN’s. Do you see what happened - the health check turned off the only remaining WAN. Wrong!

The correct procedure would be for the Peplink to stop doing health checks on the last functioning WAN - why would it want to turn it off?

I wish this bug would get fixed.

I see where you are coming from. And yes what you are saying is correct. But it would be valid only if health check returns a false alarm - if the last WAN goes down, we are cut off one way or another, with or without Peplink.

Health check is very accurate you are be sure. We have been helping many customers’ networks to stay up throughput the years without hearing anything bad on the accuracy of the health check.

And yes we will put up a feature request on fine-tuning the behaviour when we come down to the last functional link. Your idea of disabling health check when that happens is good. I am thinking to still route traffic to all health-check-failed links and report on the web admin dashboard that all links appear to be down so if user don’t have Internet, they can still log right in the Peplink web admin page can see what is going on - which I bet we would.

Thoughts? Your insight is appreciated :slight_smile:

Hi Kurt,

I think you missed the most important point. If you have only one WAN running, you don’t need a health check. The WAN will run to the best of its ability - your device is meaningless in a one WAN connection. Its only purpose here would be to poll the second WAN for its resumption. When your device interferes with a health check on the last running WAN and it fails, it will KILL the connection for 30 seconds… our only running connection. - Dumb!

Your device must not test for health on the last running WAN !

Yup. Make sense. But you are only thinking from 2-WAN environment in a failover topology with the primary WAN physically disconnected. I am coming from a multi-WAN angle factoring in the 3 different WAN statuses – health check passed, health check failed and physically disconnected.

My idea of keeping health check on the last WAN comes from more of a reporting angle. Health check will not disable the last WAN in any case. But I bet some user might still want to know the status of their last WAN as reported by health check on the web admin page. Say if the last WAN dies also, user can login to the Peplink and see that it fails health check (instead of health check disabled which doesn’t comfort the user very much I imagine) and there will be a message or something that says Peplink still passes traffic to this last despite of the health check status as a very last resort WAN so if Internet doesn’t work that means the last WAN is gone also.

This is what I was thinking - When a user is down to on his last WAN. Peplink will still do health check and report its status as it always does on the web admin page. But Peplink will not in any case disable it even if health check comes back negative.

Taking this one step further - Imagine a 5 WAN environment. 1 WAN reported physically disconnect. 3 WAN reported health check failure. We are down to the 1 last WAN. Now the modem of this last WAN dies making this WAN physically disconnected. What I was thinking is to still route traffic to all health-check-failed links and report on the web admin dashboard that all links appear to be down, but say Peplink is still forwarding traffic to WAN 2, 3 and 4 that are reported health check failed as a very last resort.

I hope it is clearer this way. Any thought on this?

YES, it does… That is the bug. Your health check, when running on the last remaining / functioning WAN will pick up bad health check, and then DISABLES the WAN, so we no have no WAN’s for 30 seconds (or what ever retry period is set). The last and only WAN will be killed off by your health check. Your router becomes 100% dead for 30 seconds, because your mis-placed health check killed it. Now do you get the bug?

Yeah I am with you. Just trying to see how we can fine-tune the mechanism while we are at it. We will sort this out.

And thanks for bringing this up. You and the community are driving a good product even better. Thanks again. :slight_smile: