Packet Loss Reported: Systematically Narrowing Down the Causes

Question the Measurement First, Then the Network

Before investigating any potential cause, the figure itself needs to be scrutinised. 20 percent loss --> measured how, from where to where, over what period, with what packet size? A ping from a laptop on Wi-Fi to a router interface measures something entirely different from a TWAMP test (network test device) between two wired measurement points. Many routers and firewalls deprioritise ICMP responses to their own control plane (control-plane policing); a ping to a device can therefore show losses that don't actually exist in the data path through that device. Equally important: is the loss constant, bursty, or load-dependent? A constant 20 percent points towards a deterministic problem (physical layer, duplex, policer), bursty loss towards congestion, and load-dependent loss towards oversubscription or queue drops.

Only once the measurement method and the loss pattern have been clarified is it worth pursuing the actual root-cause analysis. The time of day is also worth noting. Is it recurring? Could a backup job be the cause?

The Hypothesis Space: Eleven Candidates, Ordered by Layer

A single suspicion is almost never enough in troubleshooting. The analysis becomes robust once the plausible causes are laid out side by side, with a clear understanding for each of which evidence confirms or rules it out.

Physical Layer

Defective or excessively long cables, contaminated fibre-optic connectors, failing optics, attenuation outside specification. The tell-tale signs are CRC and input errors on the interface and, for fibre, conspicuous RX/TX levels in the transceivers' DDM/DOM diagnostics. Physical-layer problems are load-independent: the loss persists even at three in the morning.

Interface Errors and Duplex Mismatch

Closely related but distinct: a duplex mismatch, usually caused by a port hard-configured on only one side. The pattern is characteristic: the half-duplex side registers late collisions, the full-duplex side registers CRC errors, and the loss increases with load. With low traffic volumes, such a link can go unnoticed for years.

Congestion and Queue Drops

The classic case: an interface is temporarily saturated, the buffer overflows, and the switch discards packets. Visible as output drops or tail drops in the interface and QoS statistics – without accompanying CRC errors. It's worth examining the individual queues: if only one class is dropping, it's not a capacity issue but a QoS configuration problem, such as an overly tight policer or shaper. Microbursts are the classic trap here: 30 percent utilisation averaged over five minutes does not rule out drops occurring at the millisecond level.

Wi-Fi

If a wireless segment is part of the path, it's the prime suspect. Interference, poor SNR, sticky clients, co-channel congestion. At Layer 2, many losses are masked by retransmissions, but jitter and residual loss remain visible further up the stack. The differentiation is trivial yet often skipped: repeat the same measurement over a cable. If the loss disappears, the issue is confined to the wireless cell.

WAN Provider

Loss on the provider link becomes apparent once the measurement is segmented: clean up to one's own CE router, loss beyond that point. Reference measurements from a second site and the provider's own SLA reports are helpful here. Exercise caution with MPLS and SD-WAN links: traceroute results can be misleading due to hidden hops and ECMP load balancing; paced-probe methods such as mtr run for a sufficient duration are more informative than three quick pings.

Routing and Instability

Flapping adjacencies, route churn, or load balancing across one healthy and one faulty path typically produce periodic or partial loss. Examining routing logs (neighbour resets, SPF runs) and comparing multiple flows with different ports that fall onto different paths via ECMP hashing separates this hypothesis from the others: if only every second flow loses packets, one of two paths is faulty.

Firewall and Session Handling

Firewalls deliberately drop packets due to full session tables, triggered DoS thresholds, asymmetrically arriving packets with no matching state, or misclassification by application recognition. The tell-tale sign: the loss affects specific protocols, ports, or connection phases rather than traffic uniformly. The firewall's drop counters and session logs provide answers faster than any measurement taken externally.

MTU and Fragmentation

Strictly speaking, not statistical loss, but it looks like it: large packets fail to arrive while small ones get through. Classic triggers are paths with a reduced MTU where the ICMP "Fragmentation Needed" message is filtered – causing Path MTU Discovery to fail silently. The test is unambiguous: ping with the DF bit set and increasing packet size. If reachability breaks off at a fixed size, it's not packet loss but an MTU problem.

