The traceroute Command: Analyzing Network Routes from Console or GUI

Life, at least in IT, is what happens between system and network failures. And when a service is down or connectivity is down, the question is: Where is the failure? Because a ping tells you whether the service is alive or not, but that doesn’t help much. To locate bottlenecks and where the specific error is, we have the traceroute command, which we will analyze in depth.
He will teach us all that so poetic that the important thing in a journey is the way and not the destination.

What is the traceroute (or tracert) command?

Traceroute (on Linux/macOS) and tracert (on Windows) are diagnostic tools that identify the specific route that IP packets follow from your computer to a destination.
The goal is that very movie-like “follow that car”, to reveal every intermediate hop it makes (router, firewall, gateway) until it gets to where we tell it to.
Besides being a diagnostic tool, traceroute can be used in other IT aspects, such as security, detecting firewalls or mapping the infrastructure. Or in optimization, to check if that CDN really saves hops and milliseconds, going through the optimal route between source and destination.
However, today we will focus on the fundamentals.

How traceroute works: TTL, ICMP and hops

The traceroute mechanism is ingenious, because it exploits a property of packets, the fact that the IP standard mandates the inclusion of a TTL (Time To Live) value.
This was not done to trace them, but the TTL determines how many hops, at most, can be made to the destination. Thus, a TTL=1 means that our packet will stop at the first intermediate hop (or at the destination if we reach it in one hop, which is doubtful).
So traceroute does this to find out the path of a packet:

• A packet is sent with TTL = 1. The first router to receive it subtracts 1 and the TTL goes to 0, discards the packet and returns an ICMP message “Time Exceeded”.
• Traceroute records the IP and response time of that router.
• Well, now the process is repeated increasing the TTL of the packet progressively (2, 3, 4…) until the destination is reached.
• The final destination responds with an ICMP “Echo Reply” (if not blocked).

In this way, thanks to the TTL property, traceroute sends packets, each time with a higher TTL, that trace the path, showing each hop (each network device that touches the packet).
And what is the difference between traceroute and tracert? Well, besides the operating system…

• Traceroute (Linux/Unix): uses the UDP protocol by default and targets high ports (33434 to 33534), although it is versatile and you can define it to use TCP, ICMP Echo Request…
• Tracert (Windows): Uses ICMP Echo Request packets.

With that, we can detect problems such as:

• Route loops: A packet trapped between routers.
• Firewall blockages: Jumps that return * * * * (timeouts).
• High latency bottlenecks: Jumps with excessive response times.
• Packet loss: Indicated by % loss in some outputs.
• Inefficient routes: Geographical detours or unnecessary jumps.

How to Run Traceroute from the Command Line

Let’s take a look at how to run it, starting with Windows.

Windows (tracert)

On our machine, we run Powershell and type, for example:
tracert google.com
You’ll get an output similar to this:

1 1 ms <1 ms <1 ms router.home [192.168.1.1]
2 15 ms 14 ms 16 ms dsl-10-20-30-40.isp.com [10.20.30.40]
3 * * * Request timed out.
4 30 ms 29 ms 28 ms core-router.mad.isp.com [80.40.200.1]

We’ll analyze this output in a moment, but first let’s look at Linux and its Unix cousins.
In the terminal, run:
traceroute google.com

Or, if you want to use ICMP like in Windows:

traceroute -I google.com

Some other useful parameters include:

• -n: It skips DNS resolution (faster output).
• -m 30: It sets a maximum hop limit (30 by default).
• -q 2: Number of probes per hop (3 by default).

Let’s interpret the output:

• Numbered hops like 192… or 10.20…: Each line is a device along the path. If you’ve used -n, you’ll only see IP addresses.
• Three time values (in ms): Round-trip latency for each probe (lower and more consistent values are better).
• * * *: Asterisks indicate no response from that hop and are often central to diagnosing issues (especially when combined with high latency), but they don’t always mean the same thing.

The common causes of asterisks are:

