Traceroute Hops Analyzer

Introduction

Traceroute output is a breadcrumb trail from one networked device toward another. Each row is a visible hop, usually a router or endpoint that replied when a probe reached a specific time to live, also called TTL or hop limit. The row does not prove that the router is slow, broken, or even on the exact path every packet will take. It proves only that a diagnostic probe produced a visible reply at that point in one capture.

MTR adds repeated measurements to the same idea. Instead of one short route sample, it records loss and round-trip time across many probes, which makes intermittent delay and packet loss easier to spot. Windows tracert, Unix-style traceroute, tracepath-like output, and MTR reports use different wording, but the same practical question remains: did the problem appear at the destination, continue downstream, or show up only on a middle device that may be treating diagnostic replies differently from normal traffic?

Good traceroute reading depends on comparing rows, not reacting to the loudest single value. A lone asterisk row in the middle of the path can be harmless when later hops respond. A high middle-hop latency can be misleading when the destination stays steady. Final-hop loss, loss that repeats on later rows, and a delay step that stays high after the jump usually deserve more attention.

• Stronger evidence: final-hop loss, a trace that stops before the destination, or increased RTT that persists through later responding hops.
• Weaker evidence: one isolated middle hop with asterisks, loss that disappears downstream, or one high probe beside otherwise normal values.
• Common mistake: treating the first unusual hop as the failing link before checking whether later hops still answer cleanly.

Terminology matters because the same visible mark can mean different things. RTT is round-trip time in milliseconds, not one-way delay. A timeout is a missing diagnostic reply, not always a dropped user packet. Packet loss in MTR is measured across repeated probes, while asterisks in a short traceroute sample are only a small sample of missing replies.

Route evidence is also time-sensitive. A capture taken after a brief outage may look normal, and a capture from one network may not match the route from another office, cloud region, or VPN exit. Repeat tests during the symptom window, keep the target and thresholds consistent, and treat hostnames, private addresses, provider names, and service labels as operational log data when sharing results.

The best use of a route sample is to narrow the next check. It can support a provider ticket, compare a VPN path with direct internet access, or show that application symptoms line up with final-hop loss. It cannot by itself prove the physical link, commercial carrier, or remote host responsible for every failure.

How to Use This Tool:

Start with one captured route sample, choose gates that fit the network path, and compare the summary with the parsed rows before sharing evidence.

1. Enter a Destination label such as a hostname, IP address, ticket number, or service name. The label appears in the brief and exported evidence; it does not start a live lookup.
2. Set Latency jump threshold in milliseconds. A lower gate can help on LAN or short private paths, while a higher gate is less noisy for internet, VPN, or WAN traces.
3. Set Loss threshold as a percentage. The gate is used for MTR Loss%, partial asterisk rows, and final-hop loss checks.
4. Paste one traceroute, tracert, tracepath-like, or MTR report into Traceroute or MTR output, or load a TXT, LOG, OUT, or plain-text file under 1 MB.
5. Use Normalize after copying from a terminal, chat, or ticket with uneven spacing. It trims line endings and trailing whitespace without changing hop numbers or thresholds.
6. If Trace input needs attention appears, check that the sample contains numbered hop rows and at least one recognizable timing, timeout, or MTR report row.
7. Read Path Snapshot first, then use Escalation Findings, Hop Evidence Ledger, and Hop Delay Step Profile to verify each flagged delay step, timeout, or loss row.

Open JSON or download table and chart evidence only after the parsed hop rows match the original capture well enough for an incident note, provider ticket, or before-and-after comparison.

Interpreting Results:

The headline separates a steady parsed sample from a sample with threshold findings. Traceroute Path Looks Steady means no parsed timeout, latency step, or loss row crossed the configured gates. Traceroute Escalation Brief means the findings table has at least one row that needs review.

Check the final row before blaming the middle of the path. A middle hop can show asterisks or loss because it did not answer probes, while later hops prove forwarding continued. A final row with loss, or loss that carries into later rows, is stronger evidence for a service-impacting route problem.

A high finding count does not prove root cause. Load balancing, asymmetric return paths, Multiprotocol Label Switching (MPLS) tunnels, private carrier networks, and diagnostic-reply handling can all move the apparent problem away from the link users feel. Use the evidence to choose the next test, not to close the investigation from one sample.

