An important part of administering servers is monitoring network connectivity.
There are a few tools that are simple to use, but valuable to know. In this guide, we will discuss how to use a tool called traceroute
to diagnose where a network issue may be happening.
We will also look at a utility called mtr
which combines much of the functionality of ping and traceroute into one interface.
traceroute
is a simple tool to show the pathway to a remote server. This can be anything from a website that you are attempting to visit, to a printer on your local network.
The traceroute
program is installed by default on just about every Linux distribution, so you shouldn’t need to install it.
To call it, we simply need to provide a website or IP address that we would like to explore:
- traceroute google.com
You’ll receive output similar to the following:
Outputtraceroute 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 first line tells us the conditions that traceroute is operating under:
Outputtraceroute to google.com (173.194.38.137), 30 hops max, 60 byte packets
It gives the specified host, the IP address that DNS returns for that domain, the maximum number of hops to check, and the size of the packet that will be used.
The maximum number of hops can be adjusted with the -m
flag. If the host you are trying to route to is over 30 hops away, you may need to specify a larger value here. The maximum value you can set is 255.
- traceroute -m 255 obiwan.scrye.net
You can adjust the size of the packet that is sent to each hop by giving the integer after the hostname:
- traceroute google.com 70
You’ll see output like this:
Outputtraceroute 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
After the first line, each subsequent line represents a “hop”, or intermediate host that your traffic must pass through to reach the computer represented by the host you specified.
Each line has the following format:
Outputhop_number host_name (IP_address) packet_round_trip_times
Here is an example of a hop you might see:
Output3 nyk-b6-link.telia.net (62.115.35.101) 0.311 ms 0.302 ms 0.293 ms
Here is what each field means:
If you would like to change the number of packets that are tested against each host, you can specify a number with the -q
option, like this:
- traceroute -q1 google.com
If you would like to forgo the reverse DNS lookup to speed up the trace, you can pass the -n
flag:
- traceroute -n google.com
You’ll get output like this:
Outputtraceroute 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 dissolves into some asterisks (*), there is a problem 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 * * *
If your traceroute attempt stops at a particular hop or node and cannot find a route to the host, you have a problem.
While the hop where the route fails to return may be the location of the networking issue, it isn’t always that easy to diagnose.
Due to the fact that each ping represents a round-trip packet, and the situation where packets often use different pathways in either direction, it may indicate a problem in a completely different, possibly closer route.
It also may be the case that the problem is with the hop directly after the last hop you see. It is difficult to diagnose the exact location of the problem unless you can get a return traceroute from that specific hop. This is usually not possible outside of your own network.
A dynamic alternative to the traceroute program is mtr
. Combining the functionality of ping and traceroute, mtr allows you to constantly poll a remote server and see how the latency and performance changes over time.
Unlike traceroute, mtr is not installed by default on most systems. You can get it by typing the following commands.
Ubuntu/Debian:
- sudo apt-get install mtr
CentOS/Fedora:
- yum install mtr
Arch:
- pacman -S mtr
Once it is installed, you can call it by typing:
- mtr google.com
You’ll recieve output like this:
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 q
uit 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 look similar, the big advantage over traceroute is that the output is constantly updated. This allows you to accumulate trends and averages, and also allows you to see how the network performance varies over time.
If you ran a traceroute, there is a possibility that the packets that were sent to each hop happened to make the trip without incident, even in a situation where the route is suffering from intermittent packet loss. The mtr utility allows you to monitor for this situation by gathering data over a wider range of time.
It is also possible to run mtr with the --report
option, which returns the results of sending 10 packets to each hop.
- mtr --report google.com
The report looks like this:
OutputHOST: 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 useful when you don’t necessarily want to measure in real-time, but you want a greater range of data than traceroute provides.
With traceroute
and mtr
, you can get a sense as to which servers on your way to a specific domain or address are causing problems. This can be useful when troubleshooting an internal network, and also when trying to provide information to support members or ISPs when you are experiencing network problems.
Thanks for learning with the DigitalOcean Community. Check out our offerings for compute, storage, networking, and managed databases.
This textbox defaults to using Markdown to format your answer.
You can type !ref in this text area to quickly search our full set of tutorials, documentation & marketplace offerings and insert the link!
Excellent article and the clearest explanation I have ever seen of why MTR should be used. A very high standard of writing.
good very nice this site
This comment has been deleted
Claim points
Nice article. I have a question. I ran traceroute, and found that there is an increase of latency with one server. I pasted the traceroute below. As you might see one the #9 hop, the latency increses and doesn’t go down. How might i solve this? is there a way i might connect to a vpn and then connect to the webpage in order to diminish this latency? Is there anything i can do from my computer or the clients computer (because the ISP isn’t going to move a finger)? traceroute remote.mate.com traceroute to remote.mate.com (67.139.16.201), 30 hops max, 60 byte packets 1 192.168.4.1 (192.168.4.1) 0.142 ms 0.153 ms 0.174 ms 2 1-245-195-190.cab.prima.net.ar (190.195.245.1) 35.735 ms 35.781 ms 35.783 ms 3 * * * 4 * * * 5 * * * 6 9-165-89-200.fibertel.com.ar (200.89.165.9) 26.189 ms 237-165-89-200.fibertel.com.ar (200.89.165.237) 13.866 ms 9-164-89-200.fibertel.com.ar (200.89.164.9) 14.872 ms 7 250-165-89-200.fibertel.com.ar (200.89.165.250) 22.305 ms 15.703 ms 15.691 ms 8 ge-0-1-2.ar3.eze1.gblx.net (159.63.23.5) 15.620 ms 15.597 ms 15.584 ms 9 po3-20G.ar3.MIA2.gblx.net (67.17.75.66) 139.890 ms po2.ar3.MIA2.gblx.net (67.17.68.234) 136.998 ms 181.555 ms 10 ae5.edge2.miami2.level3.net (4.68.111.121) 184.563 ms 183.950 ms 190.760 ms 11 ae-23-52.car3.Chicago1.Level3.net (4.69.138.37) 224.550 ms 193.841 ms 187.657 ms 12 ae-23-52.car3.Chicago1.Level3.net (4.69.138.37) 178.595 ms 179.081 ms 177.543 ms 13 INTEGRA-TEL.car3.Chicago1.Level3.net (4.71.100.122) 184.659 ms 189.074 ms 183.205 ms 14 tg9-1.ar10.mplsmncd.integra.net (209.63.97.30) 191.308 ms 188.868 ms 193.198 ms 15 * * * 16 * * * 17 * * * 18 * * * 19 * * * 20 * * * 21 * * * 22 * * * 23 * * * 24 * * * 25 * * * 26 * * * 27 * * * 28 * * * 29 * * * 30 * * *
This comment has been deleted
This comment has been deleted
Good job on the article. Something to keep in mind is that if there are firewalls / routers dropping UDP or ICMP traceroutes you can often get a more complete result with tcptraceroute. Tracing to the open TCP port on a server or gateway.
I have a question. Sometimes, last hop (or last ping’able hop) gives lower ping than previous hops. For example:
(from sgp1 node to bulgaria) HOST: **************** Loss% Snt Last Avg Best Wrst StDev
As you can see, last hop is 250ms, while sofia pop of GTT.net is 320 ms. So which one is real?
The article is awesome! Thank you guys a lot!