Packet drops
-
What causes PFSense 2.4.3-RELEASE-p1 to drop packets?
Traffix shaper is enabled using default values (prioritize ACK etc).
There is bandwidth available. I see no reason why PF is dropping WAN packets.
See attached example.
-
It's probably the ISP/upstream dropping them, not pfSense. Or the ping target itself.
If you have gateway monitoring on WAN (the default setting), the system is automatically keeping track of two pings per second in Status > Monitoring.
From there select settings, change the left axis to Quality / WANGW (or the local equivalent).
A good place to start with Options: 8 hours, Resolution: 1 minute.
Another place to check is in Status > System Logs, Gateways. Any events there with "Alarm" in them are times when the ping monitor had excessive loss or latency.
A failure will look something like this:
Jan 7 15:05:31 dpinger WANGW 8.8.8.8: Alarm latency 0us stddev 0us loss 100%Lines like this are just the dpinger process starting or reloading and are normal:
dpinger send_interval 500ms loss_interval 2000ms time_period 60000ms report_interval 0ms data_len 0 alert_interval 1000ms latency_alarm 500ms loss_alarm 20% dest_addr 8.8.4.4 bind_addr 198.51.0.16 identifier "DSLGW "Sometimes it is beneficial to change your monitoring address to something further out. In general, monitoring the ISP gateway is fine if it reliably responds to pings. Changes to the monitor IP address can be made in System > Routing and editing the appropriate gateway.
-
Hi. Thanks for the prompt reply.
After changing GW_WAN to the left axis the graph result looks very empty.
GW monitoring is enabled and it is pinging ISP gateway. System Log does not show missing dpinger entries.
Is there a way to debug more deeply why these packets are a loss?
Status->Queues there are no Drops occurred during the specific time period. (sometimes there are and I don't understand those either).
-
You need to monitor the gateway you are interested in. If that is WAN1GW then that's what it is.
Yes. Packet capture outside of WAN. If you see the echo request going out but no reply, then the ISP is dropping it. This will probably entail running for some amount of time. Wireshark makes it pretty easy to find missed replies since they are flagged for you.
-
I can see number of lost packets in Wireshark analysis. The ratio between lost and all packets is something like 30/150000. PF shows 0 packet loss during the capture period. This is an example of one sample of course.
So.. even if PF detects few lost packets and wireshark displays few dozen, I can't tell which one of those is actually detected by PF. And furthermore should I be worried about lost packets detected by PF anyway?
At least some of the lost packets detected by WS I was able to link to one workstation.