• The router is overloaded, or QoS policies prioritize other traffic over traceroute responses—this alone might point to a potential issue.
• There’s a connectivity failure.
• Network configurations prevent traceroute packets from being processed correctly.
• You’ve hit firewalls or filters that block ICMP or UDP responses. However, this doesn’t always mean the packets were blocked from passing through—just that the device refused to answer. (Though some policies may block packets entirely, showing only asterisks from that point on.) As seen in the earlier example, you might still see later hops if the TTL is high enough.

From here, you may start to investigate the problem.
For example, you might want to reconfigure your “probe”—like in Star Trek—using -I, since some systems drop UDP packets due to policy but may respond to ICMP. You may also try -w with a longer wait time (e.g., 15 seconds) in case the hop is alive but slow to respond.
If it still doesn’t reply, it could be a firewall explicitly configured to drop responses.
That said, when it comes to diagnosing and troubleshooting in even moderately complex infrastructures, CLI tools like traceroute face common limitations: inconvenient output formatting, possible requirement for elevated permissions, and lack of visibility into other metrics like jitter…

Graphical and Online Alternatives

If you’re not a fan of staring into the black abyss of the terminal, need more features, or just want to avoid the hassle, there are graphical and web-based traceroute tools available.
A quick search will show you online tools like this one or this other one, but they’re often not very useful—because they run from their own servers, not yours. Plus, many are so restricted that you’ll end up seeing more asterisks than in your Wi-Fi password.
That’s why one of the most convenient options is to use the 100% free Pandora MINI app for Windows. Sure, there are others like MyTraceroute, but they’re far more limited in terms of functionality.

Route Analysis with Pandora MINI

Pandora MINI makes your life easier with a variety of monitoring and diagnostic tools, including the ability to run traceroute in a simple and visual way.
Once installed like any other Windows software, all you need to do is select the Tools option from the top menu and, in the dropdown, choose Check Traceroute.
On the screen that appears, you can easily configure the process without having to mess with terminal parameters.
You’ll then be able to intuitively see the ordered hops, the latency of each one, and all the information provided by traceroute—no need for a terminal or elevated privileges.

Other Useful Network Functions in Pandora MINI

However, the main advantage of Pandora MINI is that it integrates a full toolbox for network analysis and monitoring.
Traceroute is very useful, though it’s just the beginning of a proper network diagnosis. Thanks to the additional built-in tools, you can carry out a much more complete diagnosis with:

• Real-time, graphical ping monitoring to check whether problematic services are down or not.
• Packet loss monitoring.
• Jitter calculation across the network.
• Web checks and much more such as IP calculator or MIB browser in a Swiss Army knife of network utilities.

This way, you have more tools at your fingertips when traceroute reveals an issue.

Common Use Cases

Imagine you need to ensure a service is working perfectly. The first thing you can do is monitor it with a ping, which tells you if it’s reachable and shows its latency.

• Add the service to your real-time monitoring view by going to Monitoring > Ping, easily filling in the details and clicking “Add.”
• Now you’ll get a real-time availability graph. But as the saying goes, joy doesn’t last long in a poor man’s house—or in an IT admin’s either. So soon enough, you’ll notice something wrong. For example, latency might be high.
• In that case, without leaving Pandora MINI, you may use traceroute to pinpoint problematic hops.

Another common scenario is packet loss.

• Let’s say you’re monitoring a service like your internal app, app.company.com. Add it to the main monitoring dashboard via Monitoring > Packet loss.
• You see packet loss taking place and need to dig deeper.
• From Pandora MINI, you may run a traceroute to gain additional insight into what might be going on.
  As we can see, traceroute/tracert is an essential tool for any technician.

If you’re a command-line wizard or just need a quick check, the terminal might do the trick. I live in it often myself—not just to escape into the nostalgic silence of simpler days.
However, for quick support scenarios, on-site audits, or when you’re less comfortable with CLI, a graphical tool like Pandora MINI offers the simplicity and all-in-one advantage we’ve explored.