Packet loss rarely announces itself. A video call freezes, a VPN session drops, or a file share just feels slow, and the complaint lands on the helpdesk. Over the years we have chased hundreds of these reports, and the cause is almost never the application itself. It usually sits in a damaged cable, a switch port, a full transmit queue, or a noisy radio channel. In this article we walk through how we approach how to troubleshoot packet loss on a network, always in the same order and never by guessing.
Where packet loss actually comes from
Packet loss simply means that a packet sent from one end never arrives at the other. Each packet is a small chunk of data, so losing a few of them seems harmless at first. Yet TCP notices every gap and retransmits, and those retransmissions stack up. The session then feels sluggish even though a basic ping looks healthy. That mismatch is exactly why users describe the problem as “the network is slow” when the link itself appears fine.
In the field we sort the causes into three families. The first is physical and link-layer faults, such as a failing cable or a duplex mismatch. The second is buffer and congestion drops, where a queue overflows during a traffic burst. The third is wireless interference or overload on the access side. Our working rule is to move outward from the nearest hop, and to take measurements before anyone touches a configuration file.
Confirm the loss with ping before anything else
Before changing anything, prove that the loss exists and size it properly. A single failed ping tells you very little. You need enough samples to produce a stable percentage, so run a longer test against your default gateway, for example ping -c 200 192.168.1.1.
Next, repeat the same test against an internal DNS server and then a public address. If the gateway is clean but the public address drops packets, the problem lives beyond your edge. If all three show loss, the fault sits closer to home. Look at the shape of the loss, not only its total. Loss spread evenly across the run often points to a physical or duplex issue, while loss that arrives in bursts suggests congestion or radio trouble. That distinction tells you which branch of troubleshooting to follow.
Trace the path with mtr
Once loss is confirmed, you need to find where it begins. mtr combines traceroute and ping, and it reports loss for every hop along the route. We usually run mtr -rwc 100 8.8.8.8 and read the Loss% column from top to bottom, because that column shows where the trouble starts.
A common trap is a middle hop that shows loss while the final destination shows none. In most cases that router is simply deprioritising ICMP replies, which is not the same as dropping forwarded traffic. The signal that matters is loss that begins at one hop and carries on all the way to the destination. That hop becomes your first suspect. If the loss appears only at the last hop, your attention should turn to the destination or its access link instead.
Read the counters on the suspect device
Counters record what the port itself has observed, and they are often more revealing than any tool output. On a Cisco IOS switch or router, run show interfaces GigabitEthernet0/1, followed by show interfaces GigabitEthernet0/1 counters errors. On Linux, ip -s link show eth0 and ethtool -S eth0 give the equivalent view.
Watch for CRC errors, input errors, runts, giants, and output drops. Ignore totals accumulated since boot, because they may cover months and hide what is happening right now. Take two readings a few minutes apart and compare the delta. A counter that keeps climbing while traffic flows is the one that matters. On one occasion a single port added thousands of CRC errors within an hour while its neighbours stayed at zero. That contrast pointed us straight at the fault, and it saved a long hunt through the rest of the switch.
Duplex mismatches and bad cabling
Layer 1 and Layer 2 faults are the most frequent culprits we meet, and they are cheap to fix once found. A duplex mismatch happens when one end runs full duplex and the other falls back to half duplex. The symptoms are CRC errors and late collisions. It usually traces back to auto-negotiation failing, often after someone hard-coded one side of the link and left the other side on auto.
The clean fix is to set speed and duplex explicitly on both ends, or to leave both on auto. Physical faults produce similar symptoms. A damaged cable, a badly crimped RJ-45 plug, or a run longer than the standard allows will all rack up errors. Replace the cable or re-terminate the plug, then measure again. A green link light proves almost nothing, since a port can come up and still pass corrupted frames.
The guide below is a starting point only, because exact behaviour varies with hardware and software version.
- CRC errors with late collisions: suspect a duplex mismatch and set both ends to the same speed and duplex.
- CRC errors without collisions: suspect a bad cable or connector, then replace it, re-terminate, and retest.
- Rising output drops: suspect a full queue and check utilisation over short intervals.
- Loss only at peak hours with high retries: suspect Wi-Fi interference or overload and check channel, RSSI, and client count.
When buffers become the bottleneck
Output drops mean the device had a packet ready to send, but its queue was already full. This often happens during microbursts, which are spikes lasting only milliseconds. A five-minute average hides them completely, so graphs can look calm while the drop counter keeps climbing.
To catch them, sample utilisation over much shorter intervals and compare it against the drop counter at the same moment. The remedy may be QoS tuning, a faster uplink, or spreading the load across more paths. Queue configuration depends heavily on platform and software release, so confirm the exact syntax in your vendor documentation before changing a production device.
Wi-Fi interference at the radio layer
Wireless loss looks different from a wired fault. It worsens during busy hours, retries climb steadily, and signal strength (RSSI) is weak at the edge of coverage. An access point serving dozens of clients will struggle even when its backhaul is perfectly healthy. Overlapping channels and nearby devices add noise that the client cannot always avoid, and that noise shows up as loss rather than as a clean error message.
Start with the channel plan. Move to a less crowded channel, reduce transmit power where access points sit close together, and verify the backhaul link as well. At several sites we have visited, moving one busy access point to a quieter channel cleared the complaints without changing anything else on the network.
A real case: loss confined to one floor
A familiar call came from a multi-storey office where a single floor felt slow while the rest of the building worked normally. Users there reported dropped video calls and sluggish file transfers, and nothing had changed on the application side. The floor was the only variable that differed.
We ran ping from that floor’s gateway, then mtr toward the main file server. Loss started at the floor’s uplink switch and continued to the server. The counters on that uplink port showed CRC errors climbing steadily, while the other uplinks stayed clean. A quick inspection of the patch cable revealed a cracked boot on the RJ-45 plug. After replacing the cable and measuring again, the loss dropped to zero. The lesson for our team was simple: the shortest route to the answer is usually the one that makes the fewest assumptions.
Mistakes we keep seeing in the field
Engineers often reach for configuration changes far too early. They tweak QoS or swap hardware before proving where the loss actually sits. That wastes time and can bury the real fault under unnecessary edits. Another frequent error is reading counters since boot instead of comparing deltas, which blurs a problem that is happening right now.
The biggest mistake is trusting the link light. Measure the counters rather than the LED, and let the numbers point you to the next step. A disciplined sequence of confirm, trace, read, and then change is almost always faster than a hurried guess.
Validate changes on a digital twin first
Before you change QoS or redesign a topology on a live network, test the change somewhere safe. A digital twin, which is a simulated copy of your network, shows the effect without risking an outage. We build a test plan around it before any production change, and it has stopped us from deploying several fixes that looked right on paper but failed under real load. For a wider view of that approach, read our piece on digital twins for network integration testing. For the uplink side of the picture, our notes on SD-WAN and fiber backbone resilience explain how redundant paths behave when loss appears on one of them.
Frequently asked questions
Is 1 percent packet loss a serious concern?
It depends on what crosses the link. Bulk file transfers tolerate 1 percent loss with little visible effect. Voice, video, and real-time control traffic will show noticeable stutter at the same level. Measure over a long sample and check whether the loss is steady or bursty, since bursts usually hurt far more than the average suggests.
Ping shows no loss, but applications are still slow. Why?
Ping sends small ICMP packets, which can behave differently from the TCP or UDP traffic your applications generate. The problem may depend on packet size, on congestion that appears only under load, or on latency rather than outright drops. Test with larger packets, capture counters during real use, and review application-level metrics as well.
Should I disable auto-negotiation to avoid duplex errors?
Not as a blanket rule. Hard-coding speed and duplex on both ends works well and avoids negotiation failures. The danger is setting one side manually while the other stays on auto, which creates the very mismatch you wanted to prevent. Whichever approach you choose, make sure both ends match.
How do I tell whether the fault is in the switch or the cable?
Swap the cable first, since it is the cheapest test. If the counters keep climbing on the same port with a new cable, move the connection to another port or another switch, then inspect the original switch. Compare error patterns on neighbouring ports to see whether the problem is isolated or spread across the device.
Should I capture packets right away?
Not at the start. Counters, ping, and mtr usually narrow the fault to one hop or one port far faster than a capture would. Packet capture earns its place once you know which device or segment to watch, because it reveals the actual frames, retransmissions, and timing. Capture after you have a suspect, not before.