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

    How to respond when an ISP says "it's your equipment"

    Scheduled Pinned Locked Moved General pfSense Questions
    8 Posts 4 Posters 1.1k Views
    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.
    • B
      barnettd
      last edited by

      I have a pfsense box setup (netgate sg-2440) with dual wan connections. One connection drops a small amount of packets randomly (.8%avg and 25% max over 10 days). The other connection has a 0% loss rate over the same period. This data is gathered from an outside source pinging the wan interfaces.

      The ISP is blaming our equipment, but I think that's probably not the case since the other connection on the same box doesn't have the same issues. Any advice on what to tell them?

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

        What do the quality graphs show for that WAN?

        I like 8 hour duration 1 minute resolution for this.

        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
        • B
          barnettd
          last edited by

          To be honest the connection is mostly solid and I don't think its worth much of a fight, just kind of miffed that they suggested the issue was on our side and wanted to come back with something they can't deny.

          Its just those occasional drops can cause some timeouts for remote desktop sessions. I use smokeping, one of the default graphs is for 30 hours which looks decent.

          I do kind find it kind of funny the circuit with the 0% loss is a "legacy" T1 connection, and the lossy one is a new fiber circuit.

          30hours.PNG
          30hours.PNG_thumb

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

            Well it is really hard to blame the ISP for loss of incoming pings. You have no idea if they even received the ICMP packet to send to you. The loss could be upstream of them. You would think they would have evidence of that before blaming your gear but that would require some work - probably at other than level 1 support (such as a packet capture when the loss was happening).

            The routes between the ping source and the different WANs are likely substantially different.

            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
            • B
              barnettd
              last edited by

              Thanks good point. I'll set something up internally to ping something within the ISP network.

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

                dpinger is probably already doing this for you and you have graphs of the results.

                See the aforementioned quality graphs for that WAN.

                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
                • H
                  Harvy66
                  last edited by

                  MTR is a nice package if the issue is a hop going out.

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

                    I deal with this pain on a daily bases as a network engineer. It's really annoying when the ISP doesn't really do any testing other then using their built in software to perform a 5 second test…

                    How important is this connection? Are you doing duel WAN for balancing load or for failover?

                    What I would do is disconnect that connection that is dropping packets. Connect it to a laptop and configure your laptops NIC to the static IP settings. Then perform a continuous ping or use a network monitoring tool to capture packet loses.

                    If you lose packets then, it is for sure the ISP. If you do not, it is for sure your device.

                    This is the only sure fire way to rule out ISP equipment from your own.

                    It's a pain but it is pure proof that they can not disagree with.

                    1 Reply Last reply Reply Quote 0
                    • First post
                      Last post
                    Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.