Technical Details:

Traceroute-style diagnostics work by sending probes with increasing TTL or hop-limit values. When a router decrements the limit to zero, it may return an Internet Control Message Protocol (ICMP) time-exceeded message. That response exposes a visible hop and a round-trip time for that probe. The destination is reached when the final host sends the expected response for the probe type, such as an ICMP echo reply for Windows tracert or a port-unreachable response for common UDP traceroute behavior.

Different tools print the same idea in different shapes. Unix traceroute rows often contain three timing probes or asterisks. Windows tracert rows can include <1 ms timing and Request timed out. wording. MTR reports include repeated-measurement columns such as Loss%, Snt, Last, Avg, Best, Wrst, and StDev. Interpretation changes when those columns show destination loss, downstream loss, or only a middle router that did not answer probes.

Rule Core

Formula Core

The latency and loss gates are simple comparisons, which keeps the hop evidence auditable.

If hop 2 averages 4.0 ms and hop 3 averages 42.0 ms, the step is 38.0 ms. With the default 25 ms gate, that becomes a latency finding. If a traceroute row has two returned probes and one asterisk, the inferred row loss is 33.3%.

Displayed Evidence

The compact route skyline above the form uses the same parsed hops as a quick shape check. Responding hops get latency stems, timeout rows stay near the baseline, flagged states use stronger color, and the largest latency value is labeled. The detailed evidence remains in the tables, chart, and JSON output.

Comparisons are strongest when the destination, capture time, path source, and gates stay consistent. Changing the loss gate from 20% to 5%, or comparing an office route with a VPN route, can change which findings appear even when the raw hop text is valid.

Privacy Notes:

The page analyzes route text that was already captured elsewhere. It does not run traceroute, ping the destination, or test the service from the site server.

• Pasted trace text and selected TXT, LOG, OUT, or plain-text files are processed in the browser after the page loads.
• Selected text files must be under 1 MB.
• Exports preserve parsed host text, addresses, and labels so the evidence remains auditable.
• Review output before sharing it outside the incident, provider, customer, or internal network boundary.

Worked Examples:

Unix traceroute with one large delay step

The sample traceroute to app.example.net parses five hops. Hop 2 sits near 3.9 ms and hop 3 near 42.1 ms, so Largest latency step is about 38 ms. With the default 25 ms latency gate, Escalation Findings reports Latency step above gate. Hop 4 has * * *, but hop 5 responds, so the timeout is read as intermediate no-reply.

Windows tracert with timeout wording

A Windows capture can use <1 ms timing and Request timed out. rather than Unix-style asterisks only. The parsed Path Snapshot still shows the destination label, hop count, largest step, and final state. Hop Evidence Ledger keeps the no-reply row visible so Windows and Unix captures can be compared after separate runs.

MTR row with middle-hop loss

An MTR report row with 5.0% loss stays below the default 20% loss gate. A later 100.0% no-reply row can still be noted, but if the destination row responds without loss, the result treats the middle row as weaker evidence than final-hop loss.

Final-hop loss during an incident

If the destination row itself crosses the loss gate, Escalation Findings reports Final-hop loss above gate. That is the point to capture a longer MTR, keep the time window, and compare from another source before handing the case to a provider or service owner.

FAQ:

Glossary:

Hop

A visible step in a route sample, usually a router or endpoint that answered a hop-limited probe.

RTT

Round-trip time, measured in milliseconds, from sending a probe to receiving a response.

TTL or hop limit

The packet field that limits how far a probe travels before a router may return a time-exceeded response.

MTR

A repeated route diagnostic report that shows per-hop latency and packet-loss statistics.

Asterisk row

A traceroute row where one or more probes received no visible reply.

Latency step

The increase in average RTT between one responding hop and the next responding hop.

Final-hop loss

Loss reported or inferred on the destination row, usually stronger evidence than isolated middle-hop loss.

References:

• RFC 792: Internet Control Message Protocol, RFC Editor, September 1981.
• RFC 5388: Information Model and XML Data Model for Traceroute Measurements, RFC Editor, December 2008.
• Use the Traceroute Command on Operating Systems, Cisco.
• How to properly interpret a traceroute or MTR, APNIC Blog, March 28, 2022.