After reviewing the ping payload size, and also your recommendations, I still have the same issue.
Let me know if any other suggestions come to mind. Thx.

Oct 7 15:31:19	dpinger		WAN2GW 8.8.4.4: duplicate echo reply received
Oct 7 15:31:19	dpinger		WAN2GW 8.8.4.4: duplicate echo reply received
Oct 7 15:29:46	dpinger		WAN2GW 8.8.4.4: Alarm latency 46725667us stddev 0us loss 95%
Oct 7 15:28:14	dpinger		WAN2GW 8.8.4.4: Alarm latency 15032us stddev 3426us loss 25%
Oct 7 15:26:44	dpinger		WAN2GW 8.8.4.4: Clear latency 15014us stddev 2740us loss 0%

@wm408:

Hi Derelict,

Typically for the Monitor IP, I choose the ISP gateway or one hop past (as observed with traceroute). But lately for at least testing, I've set the problematic gateway's Monitor IP to a google DNS server also as that's been a popular choice throughout the forums.

Thanks for your other tips. I will circle back and review each of your points after I look at the results with the topic I mentioned in an earlier post, re: ping payload size.

@Derelict:

Well, there you go. dpinger is doing its job.

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 that example you can see that I am monitoring a google DNS server there. 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.

Typically for the Monitor IP, I choose the ISP gateway or one hop past (as observed with traceroute). But lately for at least testing, I've set the problematic gateway's Monitor IP to a google DNS server also as that's been a popular choice throughout the forums.

Thanks for your other tips. I will circle back and review each of your points after I look at the results with the topic I mentioned in an earlier post, re: ping payload size.

@Derelict:

Well, there you go. dpinger is doing its job.

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 that example you can see that I am monitoring a google DNS server there. 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.

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 that example you can see that I am monitoring a google DNS server there. 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.

I am going to test "Set ping payload size" to the problematic gateway. cmb advised this for "…buggy upstream devices...", which I may be experiencing here. Refer to this post: https://forum.pfsense.org/index.php?topic=110043.0

This is a sample from my Gateways log:

Oct 1 10:45:23 dpinger WAN2GW 8.8.4.4: Clear latency 209224us stddev 412652us loss 0%
Oct 1 10:43:40 dpinger WAN2GW 8.8.4.4: Alarm latency 762289us stddev 1626523us loss 0%
Oct 1 10:29:15 dpinger WAN2GW 8.8.4.4: Clear latency 42259us stddev 123654us loss 0%
Oct 1 10:27:10 dpinger WAN2GW 8.8.4.4: Alarm latency 755434us stddev 2017180us loss 4%
Oct 1 10:14:02 dpinger WAN2GW 8.8.4.4: Clear latency 443760us stddev 978113us loss 0%
Oct 1 10:13:35 dpinger WAN2GW 8.8.4.4: Alarm latency 504314us stddev 971819us loss 0%

I didn't know Chris had moved on, till now. I saw his post. Makes sense! thanks for the heads up.

@heper:

CMB has gone to where the grass appears greener.

Check your gateway logs. That should provide more insights in the reason why the gateway goes down

Check your gateway logs. That should provide more insights in the reason why the gateway goes down

Jimp? or cmb?

Any thoughts from you guys?  8)