Operations 16 min read

Why Traceroute Can’t Solve All Network Issues—and What It Really Reveals

This article explains what Traceroute is, its limitations, the underlying packet‑TTL mechanism, how DNS reverse‑lookup enriches hop information, and how to interpret serial, queue and propagation delays to diagnose network performance problems more accurately.

MaGe Linux Operations
MaGe Linux Operations
MaGe Linux Operations
Why Traceroute Can’t Solve All Network Issues—and What It Really Reveals

1.1 What is Traceroute

Traceroute is a network tool that displays the IP addresses of routers a packet traverses on an IP network.

Key characteristics:

Cross‑platform (macOS, Windows, Linux, Android, iOS, etc.).

Simple usage – just provide an IP or domain.

Comprehensive output – hop count, packet loss, latency, etc.

However, Traceroute alone cannot reliably pinpoint problems.

1.2 Limitations of Traceroute

Modern commercial networks rarely suffer from simple congestion or loops; most issues are complex and cannot be diagnosed solely with Traceroute.

Few engineers fully understand Traceroute, leading to high mis‑diagnosis rates in NOCs worldwide.

2. Traceroute Principles

2.1 How Traceroute Works

Source sends a probe packet to destination with TTL = 1.

TTL decrements at each hop.

When TTL reaches 0, the router discards the packet and returns an ICMP “TTL Exceeded” message.

Source records the hop information from the ICMP reply.

Repeat steps, increasing TTL by 1 each time.

Stop when destination replies with an ICMP “Destination Unreachable” or when the destination receives the probe.

2.2 Implementation Details

Traditional UNIX uses UDP probes (starting port 33434, incrementing each hop); Windows and MTR use ICMP Echo Requests.

If the destination does not send an ICMP “Destination Unreachable,” the hop cannot be detected (e.g., firewalls or filtered ports).

UDP/TCP/ICMP probes can all be used; TCP is usually avoided because it is often filtered.

Typical Traceroute sends three probes per hop; missing replies are shown as “*”. MTR sends probes continuously.

Each probe carries a unique identifier (incrementing UDP/TCP ports or ICMP sequence numbers).

Under ECMP, different probes may follow different paths; under LAG, they appear on the same link.

2.3 Latency Calculation

Timestamp the probe when sent.

Timestamp the ICMP reply when received.

Compute round‑trip time from the two timestamps.

Note: The displayed latency reflects the forward path, but the return path’s delay also influences the result.

2.4 How Each Hop Is Generated

When a router receives a packet with TTL = 0, it discards the packet and sends an ICMP “TTL Exceeded” message back to the source, using the router’s inbound interface IP as the source address. The source therefore sees the hop’s IP, but cannot learn the return path or the egress interface IP.

RFC 1812 requires the source address of an ICMP message to be one of the router’s physical interface IPs. In practice, some routers send the TTL‑Exceeded packet out a different interface, violating the RFC.

3 DNS Reverse Lookup in Traceroute

Reverse DNS provides valuable context for each hop:

Geographic location of the router.

Interface type and bandwidth.

Router role (core, edge, customer, etc.).

Autonomous System (AS) boundaries and relationships.

These details help infer whether a route is sub‑optimal or latency is expected.

3.1 Router Geographic Location

Knowing location helps identify illogical routing (e.g., Atlanta → Miami via New York) and assess whether latency is reasonable.

3.2 Interface Types and Bandwidth

DNS often encodes interface information (e.g., xe-11-1-0.edge1.NewYork1.Level3.net indicates a Juniper 10 GbE port). This can reveal router models and capacity.

Example interface mapping table (FastEthernet, Gigabit, 10 Gigabit, etc.)

3.3 Router Role

Common naming conventions:

Core routers – CR, Core, GBR, BB, CCR, EBR.

Peering routers – BR, Border, Edge, IR, IGR, Peer.

Customer routers – AR, Aggr, Cust, CAR, HSA, GW.

3.4 AS Boundaries and Relationships

Identifying AS edges helps understand routing policy changes, bandwidth bottlenecks, and who to contact.

Typical AS roles: Transit Provider, Peer, Customer. Some DNS names embed the AS information (e.g., te1-2-10g.ar3.DCA3.gblx.net).

4 Network Latency Types

4.1 Serial Delay

Time to transmit a packet on a link: packet size (bits) ÷ link speed (bps). Examples:

1500 bytes over a 56 kbps link ≈ 214 ms.

1500 bytes over a T1 (1.536 Mbps) ≈ 7.8 ms.

1500 bytes over Fast Ethernet (100 Mbps) ≈ 0.12 ms.

1500 bytes over Gigabit Ethernet (1 Gbps) ≈ 0.012 ms.

4.2 Queue Delay

Occurs when packets wait in a router’s buffer. High utilization leads to longer queues; at saturation, delays can reach hundreds of milliseconds.

4.3 Propagation Delay

Depends on signal speed in the medium. Light in fiber travels at ~0.67 c (≈200 000 km/s); 1 ms RTT corresponds to roughly 100 km distance.

Example: a signal around Earth’s equator (~40 000 km) incurs ~200 ms one‑way (400 ms RTT).

By correlating hop‑by‑hop geographic distance with measured RTT, you can judge whether latency is normal.

4.4 Real‑World Traceroute Example

Sample output (formatted as code):

3 xe-3-0-0.cr1.nyc3.us.nlayer.net (69.22.142.74) 6.570ms
4 xe-0-0-0.cr1.lhr1.uk.nlayer.net (69.22.142.10) 74.144ms
5 cr2.wswdc.ip.att.net (12.122.3.38) 8ms 8ms 8ms
8 192.205.34.106 [AS 7018] 228ms 228ms 228ms
9 te1-4.mpd01.iad01.atlas.cogentco.com (154.54.3.222) [AS 174] 228ms 228ms 228ms

The New York‑to‑London segment (≈ 67 ms) is normal, while the US‑internal segment (≈ 220 ms) indicates abnormal delay.

Original Source

Signed-in readers can open the original source through BestHub's protected redirect.

Sign in to view source
Republication Notice

This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactadmin@besthub.devand we will review it promptly.

tracerouteLatencyroutingnetwork operationsNetwork Diagnosticsdns reverse lookup
MaGe Linux Operations
Written by

MaGe Linux Operations

Founded in 2009, MaGe Education is a top Chinese high‑end IT training brand. Its graduates earn 12K+ RMB salaries, and the school has trained tens of thousands of students. It offers high‑pay courses in Linux cloud operations, Python full‑stack, automation, data analysis, AI, and Go high‑concurrency architecture. Thanks to quality courses and a solid reputation, it has talent partnerships with numerous internet firms.

0 followers
Reader feedback

How this landed with the community

Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.