Packet loss troubleshooting starts by finding where loss first appears
Packet loss is not a diagnosis. Frames and packets can disappear because of physical corruption, wireless retries that eventually fail, congested queues, overloaded devices, policy drops, route problems, MTU behavior, or problems outside your network. The fastest path to a defensible answer is to measure from near to far and preserve each healthy checkpoint.
Record percentage, timing, scope, and workload before changing anything
“The network drops packets” is too vague to troubleshoot. Record whether loss is constant or bursty, whether it affects one client or many, whether it occurs at idle or only under load, and whether the local gateway is affected.
Constant loss
May point toward media, policy, or persistent path problems.
Bursty loss
Often aligns with interference, microbursts, route changes, or overloaded devices.
Load-dependent loss
Strongly raises congestion and queue pressure.
Loss to the default gateway localizes the problem before the WAN
If a client loses packets to a gateway one switch or AP away, the failure is already local. That immediately raises switch-port counters, cable/optic health, VLAN placement, NIC state, AP retries, channel utilization, and local congestion above ISP troubleshooting.
A clean local hop lets you move the investigation outward
If gateway loss is 0% over a representative sample but remote destinations show persistent loss, inspect the edge/WAN path, provider circuit, routing path, firewall/policer behavior, and remote side.
CRC and FCS errors are different evidence from queue drops
CRC/FCS errors indicate corrupted frames. On copper, cabling and negotiation issues can contribute. On fiber, optics, connectors, or signal quality can matter. In wireless networks, RF delivery problems show up through retry and error behavior rather than Ethernet CRC in the same way.
Lifetime totals are weak until you know whether they are still increasing
An interface with 90,000 historical errors may be stable now. An interface adding 500 errors each minute during the complaint window is active evidence. Always compare counters over time and align them with the user-visible event.
Queue drops rise when offered traffic exceeds forwarding capacity
If packet loss appears only as a shared link approaches saturation, inspect output drops, queue depth, latency, and the traffic source. This pattern supports congestion far more than replacing a cable with clean physical counters.
Short queue overflows can cause loss even when average utilization looks safe
Monitoring sampled every few minutes can show 50% average utilization while millisecond-scale bursts briefly exceed interface capacity and overflow buffers. If users report intermittent loss but long-window utilization looks moderate, check queue-drop counters and higher-resolution telemetry if available.
802.11 can retransmit damaged frames before IP-level tools ever report loss
High wireless retry rates show that the RF layer is struggling even if ping still reports 0% loss. Once retransmissions are exhausted—or airtime becomes too congested—IP-level loss becomes visible.
Coverage and capacity are different wireless problems
A client can have excellent RSSI while competing with dozens of devices for airtime. Hidden nodes, overlapping cells, neighboring networks, wide channels, and high utilization can all increase retries and loss without weak signal.
Intermediate-hop ICMP loss does not automatically mean transit packet loss
Routers may rate-limit or deprioritize responses generated to themselves. If hop 5 answers only half the probes but hops 6 through 10 and the destination show no loss, hop 5 is still forwarding transit traffic well enough for later hops to reply.
Loss becomes more meaningful when it begins and continues through later hops
If loss begins at one segment and persists at similar or increasing levels through later hops and the destination, that pattern is stronger evidence of a forwarding-path problem. Compare repeated tests because Internet path behavior can change over time.
TCP turns loss into retransmissions, throughput reduction, and added delay
TCP interprets missing acknowledgments and lost data as a reliability/congestion signal. Retransmissions recover lost data, but throughput may fall and application completion time can increase dramatically. A small percentage of loss can have a large effect on long-distance or high-throughput TCP flows.
Real-time UDP applications often expose missing packets directly
Voice, video, and interactive applications may not retransmit every missing packet because late data can be useless. The result can be audio gaps, pixelation, freezes, or quality degradation instead of the slower-but-complete behavior seen with TCP recovery.
Not every drop is accidental
Firewalls, ACLs, policers, rate limits, security systems, and QoS policies may intentionally drop selected traffic. If loss affects one protocol, source, destination, or traffic class while other traffic remains clean, inspect policy counters and logs before assuming the medium is damaged.
Small probes can work while larger application traffic fails
If small pings succeed but larger packets fail or fragment unexpectedly, inspect MTU and path-MTU behavior. VPNs and tunnels add overhead and can reduce effective packet size.
This is one reason “ping works” is not enough to prove every application flow will succeed.
Forward and return paths can fail differently
Internet paths are often asymmetric. A client-to-server path can be clean while the return path contains congestion or filtering. Server-side measurements, bidirectional testing, or packet capture from both ends can help when one-sided tools cannot explain the round trip.
Loss begins at the gateway on Wi-Fi only
Wireless clients show 7% gateway loss while a wired laptop on the same network is clean.
Inference: investigate retries, channel utilization, interference, AP load, and client behavior before escalating to the ISP.
CRC errors rise at idle
The interface shows low utilization, but CRC/FCS errors increase rapidly and packet loss continues even when traffic is light.
Inference: media/interface integrity is stronger than congestion. Inspect cable, optic, connector, negotiation, or interface hardware.
Loss appears only during WAN saturation
Local gateway loss remains 0%, WAN utilization hits 99%, queue drops rise, and remote loss disappears when the heavy upload stops.
Inference: congestion/queueing on the shared WAN path is strongly supported.
Traceroute hop looks bad but destination is clean
One intermediate router responds to only 20% of probes, but later hops and the destination show 0% loss.
Inference: the router is likely rate-limiting probe responses rather than dropping transit traffic.
Voice breaks up but bulk file transfer mostly completes
UDP voice shows gaps while TCP transfers slow and retransmit but eventually finish.
Inference: both applications may experience the same loss differently because their transport and recovery behavior differ.
Use the artifact that matches the mechanism
| Observed evidence | Stronger mechanism | Weak conclusion |
|---|---|---|
| Rising CRC/FCS errors | Media/interface integrity | ISP congestion |
| Queue drops + saturation | Congestion | Bad cable automatically |
| High Wi-Fi retries | RF contention/interference | DNS problem |
| Loss only at one traceroute hop | Probe rate-limiting possible | Transit loss proven |
| Loss begins beyond clean gateway | Upstream path | Local NIC definitely bad |
Swipe horizontally to see the packet-loss evidence matrix.
Let the location and timing of loss choose the next branch
One successful ping after a change is not enough
Retest the same path for long enough to reproduce the original conditions. If the fault occurred only during peak traffic, test during peak traffic or under a controlled equivalent load. Check that error and drop counters stop increasing and that application behavior improves.
Path: repeat gateway and remote loss measurements.
Counters: confirm relevant CRC/drop/retry counters remain stable.
Load: recreate the workload that originally triggered loss.
Application: verify voice, web, file transfer, or other affected service.
Different applications tolerate very different levels and patterns of loss
Packet loss should be interpreted in context. A large TCP file transfer may recover from occasional loss through retransmission, but completion time can stretch. Real-time voice and video may expose the same loss immediately as clipped audio or frozen frames. Short bursts can be especially disruptive even when the long-term average percentage looks small.
A useful troubleshooting note therefore records not only the overall loss percentage but also burst length, spacing, affected application, and whether retransmissions or application recovery were visible.
Loss pattern can narrow the likely mechanism
Random isolated loss can appear differently from clustered bursts. Bursts that line up with backup jobs, wireless roaming, route changes, or interface flaps suggest a timed or state-change trigger. More evenly distributed loss may fit persistent media degradation or sustained congestion.
Discards, errors, flaps, and speed/duplex state help separate mechanisms
Interface counters are most useful when read together. CRC/FCS errors support corruption. Output drops support queue pressure. Link transitions support an unstable physical connection. A speed/duplex mismatch or repeated renegotiation can produce intermittent symptoms even when the interface remains technically up.
| Counter/state | Useful interpretation |
|---|---|
| CRC/FCS increasing | Frame corruption / media integrity |
| Output drops increasing | Egress queue pressure |
| Link up/down events | Physical instability or negotiation |
| Errors stable, drops zero | Look elsewhere in path/policy |
Swipe horizontally to see the switch-counter table.
When simpler evidence stalls, compare what each endpoint actually sees
If the client sends traffic and the server never sees it, the loss is somewhere before the server capture point. If the server sees the request and transmits the reply but the client never receives it, the return path becomes the stronger branch. Packet capture is especially valuable when forward and reverse paths differ.
Intentional drops can look exactly like congestion unless you inspect policy
A policer can drop traffic that exceeds a configured rate even when the physical link has unused bandwidth. Security devices can also rate-limit ICMP or selected application traffic. If loss consistently begins at the same traffic rate or affects one traffic class, inspect policer and firewall counters before expanding capacity.
Find the workload that causes loss, not just the interface where it appears
Once congestion is established, identify the traffic source. Backups, imaging, cloud synchronization, large software deployments, or unexpected flows can consume shared capacity. Fixing the root cause may mean scheduling or shaping the workload rather than simply increasing bandwidth.
Use several targets to distinguish one remote service from a shared path problem
If packet loss appears to one server only while multiple other remote targets remain clean, the problem may be near that destination or specific to its route. If several unrelated destinations lose packets at the same time after the local gateway, the shared upstream path becomes stronger.
Choose targets that exercise different paths and avoid relying on one public host that may rate-limit probes.
Change one condition at a time so the result creates new evidence
Move the same client from Wi-Fi to Ethernet without changing the destination. Replace one suspect cable without changing switch configuration. Pause the one heavy workload while keeping the same path. This isolates the variable responsible for the behavior.
24 Packet Loss Troubleshooting digital flashcards
Practice gateway baselines, CRC/FCS errors, congestion, queue drops, Wi-Fi retries, traceroute interpretation, TCP/UDP impact, MTU behavior, directional loss, and verification.