STEP 1Know what each tool tells you

Three tools, increasing in power. Each answers a different question about the route between you and a destination.

• ping — is the destination reachable, and how long does a round trip take? It probes one point and reports round-trip time and packet loss. The quick “is it up, and is it slow?” — but it sees only the endpoint, not the path.
• traceroute (tracert on Windows) — which routers do packets pass through on the way, and where does latency appear? It lists each hop with its round-trip time. This is how you locate where a problem starts.
• mtr — ping and traceroute combined, running continuously. It shows every hop and the loss and latency at each one, over many probes. The right tool for anything intermittent, because a single traceroute is one snapshot and misses a problem that comes and goes.

STEP 2Run them

ping and traceroute / tracert are built in everywhere. mtr you install; on Windows use pathping or WinMTR instead.

Run them against the thing that is actually misbehaving — the game server, the video-call domain, the slow website — not just a generic target. The path to that destination is the one you need to see.

STEP 3Read a healthy path, hop by hop

Here is a real, clean run from a Perth home connection to this site (which is hosted in Perth). It is the baseline for “nothing wrong here”.

Where the hops sit — read outward from you:

• Hops 1–2 are both inside your own home. Two private addresses (192.168.0.1 then 192.168.1.1) mean two routers in series: here, my own Wi-Fi router at hop 1, sitting behind the ISP-supplied router at hop 2 — an arrangement usually called double NAT. Most homes have a single router and will see just one private hop here — that is normal, and everything below reads the same way with one fewer line. Trouble at either hop is on your side of the line: Wi-Fi, cabling, an overloaded router. Both are ~2 ms and clean.
• Hops 3–4 are your ISP’s network. The first addresses past the equipment in your house — hop 2 is the ISP’s router, but it still sits on your side of the line. Trouble that starts here is your provider’s access network.
• Hops 5–7 are the carrier backbone carrying you toward the destination.
• Hop 9 is the destination. ~14 ms, in Perth, close to you.

Reading the columns. Loss% is the one that matters most — 0% here at every hop. Avg is the number to judge; ~12–14 ms end to end is excellent (you are both in Perth). Notice Wrst occasionally spikes (52, 81 ms) while Avg stays ~13 — that is ordinary home-link jitter on the odd probe, not a fault. Judge the average; only worry about the worst if it is sustained.

Ignore hop 8 for now — it says 100% loss yet hop 9 is perfectly fine. That is the single most misread thing in these tools, and Step 5 is about it.

STEP 4Latency is mostly distance

The biggest thing beginners get wrong is reading high latency as a fault. Usually it is just distance — the speed of light in fibre is a hard limit. Here is the same home connection pinging four targets, near to far:

Each step out multiplies the latency. 360 ms to Germany is not broken — it is physics plus the route the traffic takes. A traceroute shows you where the distance is added. Watch the Sydney run cross the country:

The whole lesson is hop 6 → 7: 12 ms jumps to 51 ms, and the hostname says why — the packet just crossed from Perth to Adelaide, ~2,100 km of fibre in one link. Then it steps up city by city (Melbourne, Sydney) and holds. A big jump between two hops that then sticks is a long-distance link, not a fault. The hostnames often name the cities — read them.

The Frankfurt run tells the same story on a bigger scale, and adds two twists worth knowing:

Twist one — traffic does not take the short way. Perth to Frankfurt went east via Los Angeles and across the entire USA, not west. Routes follow cables and commercial peering, not the map. That is normal.

Twist two — hop 13 (281 ms) reads lower than hop 12 (368 ms). A later hop looking faster seems impossible. It is not: each hop’s time is that router’s own reply, generated at low priority, not a running total. A busy router can report higher than the one after it. Judge the trend and the destination, not every wiggle — and the destination here is steady at ~355 ms with 0% loss, so the path is healthy. Just far.

STEP 5The misread — numbers that look bad but aren't

This is the skill that separates a useful trace from a false alarm. Loss or latency only counts if it carries through every hop after it, all the way to the destination. A bad-looking middle hop that the next hops do not show is not a fault.

Look again at hop 8 from the healthy Perth capture in Step 3:

Hop 8 shows 100% loss — and a beginner stops there and panics. But hop 9, the actual destination, is 0% loss and 14 ms. If the path were really dropping everything at hop 8, hop 9 could not be clean. What is happening: that router simply does not reply to traceroute probes (many are configured that way, or rate-limit the replies as a low-priority courtesy). It still forwards your real traffic fine. Ignore it. Read the last line.

The Frankfurt run had the same trap in latency form — hop 8 read 179 ms on one probe, hop 10 read 450 ms on one probe, while the averages around them stayed steady and the destination was fine. Isolated spikes that do not persist are that router deprioritising a probe, not loss on your path.

STEP 6The other direction — return paths

Everything so far measures the path out to the destination. Traffic has to come back, and the return route can be completely different — and invisible from your machine. A path clean outbound but congested on the way back looks fine in your traceroute while everything still feels slow. This is the biggest blind spot of tracing from your own end.

To see the return path you trace from the far end toward you — using a looking glass (a public web tool that runs traceroute from another network; pick one near the destination from a directory such as traceroute.org), or, if you own the destination, straight from it. Here is a trace from a Sydney vantage point back to this Perth site:

Compare it to the forward Sydney trace in Step 4 and the lesson lands: going Perth→Sydney, latency climbed gradually across named cities (Perth, Adelaide, Melbourne, Sydney). Coming back Sydney→Perth, it stays ~1 ms across all of Sydney, then jumps once to 48 ms and holds — the whole return haul collapsed into a single hop, no cities shown. Same two endpoints, similar total latency (~48 vs ~59 ms), but the paths are not mirror images — different networks, different hops, different visibility. That asymmetry is exactly why you check both directions. (The 172.21.x and 10.74.x hops are private addresses on the carriers’ internal links — normal, and a hint you have left the public path.)

STEP 7What you can prove — and what you can't

State the limits so you don’t over-claim:

• A destination that ignores ping is not “down.” Many servers, and plenty of home routers, drop ICMP by policy — you saw it at hop 8 above. If the last responding hop sits right next to the destination and looks healthy, the service is probably fine even though the final line shows loss. Judge by the hop before, not the silent endpoint.
• One snapshot misses intermittent faults. If the problem comes and goes, a single traceroute often catches a good moment and shows nothing. Leave mtr (or pathping, or WinMTR) running for a few minutes: a hop that drops packets consistently across hundreds of probes is real, where the same hop over four probes tells you nothing.
• You are measuring the network, not the application. A clean path to a slow service points the finger away from the network — toward DNS, the server itself, or your own device. Worth knowing, because it stops you chasing a network fault that is not there.

Used this way, the path layer turns “my internet is bad” into “loss starts at my ISP’s second hop and holds to the destination across a ten-minute mtr, and the return path is clean” — a fault report a provider can act on, rather than a complaint they can wave away.