dpinger high loss values ?



  • Hello,

    This seems to be related to https://forum.netgate.com/topic/94852/help-troubleshooting-random-crazy-high-pings

    I never looked at gateway logs and don't have any visible issues, but wonder about these entries in the gateway log:

    Mar 13 00:47:25	dpinger		WAN_DHCP 8.8.8.8: Clear latency 3127us stddev 666us loss 6%
    Mar 13 00:43:26	dpinger		WAN_DHCP 8.8.8.8: Alarm latency 3241us stddev 104us loss 21%
    Mar 13 00:25:57	dpinger		WAN_DHCP 8.8.8.8: Clear latency 3105us stddev 129us loss 5%
    Mar 13 00:24:45	dpinger		WAN_DHCP 8.8.8.8: Alarm latency 3276us stddev 195us loss 22%
    Feb 27 01:59:01	dpinger		WAN_DHCP 8.8.8.8: Clear latency 17716us stddev 11764us loss 15%
    Feb 27 01:56:56	dpinger		WAN_DHCP 8.8.8.8: Alarm latency 27141us stddev 656us loss 21%
    Feb 27 01:56:32	dpinger		WAN_DHCP 8.8.8.8: Clear latency 27071us stddev 566us loss 20%
    Feb 27 01:55:16	dpinger		WAN_DHCP 8.8.8.8: Alarm latency 108954us stddev 40575us loss 21%
    

    Is it good, bad, what to do about those ?

    I am on 1GB fiber up-link

    Thx


  • Galactic Empire

    BAD, it could be your ISP dropping ICMP packets when their network is busy.

    mac-pro:~ andy$ ping 8.8.8.8
    PING 8.8.8.8 (8.8.8.8): 56 data bytes
    64 bytes from 8.8.8.8: icmp_seq=0 ttl=122 time=10.242 ms
    64 bytes from 8.8.8.8: icmp_seq=1 ttl=122 time=9.932 ms
    64 bytes from 8.8.8.8: icmp_seq=2 ttl=122 time=10.184 ms
    64 bytes from 8.8.8.8: icmp_seq=3 ttl=122 time=9.895 ms
    64 bytes from 8.8.8.8: icmp_seq=4 ttl=122 time=10.160 ms
    64 bytes from 8.8.8.8: icmp_seq=5 ttl=122 time=10.231 ms
    64 bytes from 8.8.8.8: icmp_seq=6 ttl=122 time=10.154 ms
    ^C
    --- 8.8.8.8 ping statistics ---
    7 packets transmitted, 7 packets received, 0.0% packet loss
    round-trip min/avg/max/stddev = 9.895/10.114/10.242/0.131 ms
    mac-pro:~ andy$

    What do you get when you ping something a bit nearer your ISP.



  • @nogbadthebad said in dpinger high loss values ?:

    ping 8.8.8.8

    I see no losses running on the router:

    ping 8.8.8.8
    PING 8.8.8.8 (8.8.8.8): 56 data bytes
    64 bytes from 8.8.8.8: icmp_seq=0 ttl=118 time=3.504 ms
    64 bytes from 8.8.8.8: icmp_seq=1 ttl=118 time=3.607 ms
    64 bytes from 8.8.8.8: icmp_seq=2 ttl=118 time=3.448 ms
    64 bytes from 8.8.8.8: icmp_seq=3 ttl=118 time=3.469 ms
    64 bytes from 8.8.8.8: icmp_seq=4 ttl=118 time=3.478 ms
    64 bytes from 8.8.8.8: icmp_seq=5 ttl=118 time=3.320 ms
    64 bytes from 8.8.8.8: icmp_seq=6 ttl=118 time=3.340 ms
    64 bytes from 8.8.8.8: icmp_seq=7 ttl=118 time=3.462 ms
    64 bytes from 8.8.8.8: icmp_seq=8 ttl=118 time=3.436 ms
    64 bytes from 8.8.8.8: icmp_seq=9 ttl=118 time=3.197 ms
    64 bytes from 8.8.8.8: icmp_seq=10 ttl=118 time=3.314 ms
    ^C
    --- 8.8.8.8 ping statistics ---
    11 packets transmitted, 11 packets received, 0.0% packet loss
    round-trip min/avg/max/stddev = 3.197/3.416/3.607/0.108 ms
    


  • Does not seem like I am seeing losses all the time, maybe just some ISP issues but not ongoing ?



  • Seems like an ISP that sells 'n' times a "1GB fiber up-link" but they haven't a n x "1GB fiber up-link" from their neighbourhood router upstream, to the net. Thy're overselling (they all do).
    Result : upstream gets full (everybody wants it's "1GB fiber up-link", espically at 08h00 PM, low priority protocols get dropped like ICMP.

    Drop in here to test more http://www.dslreports.com/speedtest

    edit : if needed, optimize your connection.
    0_1552665908581_e822171a-8116-4e03-a4df-36bbe03a9d0e-image.png





  • @chudak said in dpinger high loss values ?:

    @gertjan

    http://www.dslreports.com/speedtest/47343618

    Good !
    Right now, your ISP is actually quiet good.



  • I'm experiencing similar issues. It is even worse ... from time to time the interface is not even recovering. See my description below posted to support:

    In two locations I have installed the SG3100. In one locations, there is a gateway group with two WAN connections. The other location has only one WAN connection.

    On these two devices I discovered some strange behaviour with the gateway monitor which is pointing to Google DNS servers (8.8.8.8) or Quad9 (9.9.9.9). These are both multicast IP's.

    Case A/ 2 WAN connections with primary and failover WAN

    At a given moment the primary WAN failed due to a package loss towards 8.8.8.8. The secondary takes over as planned and no network interruption seen, but at no moment (in a period of several weeks) the primary became online again (although of course the 8.8.8.8 was perfectly pingable from any device in the network). The only way I could re-enable the interface was going into the configuration and force it online. (See 2 attach starting with 2WAN_ => you see gateway with 100% loss, traffic dropping to 0 and other interface taking over.)

    Case B/ 1 WAN Connection

    At a given moment the gateway monitoring indicated major packet loss and the gateway was "offline". However, I didn't notice this one while working on the network, so even if it was "offline" it kept working, which I found strange. Again I tested the ping from a device on the network which worked perfectly. I did the ping test using diagnosis tab in PfSense GUI, and to my surprise it indicated 100% packet loss ... other pings worked well. Also here, I had to go to the config to force the interface online. This resolved the ping issue as well using the diagnosis ping option. However, as stated, even with the gateway "offline" I could still work.
    (Attach: 1WAN_GatewayDown_Keptworking => You see the gateway goes down but there is still traffic). But key thing here as well ... why didn't the ping recover ?!

    Case A/

    • Primary interface goes down due to 100% package loss for ping
      2WAN_Primary_down.jpg

    • Secondary takes over for several weeks (till manual intervention)
      2WAN_Secondary_TakeOver.jpg

    Case B/
    1WAN_GatewayDown_KeptWorking.jpg


Log in to reply