How to trace IP packets and routes on Linux with traceroute

What traceroute is and why you need it

When you access a website or send data across the internet, information rarely travels in a straight line. It bounces through multiple routers, which are the devices responsible for guiding traffic between different networks. The traceroute command is a native Linux tool used precisely to map this journey, showing every stop your IP packet makes until it reaches the final destination. In practice, it acts like a network GPS, revealing the exact paths your data takes.

Knowing how to use this tool is essential for system administrators and enthusiasts who need to troubleshoot slowdowns or connection drops. Before performing complex analyses, we often combine software diagnostics with physical checks, such as inspecting cables, connections, or even bench power stability. Traceroute operates directly at the network layer, exposing the behavior of intermediate routers.

How the TTL mechanism tracks network hops

To discover which machines are in the middle of the path, traceroute uses an intelligent trick based on a field called TTL, or Time-to-Live. Despite the name suggesting time, TTL is actually an integer counter that decreases by one each time the packet passes through a router. When this value reaches zero, the current device discards the packet and sends back an error message stating that the time has expired.

The command leverages this behavior by sending packets with an initial TTL of one. The first router receives it, zeroes the counter, and returns a response, revealing its IP address. Next, traceroute sends another packet with a TTL of two, which passes through the first router and expires at the second, revealing the second IP. This process repeats successively until the packet finally reaches the desired destination and the test concludes.

Interpreting results and latencies in the terminal

When you run the command in the terminal, the output displays a table divided into columns that require careful attention. Each line represents a hop, corresponding to a different router along the path. Next to the IP address or host name, three numerical values appear in milliseconds, representing the time it took for the packet to make the round trip across three distinct transmission attempts.

These latencies help identify exactly where a network delay is happening. If a specific hop shows a very high response time compared to previous ones, you have found a potential routing bottleneck. If you want to deepen your audit of open ports and sockets on the same operating system, it is worth learning how to use the ss command on Linux to complement local traffic investigations.

Dealing with asterisks and security blocks on hops

One of the most common behaviors when using traceroute is encountering lines that display only asterisks instead of response times. This often causes confusion, but in most cases, it does not mean the internet is down or that there is a severe routing error. Many administrators configure their routers to ignore diagnostic packets or limit ICMP response rates to prevent denial-of-service attacks and save processing power.

When this happens, the packet may pass perfectly through the invisible router, but the return response is blocked, generating the famous asterisk symbol. It is important not to panic when seeing these partial display failures, as the test continues to work if subsequent hops respond normally. The secret is to observe whether the issue persists all the way to the destination or if it is just a specific device in the middle of the path maintaining discretion.

Practical differences between ICMP, UDP, and TCP packets

By default, depending on the version and operating system, traceroute uses different transport protocols to perform probe tests. On Linux, the traditional implementation usually sends UDP packets targeted at high, unlikely ports on the destination, while modern tools also allow switching to the ICMP echo request protocol or TCP packets.

Understanding these variations is useful because strict corporate firewalls often block UDP or ICMP packets while frequently letting TCP traffic pass through standard internet ports. Adjusting the protocol used in the command can mean the difference between getting a complete route map or receiving screens full of failures and asterisks due to restrictive security policies on the corporate network. To explore these architectural concepts further in production, see our related technical analysis on How to test an ATX power supply on the bench with a paperclip.

Final thoughts on IP route diagnostics

Mastering the traceroute command transforms how you view data traffic and troubleshoot connectivity faults. Instead of blindly rebooting equipment, conscious use of TTL and correct latency readings allow you to isolate whether a problem occurs on your local network, at your internet service provider, or on remote servers. Combining this tool with solid auditing practices ensures a much more transparent, secure, and maintainable network ecosystem.

Maintaining the habit of inspecting routes and understanding IP packet behavior is a valuable technical skill for any technology professional. Whether diagnosing sporadic slowdowns or mapping server infrastructure, the Linux terminal remains the definitive workbench for unraveling the mysteries of any modern connection.