Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    Packet drops

    Off-Topic & Non-Support Discussion
    2
    5
    759
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • A
      axsense2
      last edited by

      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.
      0_1530546622086_pfsense.PNG

      1 Reply Last reply Reply Quote 0
      • DerelictD
        Derelict LAYER 8 Netgate
        last edited by

        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.

        Chattanooga, Tennessee, USA
        A comprehensive network diagram is worth 10,000 words and 15 conference calls.
        DO NOT set a source address/port in a port forward or firewall rule unless you KNOW you need it!
        Do Not Chat For Help! NO_WAN_EGRESS(TM)

        1 Reply Last reply Reply Quote 0
        • A
          axsense2
          last edited by

          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?

          0_1530601431921_pfsense2.PNG

          Status->Queues there are no Drops occurred during the specific time period. (sometimes there are and I don't understand those either).

          1 Reply Last reply Reply Quote 0
          • DerelictD
            Derelict LAYER 8 Netgate
            last edited by

            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.

            Chattanooga, Tennessee, USA
            A comprehensive network diagram is worth 10,000 words and 15 conference calls.
            DO NOT set a source address/port in a port forward or firewall rule unless you KNOW you need it!
            Do Not Chat For Help! NO_WAN_EGRESS(TM)

            1 Reply Last reply Reply Quote 0
            • A
              axsense2
              last edited by

              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.

              1 Reply Last reply Reply Quote 0
              • First post
                Last post