Monitoring network connectivity is a crucial aspect of server administration. Within this realm, there are several straightforward yet invaluable tools to employ. This guide will explore the utilization of traceroute for pinpointing network issues and introduce mtr, a utility amalgamating ping and traceroute functionalities within a single interface.
Using Traceroute: A Comprehensive Guide
Traceroute Simplified: Navigating the Path to Remote Servers
Traceroute serves as a straightforward tool for unveiling the pathway to a remote server, whether it's a website you're attempting to access or a printer on your local network. With the traceroute program pre-installed on nearly every Linux distribution by default, there's typically no need for additional installations. Simply call it by providing the website or IP address you wish to explore.
| $ traceroute google.com |
You will be provided with output resembling the following:
| Output traceroute to google.com (173.194.38.137), 30 hops max, 60 byte packets 1 192.241.160.253 (192.241.160.253) 0.564 ms 0.539 ms 0.525 ms 2 192.241.164.241 (192.241.164.241) 0.487 ms 0.435 ms 0.461 ms 3 xe-3-0-6.ar2.nyc3.us.nlayer.net (69.31.95.133) 1.801 ms 1.802 ms 1.762 ms 4 144.223.28.73 (144.223.28.73) 0.583 ms 0.562 ms 0.550 ms 5 144.232.1.21 (144.232.1.21) 1.044 ms 1.048 ms 1.036 ms 6 74.125.49.212 (74.125.49.212) 0.494 ms 0.688 ms 0.643 ms 7 209.85.248.180 (209.85.248.180) 0.650 ms 209.85.248.178 (209.85.248.178) 0.621 ms 0.625 ms 8 72.14.236.208 (72.14.236.208) 0.618 ms 72.14.236.206 (72.14.236.206) 0.898 ms 72.14.236.208 (72.14.236.208) 0.872 ms 9 72.14.239.93 (72.14.239.93) 7.478 ms 7.989 ms 7.466 ms 10 72.14.232.73 (72.14.232.73) 20.002 ms 19.969 ms 19.975 ms 11 209.85.248.228 (209.85.248.228) 30.490 ms 72.14.238.106 (72.14.238.106) 34.463 ms 209.85.248.228 (209.85.248.228) 30.707 ms 12 216.239.46.54 (216.239.46.54) 42.502 ms 42.507 ms 42.487 ms 13 216.239.46.159 (216.239.46.159) 76.578 ms 74.585 ms 74.617 ms 14 209.85.250.126 (209.85.250.126) 80.625 ms 80.584 ms 78.514 ms 15 72.14.238.131 (72.14.238.131) 80.287 ms 80.560 ms 78.842 ms 16 209.85.250.228 (209.85.250.228) 171.997 ms 173.668 ms 170.068 ms 17 66.249.94.93 (66.249.94.93) 238.133 ms 235.851 ms 235.479 ms 18 72.14.233.79 (72.14.233.79) 233.639 ms 239.147 ms 233.707 ms 19 sin04s01-in-f9.1e100.net (173.194.38.137) 236.241 ms 235.608 ms 236.843 ms |
The initial line provides information regarding the conditions under which traceroute operates:
| Output traceroute to google.com (173.194.38.137), 30 hops max, 60 byte packets |
It indicates the specified host and the corresponding IP address retrieved from DNS for the domain, along with the maximum number of hops to examine and the packet size to be utilized.
The maximum number of hops can be modified using the -m flag. If the destination host is situated beyond 30 hops, you may need to specify a larger value. The maximum allowable setting is 255.
| $ traceroute -m 255 obiwan.scrye.net |
To modify the packet size sent to each hop, specify the desired integer after the hostname:
| $ traceroute google.com 70 |
The output will appear as follows:
| Output traceroute to google.com (173.194.38.128), 30 hops max, 70 byte packets 1 192.241.160.254 (192.241.160.254) 0.364 ms 0.330 ms 0.319 ms 2 192.241.164.237 (192.241.164.237) 0.284 ms 0.343 ms 0.321 ms |
Following the initial line, each subsequent line signifies a "hop" or intermediate host that your traffic traverses to reach the specified computer host. Each line adheres to the following format:
| Output hop_number host_name (IP_address) packet_round_trip_times |
Below is an exemplar of a hop you may encounter:
| Output 3 nyk-b6-link.telia.net (62.115.35.101) 0.311 ms 0.302 ms 0.293 ms |
Below is the breakdown of each field:
hop_number: Represents the sequential count of the degree of separation between the host and your computer. Higher numbers indicate that traffic from these hosts must traverse more computers to reach its destination.
host_name: Contains the result of a reverse DNS lookup on the host's IP address, if available. If no information is returned, the IP address itself is displayed.
IP_address: Displays the IP address of the network hop.
packet_round_trip_times: Provides the round-trip times for packets sent to the host and back. By default, three packets are sent to each host, and the round-trip times for each attempt are appended to the end of the line.
To alter the number of packets tested against each host, you can indicate a specific number using the -q option, as demonstrated below:
| $ traceroute -q1 google.com |
To expedite the trace by skipping the reverse DNS lookup, you can utilize the -n flag as shown:
| $ traceroute -n google.com |
The output will resemble the following:
| Output traceroute to google.com (74.125.235.7), 30 hops max, 60 byte packets 1 192.241.160.253 0.626 ms 0.598 ms 0.588 ms 2 192.241.164.241 2.821 ms 2.743 ms 2.819 ms 3 69.31.95.133 1.470 ms 1.473 ms 1.525 ms |
If your traceroute displays asterisks (*), it indicates an issue with the route to the host.
| Output ... 15 209.85.248.220 (209.85.248.220) 121.809 ms 72.14.239.12 (72.14.239.12) 76.941 ms 209.85.248.220 (209.85.248.220) 78.946 ms 16 72.14.239.247 (72.14.239.247) 101.001 ms 92.478 ms 92.448 ms 17 * * 209.85.250.124 (209.85.250.124) 175.083 ms 18 * * * 19 * * * |
What Signifies a Routing Problem?
Encountering a halt in your traceroute at a specific hop or node, indicative of an inability to find a route to the host, signifies a problem. Pinpointing the exact location of the networking issue isn't always straightforward. While the failed hop might seem the likely culprit, the complexity arises from the nature of round-trip packet pings and potential disparities in packet pathways. The issue could potentially lie closer or further along the route. Determining the precise problem location typically requires a return traceroute from the specific hop, which is often unattainable outside of your network.
Using MTR: A Guide
MTR serves as a dynamic alternative to the traceroute program. It combines the functionalities of ping and traceroute, enabling constant polling of a remote server to observe changes in latency and performance over time.
Unlike traceroute, MTR is not typically installed by default on most systems. You can obtain it by executing the following commands.
Ubuntu/Debian:
| $ sudo apt-get install mtr |
CentOS/Fedora:
| $ yum install mtr |
Arch:
| $ pacman -S mtr |
Once installed, you can initiate it by typing:
| $ mtr google.com |
You will receive output resembling the following:
| Output My traceroute [v0.80] traceroute (0.0.0.0) Tue Oct 22 20:39:42 2013 Resolver: Received error response 2. (server failure)er of fields quit Packets Pings Host Loss% Snt Last Avg Best Wrst StDev 1. 192.241.160.253 0.0% 371 0.4 0.6 0.1 14.3 1.0 2. 192.241.164.241 0.0% 371 7.4 2.5 0.1 37.5 4.8 3. xe-3-0-6.ar2.nyc3.us. 2.7% 371 3.6 2.6 1.1 5.5 1.1 4. sl-gw50-nyc-.sprintli 0.0% 371 0.7 5.0 0.1 82.3 13.1 |
While the output may appear similar, the significant advantage over traceroute lies in the constant updating of results. This feature enables the accumulation of trends and averages, offering insights into how network performance fluctuates over time.
Unlike traceroute, where packets may occasionally traverse without issue, even in the presence of intermittent packet loss along the route, the mtr utility monitors for such occurrences by collecting data over an extended period.
Additionally, mtr can be run with the --report option, providing the results of sending 10 packets to each hop.
| $ mtr --report google.com |
The report appears as follows:
| Output HOST: traceroute Loss% Snt Last Avg Best Wrst StDev 1.|-- 192.241.160.254 0.0% 10 1.5 0.9 0.4 1.5 0.4 2.|-- 192.241.164.237 0.0% 10 0.6 0.9 0.4 2.7 0.7 3.|-- nyk-b6-link.telia.net 0.0% 10 0.5 0.5 0.2 0.7 0.2 4.|-- nyk-bb2-link.telia.net 0.0% 10 67.5 18.5 0.8 87.3 31.8 |
This can be advantageous when real-time measurement isn't imperative, but you require a broader range of data than what traceroute offers.
Traceroute and MTR offer insights into servers causing issues along the path to a specific domain or address. This is invaluable for troubleshooting internal network issues and providing pertinent information to support teams or ISPs when encountering network problems.
