How to Read a Traceroute: Analyzing Hops, Latency, and Packet Loss

Traceroute (and its continuous real-time derivative, mtr) is the ubiquitous command-line tool for isolating routing failures and pinpointing where network latency originates between source and destination endpoints [1].

Despite its simplicity, traceroute is widely misinterpreted by junior system administrators and end-users [1, 2]. Misconceptions regarding intermediate packet loss, router control-plane rate limiting, and asymmetric internet routing regularly result in false accusations directed at upstream internet service providers [1, 2]. In this technical guide, we dissect the mechanics of traceroute outputs, explain how to read hop latencies, and outline the rules for identifying genuine network defects [1, 2, 3].

1. The Fundamental Golden Rule of Traceroute

Before analyzing any traceroute output, internalize this fundamental networking principle [1, 2]:

If packet loss or a latency spike does not persist across all subsequent hops to the final destination, the issue is not network packet loss or congestion.

Because IP packets traverse network hops sequentially, true physical congestion or link loss at Hop 4 will inevitably degrade Hop 5, Hop 6, and the final destination [1].

False Alarm Pattern (ICMP Rate Limiting):
Hop 1: 1 ms, 0% loss
Hop 2: 2 ms, 0% loss
Hop 3: 45 ms, 20% loss  <-- Router control plane drops ICMP probes!
Hop 4: 4 ms, 0% loss   <-- Subsequent hop is completely healthy!
Hop 5: 5 ms, 0% loss   <-- Proves Hop 3 forwards transit traffic flawlessly!

Why Intermediate Drops Happen (RFC 1812)

Under RFC 1812, core internet routers are engineered to switch transit packets across their high-speed hardware data planes at hundreds of gigabits per second [2]:

• Generating an ICMP Time Exceeded (Type 11) reply requires punting the packet from the hardware ASIC to the router's central CPU (the control plane) [1, 2].
• Router operating systems enforce strict rate-limiting on ICMP generation to protect the control-plane CPU from denial-of-service exhaustion [2].
• The router prioritizes forwarding transit packets at line rate, dropping deprioritized diagnostic probes.

2. Recognizing Genuine Network Problems

A genuine network problem displays a clear, cascading signature across the traceroute report [1]:

Genuine Network Congestion Pattern:
Hop 1: 1 ms, 0% loss
Hop 2: 2 ms, 0% loss
Hop 3: 145 ms, 15% loss <-- Problem originates here!
Hop 4: 148 ms, 15% loss <-- Congestion cascades forward!
Hop 5: 146 ms, 15% loss <-- Carried all the way to destination!

In this scenario, a physical link saturation, fiber degradation, or buffer queue overflow exists between Hop 2 and Hop 3, cascading packet loss and high latency through all subsequent hops [1].

3. Asymmetric Routing: The Return Path Reality

A frequent trap in traceroute analysis is assuming packets follow identical paths in both directions [1]:

• Internet routing is inherently asymmetric. The forward path from your office in Dhaka to a server in Frankfurt may traverse an upstream transit provider via Singapore, while the reverse path from Frankfurt back to your office traverses a direct terrestrial route through the Middle East [1].
• Traceroute measures only the round-trip time to each intermediate hop. If Hop 6 suddenly introduces 80 ms of latency, the delay may be occurring on the return path from Hop 6 back to you, rather than on the forward path [1, 2].

4. MPLS Label Stacks in Traceroute (RFC 4950)

Modern telecommunications carriers transport subscriber traffic across internal Multiprotocol Label Switching (MPLS) backbones [3]:

C:\> mtr -rw deprogit.com

HOST: workstation               Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- 192.168.1.1              0.0%    20    0.8   0.9   0.7   1.2   0.2
  2.|-- 10.200.0.1               0.0%    20    2.1   2.3   1.9   3.1   0.4
  3.|-- 103.14.x.x               0.0%    20    3.5   3.7   3.2   4.5   0.5
  4.|-- core1-dhaka.carrier.net  0.0%    20    4.1   4.3   3.8   5.2   0.4
        [MPLS: Lbl 24012 Exp 0 S 1 TTL 1]
  5.|-- edge1-transit.net        0.0%    20   14.2  14.5  13.9  16.1   0.6

Under RFC 4950, when an MPLS Label Switching Router (LSR) expires an IP packet's TTL, it appends the active MPLS label stack to the returned ICMP Time Exceeded payload [3]. This allows network engineers to observe provider label switching paths directly within traceroute outputs [3].

Traceroute Diagnostic Interpretation Cheat-Sheet

Practical Diagnostic Workflow

When conducting network path diagnostics:

1. Deploy MTR for Statistical Significance: Never draw conclusions from a single tracert execution. Run mtr (or WinMTR) for at least 100 consecutive cycles to gather meaningful statistical averages and loss percentages [1].
2. Reverse the Trace: Whenever possible, obtain a reverse traceroute from the remote server back to your client using carrier Looking Glass tools to account for asymmetric paths [1].
3. Verify Hostnames via Reverse DNS: Analyze intermediate hostnames (PTR records) to identify geographic transitions (e.g., fra for Frankfurt, sin for Singapore, dac for Dhaka) to distinguish physical propagation delay from true congestion [1].

For carrier peering coordination, enterprise routing optimization, and managed network architecture, explore our capabilities on our IT Infrastructure & System Integration page.

Key Takeaways

• Packet loss on a single intermediate hop is harmless ICMP rate-limiting if it does not persist to subsequent hops.
• True network problems cascade sustained packet loss and latency jumps through to the final destination.
• Internet routing is asymmetric; forward paths frequently differ from return paths, affecting round-trip latency.
• MTR provides statistical averaging over multiple cycles, eliminating false alarms caused by isolated transient spikes.

Need help with this? Contact us.

Sources

[1] IETF, "RFC 1393: Traceroute Using an IP Option", 1993. URL: https://www.rfc-editor.org/rfc/rfc1393.html (Standards-track foundational specification of the traceroute diagnostic protocol and hop discovery mechanics).

[2] IETF, "RFC 1812: Requirements for IP Version 4 Routers", 1995. URL: https://www.rfc-editor.org/rfc/rfc1812.html (Authoritative routing standard specifying ICMP rate limiting and control-plane packet handling).

[3] IETF, "RFC 4950: ICMP Extensions for Multiprotocol Label Switching", 2007. URL: https://www.rfc-editor.org/rfc/rfc4950.html (Standards-track RFC defining MPLS label stack inclusion in ICMP Time Exceeded diagnostic datagrams).

Last reviewed: October 2026