Tunnels and Overlays

IPsec, GRE, VXLAN and SD-WAN overlays combine several sources of error at once: header overhead exacerbates MTU problems, rekeying events cause brief outages, and loss on the underlay path propagates fully into the tunnel. The key is to measure underlay and overlay separately: if the underlay is already losing packets, the tunnel is merely the messenger.

Asymmetric Routing

The forward and return paths take different routes: loss can occur on either one, and stateful devices along the path additionally discard traffic they only partially observe. One-way loss measurements (rather than round-trip) or synchronised captures at both ends reveal which direction is actually losing packets. A round-trip ping is fundamentally incapable of distinguishing this.

Oversubscription

Structural overbooking: too many access ports on too little uplink, undersized firewall clusters, virtual switches on heavily loaded hosts. Unlike short-term congestion, this is an architectural issue: the loss correlates reproducibly with production or backup windows and does not disappear after a restart. Diagnosis relies on high-resolution utilisation history, and the remedy lies in capacity or architecture, not configuration.

The Measurement Logic: Halving Rather Than Guessing

The art lies not in listing hypotheses but in efficiently ruling them out. A binary search along the path has proven effective: place a measurement point at the midpoint of the route, determine in which half the loss occurs, then halve again within that segment. In parallel, three questions each roughly halve the hypothesis space:

• Load-dependent or constant? Constant points to physical layer, duplex, or policer issues. Load-dependent points to congestion, oversubscription, or Wi-Fi.
• All packets or only certain ones? Size-dependent means MTU; protocol- or port-dependent means firewall or policy. Flow-dependent means ECMP with a faulty sub-path.
• One direction or both? One-sided loss suggests asymmetry or a directional fault. Only a direction-separated measurement can clarify this.

With these three answers, the eleven candidates are usually narrowed down to two or three, each of which can then be verified with a targeted individual test.

Which Measurement Comes Next?

The honest answer is: the interface counters along the path, before any active test is run. CRC errors, input/output drops, queue statistics and optical levels on every hop take five minutes to check and already distinguish between physical-layer issues, congestion and "the problem lies elsewhere". Clear the counters first or note the deltas; absolute counter values since the last reboot are worthless.

Only after that comes the active measurement, carried out in segments: continuous probes (such as mtr or a sustained ping run with timestamps) from both ends to intermediate points, complemented by a DF-bit sweep to check MTU. If that's not sufficient, time-synchronised captures at two points come next. Comparing sequence numbers shows precisely between which two devices the packets are disappearing. This is labour-intensive but conclusive, and it ends any discussion with a provider or manufacturer support team.

The OT Perspective

In production networks, the priorities shift. First, active measurements must be used with caution: a ping sweep or load test in the wrong cell network can disrupt older controllers. Passive methods such as counters, SPAN ports and TAPs take priority. Second, the symptoms differ: 20 percent loss here does not manifest as "the video call is stuttering" but as sporadic PLC connection drops, timeouts in process visualisation, or fault alarms with no discernible pattern. Third, physical causes are considerably more likely than in an office environment: vibration at connectors, EMI interference near frequency converters, temperature inside the control cabinet, unmanaged switches with no diagnostic capability whatsoever in the field.

This last point in particular is an argument for clean network architecture: those who properly segment their cells and provide measurement points at the transitions can narrow down, within minutes, which cell the problem lies in during a fault, rather than searching through a flat broadcast domain with hundreds of participants.

Conclusion

20 percent packet loss does not have a single cause but a space of possible causes. Anyone who first validates the measurement, organises the hypotheses by layer, and halves the space using three differentiating questions will find the cause in a fraction of the time and won't replace hardware on suspicion. The most valuable "next measurement" is almost always the least spectacular one: the interface counters along the path, read cleanly as a delta. Everything else follows from what they reveal.