2.3 and dpinger/gateway craziness
-
Hi,
I'm still a bit new to pfSense, so bear with me with me…
This upgrade to dpinger seems to be causing a race condition. I upgraded the 2.2 system (which was working fine). It has a single WAN but one of the interfaces is dedicated to a VPN (anything plugged into the switch on the interface has firewalled traffic forced over it). This was working without issue in 2.2.
After the 2.3 upgrade, dpinger seems to create a race condition. Streaming data over the WAN or the VPN creates no problems. However, downloading a file of pretty much any size triggers dpinger threshold latency limits - no matter how high I set them - and shuts down the interface. If I disable the gateway service, everything works just fine.
The connection to the firewall is over two dedicated T1 lines (yes, it's a remote location). Ping times are typically 25ms or less, and upload/download are in the 2.9 Mb/s range (which is as good as it will get for a while). When any file of any size is downloaded (for example, the 2.3 upgrade...), within a few MB of downloading, dpinger reports latencies over 1400ms and kills the connection (I continue to ease the thresholds up, but I'm now convinced that it will terminate regardless of the upper limit).
Again, what's odd is that streaming has no effect. I can stream audio or video all day long with no problems. Whenever I try to get a file, it chokes. Disabling dpinger eliminates the problem. I followed the sticky about changing the ping payload size to 1 and saving the file again, but no joy. Any thoughts on what to do next?
Any help appreciated.
Rip
-
Sounds like normal, expected behavior for a heavily loaded T1. Guessing pings from your LAN show roughly same. Up the threshold to maybe 3000 or so.
-
In remote places in Nepal with slow/crud internet, that usually have 200-300ms ping time, I have found that 3000, 4000 or even 5000ms threshold is needed for when people are downloading (particularly if they have a download manager that gets a bunch of streams going in parallel). The ping echo replies get held up in ISP router buffers somewhere behind loads of big download packets, waiting to be dribbled down to the site.
I imagine it would be good, if they would do it, for the ISP to prioritize ICMP so that the echo replies can "jump the queue" in front of the large download packets. -
I imagine it would be good, if they would do it, for the ISP to prioritize ICMP so that the echo replies can "jump the queue" in front of the large download packets.
In belgium there are isps with a download quota/month. When going over quota it limits speed from 200mbit –> 5mbit
they prioritize ICMP.So if a school has a multi-wan system & WAN1 goes over quota, gateway-monitoring notices nothing wrong while 300 devices are all trying to push their favorite selfie towards some form of asocial media......
prioritizing icmp is bad in those situation ... it would be better if the pings skyrocketted & things failover to WAN2
-
Yeh, it depends on the situation. In the case you describe, you want to failover even though the "primary" WAN is actually up (it is slow for a known reason).
In many cases the netadmin wants to know that the link is up (even if overloaded), and keep using it (because, for example, the backup link is even slower).
So "it depends".