Diagnosing packet loss without blaming the wrong hop

A failed ping and a stalled download are observations from different layers. They may share a cause, but neither observation identifies that cause by itself. Useful diagnosis starts with an explicit question: which traffic fails, between which endpoints, in which direction, and during which interval? This article develops a bounded investigation that preserves those distinctions instead of treating every missing reply as proof of a broken router.

Define the measurement before collecting it

Packet loss needs a denominator and a deadline. Sending 100 probes and receiving 98 replies describes a sample; it does not establish a permanent two percent loss rate for every application. Very late packets also require a consistent treatment. The IETF's one-way loss metric in RFC 7680 specifies the importance of packet type, measurement times, and the waiting threshold used to declare loss.

Record the source interface, destination, protocol, packet size, count, and timestamps. Keep a small incident note beside the raw output. Include whether a VPN or transparent tunnel was active, and whether another destination remained reachable. This makes later comparisons useful: an evening TCP download and a morning ICMP sample are not interchangeable controls.

Establish endpoint behavior with modest probes

On a Linux host, a short initial sample can be collected with:

ping -n -c 30 -i 0.5 example.com
ip route get 192.0.2.10
ip -s link show dev eth0

Replace the documentation address and interface with the actual test destination and interface. The first command avoids reverse DNS lookups in the displayed addresses and limits the number of probes. The routing lookup and interface counters provide local context without changing configuration. Consult the installed manual for distribution differences; the iputils ping documentation explains its options and the reported round-trip summary.

Capture interface counters again after the sample. A cumulative drop counter may include events from days earlier. The interval delta is the evidence relevant to this investigation. Even a new receive drop identifies a local observation, not automatically a defective cable: driver behavior, receive queues, and host scheduling remain possible explanations.

Read intermediate hops conservatively

A route trace asks routers to produce diagnostic replies. Routers can forward ordinary traffic while filtering or limiting those replies. Therefore, a silent middle hop followed by responding later hops does not establish forwarding loss at the silent hop. A percentage in a route report becomes more interesting when comparable loss persists toward the destination and the endpoint test also deteriorates.

Treat that pattern as a lead, not a verdict. Paths may change between probes, replies can return along different routes, and multiple paths can be combined into one display. Preserve the complete trace rather than copying only the most alarming row. If a firewall blocks all destination probes, explicitly label endpoint loss as unknown for that probe method.

Connect the symptoms to a real TCP flow

Inspect a controlled connection while it is carrying data:

ss -tin dst 192.0.2.10

The iproute2 ss manual documents TCP internal information, including timing and congestion-related fields where the kernel exposes them. Keep the selected connection's source and destination ports so a later sample can be matched to the same flow. A host-wide TCP counter includes unrelated SSH sessions and web traffic; it cannot be assigned entirely to the download under investigation.

Retransmission counts are useful evidence of TCP recovery, but they are not a direct percentage of packets lost on a particular link. Reordering, delayed acknowledgments, and timeout behavior complicate interpretation. Correlate a rise in retransmissions with the receiving application's throughput and latency, rather than ranking routes by a retransmission total alone.

Change one variable at a time

Build a comparison that answers a specific question. Keep the same destination and application while changing the local access network, or keep the access network fixed while testing a second destination. Repeat both transfer directions when possible. Upload and download can behave differently because the sender, route, queue, and available capacity differ.

Use bounded tests during an agreed interval. A throughput test can itself fill a queue and increase latency for everyone sharing the link. Do not run an unlimited packet flood, disable a firewall, or alter congestion settings merely to make an initial result look better. Those changes remove the baseline needed to understand the fault.

Preserve conclusions at the right confidence level

A strong incident record separates facts from hypotheses. “Three endpoint replies were missing during this sample” is a fact. “The upstream provider dropped application traffic” is a hypothesis requiring additional evidence. Write down the test interval, counter deltas, selected routes, application symptoms, and which explanations the comparisons support.

Also record what remains unresolved. An inaccessible destination, a short sample, or a changing route can prevent precise localization. That limitation is useful information for the next investigation. A repeatable method and intact evidence usually produce a better repair decision than a confident accusation based on one red row in a diagnostic table.