A packet-loss figure at one MTR hop is not enough to identify a faulty link. The router may be limiting the ICMP responses it receives while continuing to forward traffic. To distinguish that case from physical errors, saturated queues, or a rate limit, check whether the loss reaches the destination and compare it with the host's counters.
This tutorial follows a specific process: measure using different packet sizes, read the MTR pattern, take counters before and after the test, and, if needed, gradually increase the rate of a UDP stream. We will use addresses reserved for documentation: 198.51.100.10 as the remote destination and eth0 as the local interface. Replace them with values from your environment.
flowchart TD
A["Medir con ping y MTR"] --> B["Comprobar el destino"]
B --> C["Revisar contadores locales"]
C --> D["Clasificar errores o colas"]
D --> E["Probar una tasa UDP"]
E --> F["Aislar el tramo y registrar"]Prepare a repeatable measurement
On Linux, install MTR using your distribution's package manager. Alibaba Cloud documents apt for Ubuntu and Debian, and yum for CentOS and Alibaba Cloud Linux. The example uses Debian or Ubuntu; the following tests also require iproute2, which provides the ip command, and ethtool to query device statistics.
# Debian or Ubuntu: install MTR and ethtool
sudo apt install mtr ethtoolBefore running the tests, note the time, interface, and destination. A short sample can confuse a momentary fluctuation with a trend; the test below sends 200 probes at 0.2-second intervals. Repeat with large packets and compare IPv4 and IPv6 if the problem also occurs over IPv6.
# Measure loss and latency with small and large packets
ping -c 200 -i 0.2 198.51.100.10
ping -c 200 -i 0.2 -s 1400 198.51.100.10
# Save an MTR report with 200 probes
mtr -rwzc 200 198.51.100.10If only large packets fail, investigate MTU or fragmentation before attributing the issue to congestion. If loss occurs at certain times, the pattern is consistent with congestion; if it is constant, also look for a persistent fault. These are clues, not a definitive location.
Read MTR without blaming the first hop that fails
MTR combines continuous probes with hop tracing. The useful rule is to look at what happens after the hop that shows loss: if the destination has no loss, that intermediate figure may reflect ICMP rate limiting, not loss of forwarded traffic. If the same pattern continues all the way to the destination, there is more reason to investigate the data path.
A hop that does not respond—sometimes shown as ???—does not, by itself, prove that there is packet loss either. There may be no route information for that node, or the router may not respond to probes. When MTR shows loss at several hops, compare the percentages through to the end and do not focus on the first nonzero value. Alibaba Cloud describes, for example, a sample where one hop shows 41.2% and the next 0%: this discontinuity points to response limiting, not loss propagating along the route.
If possible, repeat the test with TCP as well as ICMP. Akamai's Edge Diagnostics documentation warns that ICMP probes may be subject to provider or firewall limits; it also notes that TCP may be less reliable in some of its tests. If one type fails, compare it with the other rather than treating a single result as a verdict.
Take counters before and after
A route showing symptoms does not rule out the host itself. Save a reading of the interface and kernel statistics, run the test, and read them again. What matters is the increase during the interval, not just the cumulative value since the system started.
# Check detailed interface and kernel statistics
ip -s -s link show dev eth0
ethtool -S eth0 | grep -Ei 'err|drop|miss|fifo|crc'
nstat -az | grep -Ei 'drop|retrans|overflow'Linux exposes standard interface statistics through ip; repeating -s also displays detailed fields. ethtool -S provides device and driver statistics. Specific names vary by device, so look for counter groups and compare their values without assuming that all drivers publish the same set.
An increase in CRC, frame, or alignment errors points the investigation toward the physical layer: cable, connector, optics, or duplex negotiation. RX dropped-packet or FIFO counters may indicate that the NIC or driver cannot keep up. TX or qdisc drops point to the output queue. Conversely, clean host counters shift suspicion to the path between endpoints, although they do not, by themselves, identify the exact segment.
Distinguish physical errors, congestion, and rate limits
Check the queueing discipline and its activity over the same period. If drops increase under load on an output interface, also check its utilization: this is a different signature from CRC errors, which appear in link error counters.
# Check eth0 output queue statistics
tc -s qdisc show dev eth0A queue pattern that drops packets as traffic rises is consistent with congestion or bursts that exceed the available buffer space. Physical errors, by contrast, increase in interface counters and can occur regardless of load. Before replacing hardware, record the values and repeat the test: the change between the two readings is the most useful evidence.
A policer or rate limiter usually produces a different pattern: throughput levels off near a ceiling and packet loss appears even though the link does not seem full. To look for that threshold, send UDP at a fixed rate and increase it in successive tests. The following example requires an iperf3 server accessible at the destination; start at 50 Mbit/s and run for 30 seconds.
# Send UDP at 50 Mbit/s for 30 seconds
iperf3 -c 198.51.100.10 -u -b 50M -t 30Repeat at higher rates, changing the value of -b with each run. Loss that begins abruptly around a specific rate is consistent with a limit or a bottleneck at that speed. It does not, by itself, distinguish between the two: compare the result with utilization and queue counters, and ask the provider to check the specific link if the data points beyond the host.
Isolate the segment and document the evidence
If the host is clean and loss reaches the destination, compare intermediate points you control. You can also capture traffic at both ends and compare packets and timestamps; a test in the reverse direction helps when forward-path latency or loss does not explain what the application observes. MTR shows the path from the test origin: it does not automatically make the hop with the most loss responsible.
When escalating the case to an operator, provide the time window, addresses, packet size, test rate, MTR result, and counters from before and after. Also record which endpoint ran the test. This information makes it possible to repeat the test after a change and narrows the discussion to a specific segment and symptom.
The practical sequence is to measure, check the destination, inspect the host, and classify the pattern before changing configuration. If an intermediate hop loses probes but the destination does not, do not assume the route is losing packets; if a queue or physical counter increases during the test, you already have a local clue that can be verified.
Sources: DEV Community, Linux Kernel Documentation, Alibaba Cloud Documentation, Edge Diagnostics
