I’ve got a peplink balance 20 loadbalancing a Timewarner Cable connection and a Verizon ‘high speed’ DSL.
I’m fairly satisfied with the peplink appliance - it is generally simple and clear
There is one issue I’ve been having with the health check on my DSL:
it’s down too much - I’m not sure if maybe there are issues between the interfaces on the peplink and my verizon modem - but I can run a successful ping test off the DSL network while at the same time the peplink admin page is showing that link as failing the test.
I think - at least with the configuration I have here - that the link failure detection is being too greedy. It seems to fail the test too easily.
Unfortunately I can’t seem to find any settings to address this problem - I have it whether I use DNS or Ping tests, HTTP doesn’t seem to be an option here either. Perhaps this is an issue with the quality of my DSL, but when I run a ping test off my laptop I see satisfactory results. Nothing indicating the outright failure the peplink seems to assume after a delay in response.
Is there a firmware upgrade that can fix this? Is there anything I can do to address this?
Everytime the DSL has the slightest hookup, the load balancer is shutting the interface down for WAY too long.
Its possible the DNS servers selected, are rather busy and just drop the ping requests. Try a different IP, like the Google DNS (8.8.8.8) or set the IP of your first hop / gateway.
On a few occasions, I have been blocked at 8.8.8.8. They do seem to monitor it, and if you ping it too much, you get dns redirected to a google page that says - your using an automated process - your now blocked for a day. That’s why I shifted to pinging to dumb router IP’s that have no monitoring.
Yeah, I never got the impression that the issue was related to being blocked - as it would occasionally pass.
So, I set the ping test to the default gateway for that interface - and I haven’t gotten a passed test yet. This test is too stringent - and when the peplink takes the interface down I can’t use the peplink gui to try to manually ping.
64 bytes from 192.168.1.1: icmp_seq=0 ttl=64 time=3.723 ms
64 bytes from 192.168.1.1: icmp_seq=1 ttl=64 time=7.158 ms
64 bytes from 192.168.1.1: icmp_seq=2 ttl=64 time=3.857 ms
64 bytes from 192.168.1.1: icmp_seq=3 ttl=64 time=4.604 ms
64 bytes from 192.168.1.1: icmp_seq=4 ttl=64 time=4.359 ms
64 bytes from 192.168.1.1: icmp_seq=5 ttl=64 time=3.835 ms
64 bytes from 192.168.1.1: icmp_seq=6 ttl=64 time=1.369 ms
64 bytes from 192.168.1.1: icmp_seq=7 ttl=64 time=3.773 ms
64 bytes from 192.168.1.1: icmp_seq=8 ttl=64 time=1.593 ms
64 bytes from 192.168.1.1: icmp_seq=9 ttl=64 time=6.121 ms
64 bytes from 192.168.1.1: icmp_seq=10 ttl=64 time=4.081 ms
64 bytes from 192.168.1.1: icmp_seq=11 ttl=64 time=1.396 ms
64 bytes from 192.168.1.1: icmp_seq=12 ttl=64 time=7.967 ms
64 bytes from 192.168.1.1: icmp_seq=13 ttl=64 time=4.059 ms
64 bytes from 192.168.1.1: icmp_seq=14 ttl=64 time=2.605 ms
64 bytes from 192.168.1.1: icmp_seq=15 ttl=64 time=3.963 ms
64 bytes from 192.168.1.1: icmp_seq=16 ttl=64 time=1.437 ms
64 bytes from 192.168.1.1: icmp_seq=17 ttl=64 time=2.633 ms
64 bytes from 192.168.1.1: icmp_seq=18 ttl=64 time=6.640 ms
64 bytes from 192.168.1.1: icmp_seq=19 ttl=64 time=1.346 ms
64 bytes from 192.168.1.1: icmp_seq=20 ttl=64 time=3.592 ms
64 bytes from 192.168.1.1: icmp_seq=21 ttl=64 time=3.864 ms
64 bytes from 192.168.1.1: icmp_seq=22 ttl=64 time=4.942 ms
64 bytes from 192.168.1.1: icmp_seq=23 ttl=64 time=3.939 ms
64 bytes from 192.168.1.1: icmp_seq=24 ttl=64 time=1.412 ms
64 bytes from 192.168.1.1: icmp_seq=25 ttl=64 time=3.639 ms
64 bytes from 192.168.1.1: icmp_seq=26 ttl=64 time=1.451 ms
64 bytes from 192.168.1.1: icmp_seq=27 ttl=64 time=30.058 ms
64 bytes from 192.168.1.1: icmp_seq=28 ttl=64 time=9.068 ms
64 bytes from 192.168.1.1: icmp_seq=29 ttl=64 time=1.516 ms
64 bytes from 192.168.1.1: icmp_seq=30 ttl=64 time=1.627 ms
64 bytes from 192.168.1.1: icmp_seq=31 ttl=64 time=1.326 ms
64 bytes from 192.168.1.1: icmp_seq=32 ttl=64 time=1.209 ms
64 bytes from 192.168.1.1: icmp_seq=33 ttl=64 time=1.145 ms
64 bytes from 192.168.1.1: icmp_seq=34 ttl=64 time=2.410 ms
64 bytes from 192.168.1.1: icmp_seq=35 ttl=64 time=1.346 ms
64 bytes from 192.168.1.1: icmp_seq=36 ttl=64 time=1.236 ms
64 bytes from 192.168.1.1: icmp_seq=37 ttl=64 time=4.133 ms
64 bytes from 192.168.1.1: icmp_seq=38 ttl=64 time=1.115 ms
That’s what I get from my own computer - it seems like this should be acceptable - if it isn’t can peplink advise me on what the heck I can do to keep this interface up?
I’ve got my ISP sending me a new router - so hopefully that will respond to pings fast enough for the peplink balance, but I wish there was a way for me to make this test not so stringent. I’d disable the health checking but it would essentially make the balance useless.
In the meantime I switched backed to a DNS check as that occasionally worked
Thanks for the screenshot - I don’t know how I missed those settings. I’ve received a new device from our DSL provider and the service has been a little more consistent, especially with some minor changes to the health check behavior.
However - I still can’t hit my WAN2’s default gateway with a ping using the peplink GUI’s troubleshooting tools. I can hit the default gateway with a laptop hooked up to the same switch in the back of the modem, but not the peplink. Any ideas on why? I must have some sort of service issue seeing as how my DNS health check isn’t very consistent - but I don’t think that issue is consistent with why I can’t ping the gateway. I’d really prefer to use that as a health check - but at this point it’s just a curiosity I’d like to clear up.
I’m becoming increasingly convinced that the peplink is the issue considering that I can ping the gateway from my laptop, and I can’t ping anything with the peplink, my gateway or DNS. Which is pretty surprising considering that I am able to occasionally receive a DNS reply.
I have a brand new modem from verizon yet it’s the peplink that is still behaving the same. If the issue was my verizon modem - what could be causing it considering that anything else plugged into the modem works perfectly fine?
In this situation, we suggest to contact our support by create a support ticket, obtain the diagnostic report and turn on remote assistance of the Peplink Balance unit. Please also mention this forum thread in the support ticket.
I contacted support, thanks for the recommendation.
I switched my verizon connection to PPPoE and got the login info from my ISP and it’s been incredibly stable since. I’m pretty sure the connection isn’t great (duh, it’s DSL), but my gateway is always responding promptly and the interface hasn’t been taken down in 5 days (a new record!).
Obviously double-NATing is generally frowned upon (my other interface is double-NAT’d once it passed through the peplink), but I can’t really determine why that would prevent my gateway (the router in question) from responding to pings quickly - but hey, it works now. no complaints
So if anyone else has this issue - try getting a public IP on the peplink interface at issue
