Enterramon Decal 2

Using the Enterramon Hop Test (Traceroute)

What is traceroute

Traceroute is what you reach for when ping has already told you something is slow, but not why. Where ping only measures the round trip to a single target, traceroute maps every single network it passes through along the way, hop by hop, and times each one individually.

It works by sending packets with a slowly increasing time-to-live value, one hop, then two, then three, and so on. Each router along the path that the packet expires at sends a small message back, and that’s how the tool builds up the full path one hop at a time. The result is a list, starting at the region you tested from and ending at the target, showing everything the traffic passed through to get there.

Our Hop Test does exactly this, from five regions, with three separate timing samples per hop instead of just one.

Using the Enterramon Hop Test

Head to enterramon.com/trace-route-check and enter a domain or IP address.

Same two settings as Ping, and for the same reasons.

globe

Region

Cape Town, Frankfurt, Singapore, St Louis, or Sydney. The path traffic takes changes completely depending on where it starts, so if you’re chasing a routing issue that’s specific to a region, that’s the region to test from.

bring_your_own_ip

IP version

IPv4 or IPv6. Worth running both if the target supports both, since IPv4 and IPv6 traffic can genuinely take different physical paths through different networks.

Hit Run Test and we map every hop between the chosen region and the target, with three timing samples per hop rather than one.

Understanding the traceroute results

The results break down into a few blocks:

hub

Hops

The total number of unique hops the path crossed to reach the target. A short path isn’t automatically better, it just tells you how many networks the traffic passed through. What matters more is what’s happening at each one.

public

Countries

How many countries the path physically crossed. Handy for a quick sanity check, if you’re testing from Cape Town to a server that should be hosted locally and the trace shows the path bouncing through three other countries first, that’s worth investigating on its own. The country tag is determined by the listed location of that IP or subnet, this is not always accurate as the listed location of the IP may not be where it actually is used on the internet.

timer_off

Timeouts

How many hops along the path didn’t respond at all. This is one of the more misunderstood numbers on the page, and it’s worth being upfront about it here rather than leaving it to guesswork, some routers are configured to not respond to this kind of probe at all, as a deliberate security or load setting, not because anything is actually broken. A timeout mid-path with a clean, fast result at every hop after it usually just means that one router doesn’t reply. A timeout at the very end, right where the target should be, is a different story and worth a closer look, but could also be a firewall rule or access list, or an actual issue that needs to be investigated.

list_alt

Per-hop detail

For each hop you get the IP address, the hostname if it resolves, three separate round-trip times, and the country and network operator responsible for that hop. The three RTT samples per hop matter for the same reason the packet table matters on Ping, a single slow reading could be a momentary blip, but three consistently slow readings at the same hop is a real pattern. If a hop fails to respond, it’s explicitly marked as such rather than left blank, so you can tell the difference between a hop that’s slow and one that’s simply silent. Of course a slow hop could mean you have congestion on the route or you are changing continents, so knowing where you are testing from and to can be important.

How traceroute can help you

Ping tells you a server is reachable and gives you a rough sense of how fast. Traceroute tells you where along the way any delay is actually happening.

When ping times come back high, traceroute is how you find out whether the problem sits at the destination server itself, several networks upstream, on a congested transit link somewhere in the middle, or because traffic is being routed through a longer physical path than it needs to be. Those are four very different problems with four very different fixes, and ping alone can’t tell you which one you’re looking at.

This is especially useful for anything international. A visitor connecting from one continent to a server on another crosses several networks to get there, and every so often one of those networks has a bad day. Traceroute shows you exactly which hop that is, rather than leaving you to guess whether it’s your server, your host’s network, or something entirely outside anyone’s control.

It’s also worth running before and after any routing-relevant change, a new CDN, a BGP update on your provider’s side, a change in upstream transit. Comparing a trace from before the change to one after is usually the clearest way to confirm traffic is taking the path you expect, and to catch it quickly if a change has quietly sent visitors somewhere less direct than before.

What traceroute is not

Traceroute maps the path. It doesn’t tell you anything about what happens once the traffic actually arrives at the server, that’s a job for Server Check or a full page load test instead.

It’s also not a perfect map of every path every visitor takes. A trace shows you the specific path from one test region at one moment in time. Real users are scattered across many networks and locations, and routing can change between tests, sometimes hop to hop, sometimes for the whole path, depending on how the networks in between are configured. Treat a single trace as a sample of the route, not a permanent guarantee of it.

And timeouts need reading carefully rather than taken at face value. A silent hop in the middle of an otherwise clean trace usually means that router just doesn’t respond to this type of probe, not that anything is actually failing. It’s the pattern across the whole trace that tells the real story, not any single line in isolation.

If ping alone already gave you a clean result with no packet loss, a trace usually won’t add much, since there’s no delay to go hunting for. Traceroute earns its place once ping has already shown you something’s off and you need to know where.