'Fastest response' fails if one connection down

I have 3 connections balanced on ‘Fastest response’ method.

Now one connections runs out of traffic and ISP blocks it. Two remaining connections still work. What ‘Fastest response’ should do? It even does not need any health checks - just put traffic on that one who responds faster.

What ‘Fastest response’ practically do? Hang! Nothing works!

Looks like algorithm’s waiting to have responses from all selected connections until it choses the fastest one. And obviously will wait forever to get response from non-healthy connection. I don’t have any other explanations. Once I manually disconnect problematic connection, everything works again.

Sounds like a bug to me.
Fastest Response should send new requests to any new public IP via all the available WAN interfaces. Whichever connection gets a response back from that IP first is the WAN link that will be used for all future communication with that public IP.

In this situation is the WAN that’s run out of data showing as red or green on the dashboard?

2 Likes

Fastest Response send traffic to WAN with first reply packet (not wait for reply from all selected WAN) and will not send traffic to health check failed WAN.

Did you enabled Health Check on the blocked WAN? Does the ISP intercept your HTTP session and return something (e.g. Quota exceeded)?

3 Likes

Connection stays green probably because default (I guess) health check setting is DNS records. When ISP blocks traffic it probably does not block its own DNS servers. So connection stays green. Now I changed this to Google’s DNS.

The only way I know connection is broken then is by checking WAN Quality page in Status section. There I can see that pings/latency chart is empty.

Still I cannot understand why I’m not getting provider’s ‘quota exceeded’ page if this channel is fastest or requested resource through any other working connection.

i am having the same issue. system installed on a yacht. usually have three wan sources: cellular, wifi as wan 2.4ghz and wifi as wan 5ghz. problem is usually at least one wan is not reliable and wan conditions change based on various factors such as movement, location, network being overloaded by too many clients (i.e. no bandwidth available), etc. if i leave all three WANs on priority 1 and use the fastest response algorithm, when one connection stops passing data or starts failing everything gets hung up and i have zero internet. i have to manually log-in and disable that wan to have any connectivity at all. as soon as i disable the problem WAN internet is back working and i get 50+ mbps. it makes no sense. i think there is a bug as traffic should be routed over the other 1 or 2 WANs that do have good connectivity and manually intervention should NOT be required.

@SLR, @mystery. Please do me favor below when the problem is occurring. Please take note, perform action below when everything is running fine will not help to diagnose the problem.

  1. Login to Peplink/Pepwave router.
  2. Enter http://<LAN IP>/cgi-bin/MANGA/support.cgi.
  3. Navigate to Network Capture > Start.
  4. Let it runs for 3 minutes.
  5. Navigate to Network Capture > Stop > Download.

Then submit a ticket with 2 files above for us to investigate.

Thanks.

2 Likes

Ticket # 9070529 submitted

recommendation has come from support that the https persistence outbound rule could be playing a role. i will disable and see how that works but am concerned that i will start having authentication issues across websites…

they also recommended changing from ping to http health check. i tried some major websites like dell.com, yahoo.com, even peplink.com but health check keeps failing. i am wondering if its because these websites re-write HTTP to HTTPS? how can i find two websites to use for the HTTP health check? is there any reason peplink cant do a HTTPS health check?

thank you

Update: Peplink is logging a feature request to make HTTPS health check available since most websites no longer operate on HTTP. I have noticed an improved experience since disabling HTTPS persistence. No ill effects…yet.