Traceroute: How to track network hops and find bottlenecks
Learn how the traceroute command works in practice. Discover how to identify each hop between routers and pinpoint where latency occurs in your network.
Summary
- Traceroute identifies every router in the path between the source and the final destination of a packet.
- The command uses the Time to Live (TTL) field to force responses from intermediate routers.
- High latency on a specific hop indicates exactly where the network bottleneck is occurring.
- Packet loss on a hop does not always mean failure, as some routers ignore ICMP requests.
- Tools like tcpdump complement route diagnostics when the problem requires deep packet inspection.
What is traceroute and why use it
When you access a website, your data does not travel in a straight line to the server. It passes through a series of intermediate routers, much like a series of train connections until it reaches the final destination. Traceroute is the essential tool for mapping this path. It shows exactly where your packet travels, revealing the IP address of each 'stop point', which we technically call hops.
Knowing how to track these hops is crucial for anyone facing slow connections or drops. If your internet is slow, the problem could be at your ISP, an international transit node, or the destination server itself. Without traceroute, you would be 'flying blind'. Combining this topology view with more granular tools, like diagnostics via tcpdump, allows you to isolate a routing issue from an application error.
How traceroute works under the hood
The secret of traceroute lies in an IP header field called Time to Live (TTL). The TTL is originally used to prevent packets from circling the network indefinitely if there is a configuration error. Each time a router processes the packet, it subtracts a value from the TTL. When the TTL reaches zero, the router discards the packet and sends an error message back to the sender.
Traceroute uses this behavior smartly. It sends packets with the TTL set to 1, forcing the first router to respond. Then, it sends packets with the TTL set to 2, forcing the second router to respond, and so on. By measuring the time it takes to receive these error messages back, the command calculates the latency specific to each hop, making it possible to identify where communication is being delayed.
How to read the command output
When you run the command in your terminal, you will see a numbered list. Each line represents a router on the path. The time, measured in milliseconds (ms), is the round-trip time (RTT) of the packet. If you notice that the response time increases dramatically from a specific hop onwards, you have found your bottleneck.
It is important not to confuse latency with packet loss. Some high-load or strictly secured routers may ignore diagnostic packets to prioritize real traffic. If you see asterisks in a row, do not panic; this may just be a 'silent' router. If you need to check for serious structural issues, it is worth reviewing the guide on how to find routing loops with traceroute to ensure traffic is not stuck in an infinite cycle.
Running the command in practice
To use the tool on Linux or macOS systems, simply open the terminal and type the command followed by the address or domain you want to test. See how to proceed:
- Open your preferred terminal.
- Type the base command followed by the IP or domain:
traceroute marciocunha.net - Observe the response times in ms for each hop.
- If you need to use the TCP protocol instead of UDP (which is blocked by some firewalls), use the -T flag:
traceroute -T -p 80 marciocunha.net
Conclusion
Traceroute is the first line of defense in understanding the health of your connectivity. By identifying where packets lose time or are discarded, you gain autonomy to demand solutions from the correct provider or adjust your internal infrastructure. Always remember to interpret the data with caution, considering that not all latency is a critical issue.
Practicing network commands strengthens your troubleshooting ability. If you are investigating more complex failures that do not appear in a traceroute, remember that other tools, like netstat, can be essential for checking the status of local connections and ports.