Technical reference

Traceroute technical details

This reference documents how the Traceroute tool runs a trace: where the probes are, what is measured at each hop, how the results are read, and what a remote trace cannot tell you. For reading traces in general, see How to Read a Traceroute.

Author
CategoryUsing the Tools

Where traces run

DNS Panopticon runs on Cloudflare Workers, which can open HTTP and TCP connections but cannot send ICMP or set the TTL of a packet, so a trace cannot start from our servers. Traces run instead on Globalping, a free, open network of community-hosted probes in data centers and homes around the world. The tool asks Globalping to run a measurement, then reads the result about once a second until it finishes, drawing hops as they arrive.

You choose where the probe is: anywhere, a continent, a country, or three continents at once (North America, Europe and Asia, one probe each) to compare paths. Globalping picks a probe that matches; the results name its city, network and AS number. Because the probe is not your computer, the path is the one from that probe’s network, not from yours. Run tracert, traceroute or mtr on your own machine to see your own path.

What is measured

Each trace is an mtr run, which combines traceroute and ping: every hop is probed three times, so each one reports loss, an average, the fastest and slowest reply, and jitter (the average change between consecutive replies), not just one sample.

OptionValuesNotes
ProtocolICMP (default), TCP, UDPICMP sends Echo Requests, like Windows tracert. TCP sends SYN packets to a port, which firewalls that allow a website usually let through.
Port1 to 65535TCP and UDP only. Defaults are 443 for TCP and 53 for UDP.
IP versionIPv4 or IPv6For host names only; an IP address sets its own version.
Packets per hop3Enough to show loss and spread while keeping a trace to about 10 to 30 seconds.
Probes1, or 3 to compareOne per chosen location.

Each hop’s address is named with a reverse DNS (PTR) lookup on the probe, and its AS number comes with the result. AS names, such as “Cloudflare, Inc.”, are looked up from Team Cymru’s IP to ASN mapping service.

The visuals

  • Network path groups consecutive hops by the autonomous system (AS) that answered, from the probe to the target. A hop with a private address (RFC 1918, carrier-grade NAT or link-local) belongs to the probe’s own network. Silent hops between two hops of the same network are counted in that network; otherwise they appear as “No reply”.
  • Latency by hop draws one bar per hop for the average round-trip time, a line from the fastest to the slowest reply, the loss percentage above any hop that dropped replies, and a hollow dot for a hop that did not reply. Each network keeps its colour across the path, the chart and the hop list.
  • Hops lists every hop with its name, address, network, average time, jitter and loss, so the chart is also available as text.

How a trace is read

The reading follows one rule: a problem is worth investigating only if it continues to the end of the trace. Even then, three probes per hop are a brief snapshot, and loss at the destination can come from how it handles probes, so repeat with more samples (for example a long mtr run) and check real application traffic before reporting a fault. Routers forward packets in hardware but answer probes in software, often rate-limited, so a single slow or silent hop is usually not a fault.

FindingWhen it appears
Hops did not replyA hop gave no replies, but a later hop did. Reported as normal.
Loss at the destinationThe destination lost replies. If every answering hop before it back to hop N also lost replies, loss is reported as starting at hop N.
Loss that does not continueA hop lost replies but a later hop answered with none lost. Reported as rate limiting. On a trace that stops, loss with no clean hop after it is named as a possible start of the failure instead.
Latency rises and staysThe average rises at least 20 ms from one answering hop to the next, and no later hop falls back by more than half the rise. The largest such rise is shown, often a long-distance link.
Slow to reply, not slow to forwardA hop is at least 40 ms slower than the one before it, but later hops are faster again.
The path loopsOne address answers at two hops that are not next to each other.
The trace stoppedNo hop with the target’s address replied. The last answering hop is named, with a suggestion to try TCP on port 443 when ICMP or UDP was used.

Limits of a remote trace

  • Only the path out. Replies can come back by a different route, so latency at a hop includes a return path the trace cannot see.
  • One probe, one moment. A trace is a snapshot from one network. Run it again, or from another location, before deciding a problem is persistent.
  • Load balancing. Routers spread traffic over parallel links, so different probes of the same hop can reach different routers. Globalping reports one address for each hop, so other routers at the same hop are not shown.
  • AS numbers are where the reply came from. Routers at exchange points and on links between networks often use addresses from the other network’s block, so the boundary between two networks can be off by one hop.
  • Public targets only. Private, loopback and internal names are refused, because a probe on the internet cannot reach them.

Limits and privacy

  • Each visitor can start 20 traces an hour and 100 a day. Globalping also limits how many tests DNS Panopticon can run each hour; when that limit is reached, the tool asks you to try again later.
  • Your IP address is not sent to Globalping; requests go from DNS Panopticon’s servers. Globalping keeps measurement results for a limited time under its own policies, and anyone with a measurement’s id can read it.
  • DNS Panopticon does not store traces. Results exist only in your browser.

Sources and further reading