All-in-one-for-rhel

How to Combine Ping and Traceroute On Linux Using MTR Command Examples

MTR stands for My Traceroute.

It is a powerful network diagnostic tool which combines the power of both Ping and Traceroutecommands.

It enables administrator to diagnose and isolate network errors and provide helpful network status reports.

In this article, we will explain how to install, use and analyze the report provided by the MTR command.

MTR works by sending ICMP packets by incrementally increasing the TTL value to find the route between the source and the given destination.

1. Installation

On debian or Ubuntu systems use the following command:

$ sudo apt-get install mtr

On centos and fedora systems execute the following command:

$ yum install mtr

2. Execute mtr for a Domain

MTR works in two modes, a graphical mode (X11) and text based mode (ncurses). By default, mtr command runs in X11 mode.

$ mtr google.com

The above command will openup a GUI window, and display the results.

3. Launch Text Mode using –curses

Use the –curses option to run mtr in terminal mode.

$ mtr --curses google.com

                     Packets               Pings

 Host                Loss%   Snt   Last   Avg  Best  Wrst StDev

 1. mblaze.hilink     0.0%    20    3.2   2.7   2.1   3.8   0.5

 2. 10.228.129.9      0.0%    20  187.7  61.8  41.6 187.7  31.3

 3. 10.228.149.14     0.0%    20  112.1  60.2  33.2 112.1  17.8

 4. 116.202.226.145   0.0%    20   57.9  63.2  35.2 147.6  24.4

 5. 116.202.226.21    0.0%    20   35.4  70.4  35.4 211.8  48.6

 6. 72.14.219.94      0.0%    20   58.9  74.6  43.4 231.2  44.2

 7. 72.14.233.204     0.0%    20   46.9  69.8  40.3 222.5  41.9

 8. 72.14.239.20      0.0%    20   94.1 259.2  68.8 3436. 748.2

 9. 209.85.244.111    0.0%    20   86.4  97.5  72.1 232.2  34.3

10. google.com        0.0%    19  387.9 132.5  71.8 387.9  84.9

The above will run continuously in interactive mode.

In interactive mode, the result will reflect the current Round Trip Time, for each host. From the above example, the packet traveled through “mblaze.hilink”, (my local router), then through a series of “hops”, and reaches the destination.

Hops are routers or nodes in internet which through which the packet travels to reach the destination.

4. Omit Reverse DNS using –no-dns

MTR finds the hostname of each router/node by using Reverse DNS Lookup. If you want to avoid doing a reverse DNS lookup, use –no-dns option.

$ mtr --curses --no-dns google.com

                       Packets               Pings

 Host                Loss%   Snt   Last   Avg  Best  Wrst StDev

 1. 192.168.1.1       0.0%     2    3.0   2.9   2.9   3.0   0.1

 2. 10.228.129.9      0.0%     2   58.6  49.6  40.7  58.6  12.7

 3. 10.228.149.14     0.0%     2   46.1  46.8  46.1  47.6   1.0

 4. 116.202.226.145   0.0%     2   61.8  61.6  61.3  61.8   0.3

 5. 116.202.226.17    0.0%     2   42.7  39.9  37.0  42.7   4.0

 6. 72.14.215.234     0.0%     2   47.1  43.9  40.7  47.1   4.5

 7. 72.14.232.110     0.0%     2   56.9  60.7  56.9  64.4   5.3

 8. 72.14.239.22      0.0%     2  111.5  95.0  78.5 111.5  23.3

 9. 209.85.244.23     0.0%     2  126.0 102.4  78.8 126.0  33.4

10. 209.85.223.113    0.0%    10   76.4  92.7  75.4 157.3  29.5

11. 74.125.200.102    0.0%     1   78.4  78.4  78.4  78.4   0.0

5. Execute mtr in Report Mode using –report

Instead of running MTR in interactive mode, you can run it in report mode using –report. In report mode, mtr will run for the number of cycles ( default 10 ), and then prints the statistics and exit. This mode will be useful for generating statstics about network quality.

$ mtr --no-dns --report google.com

HOST: lakshmanan                  Loss%   Snt   Last   Avg  Best  Wrst StDev

  1.|-- 192.168.1.1                0.0%    10    2.5   3.0   2.4   4.2   0.6

  2.|-- 10.228.129.9               0.0%    10  235.0  74.4  34.0 235.0  67.9

  3.|-- 10.228.149.14              0.0%    10  154.8  65.5  38.7 154.8  34.8

  4.|-- 116.202.226.145            0.0%    10   60.9  66.9  48.2 102.4  15.4

  5.|-- 116.202.226.17             0.0%    10   54.1  65.1  36.0 194.5  46.8

  6.|-- 72.14.215.234              0.0%    10   44.5  78.8  39.2 252.7  64.5

  7.|-- 72.14.232.110              0.0%    10   55.7  66.4  39.1 179.8  41.8

  8.|-- 66.249.94.72               0.0%    10   68.9  90.3  68.9 133.6  18.6

  9.|-- 72.14.233.105              0.0%    10   68.8  76.3  68.8  92.2   7.3

 10.|-- 173.194.38.162             0.0%    10   88.7 107.3  72.2 293.1  65.8

In the above example, mtr run for 10 cycles and collected the statistics. Users can change the number of cycles using the -c option.

Understand MTR Report

Beyond providing the information about the path between the source and destination, MTR provides valuable statistics regarding durability of the connection.

§ Lost% – Shows the % of packets loss at each hop.

§ Snt – Shows the no:of:packets being sent.

§ Last – Latency of the last packet being sent.

§ Avg – Average latency of all packets.

§ Best – Displays the best Round Trip Time for a packet to this host (shortest RTT).

§ Wrst – Displays the worst Round Trip Time for a packet to this host (longest RTT).

§ StDev – Provides the standard deviation of the latencies to each host.

Even if the “Avg” looks good, take a look at standard deviation. If the Standard deviation is high, then it may indicate that “Avg” is skewed by some measurement error or too much fluctuation. In such a case, take a look at Best and Wrst latency to make sure the average is good.

Analyze MTR reports

1. Verify Packet Loss

There is a common practice among the service provides to “Rate Limit” the ICMP traffic. This can provide an illusion of packet loss, when in fact there is no loss. To verify whether the loss is real or due to rate limiting, check the “Loss%” of the next hop. If it shows 0.0%, then you can be sure that the “Loss%” reported is due to the ICMP rate limiting and not actual loss.

 10.|-- 209.85.250.237             0.0%    10   85.6  97.5  76.0 172.0  27.2

 11.|-- 209.85.250.203            100.0    10    0.0   0.0   0.0   0.0   0.0

 12.|-- 74.125.135.138             0.0%    10   77.2 107.3  77.2 219.5  43.5

In the above output, though it show 100.0% Loss between hop 10 and 11, the next hop 12, reports 0.0% packets loss, which means the Loss reported on hop 11, is only due to ICMP rate limiting.

If the loss continues for more than 1 hop, then it is possible that there is some packet loss. Also note that Rate limiting and Packet Loss can happen concurrently. In that case take the lowest Loss% in a sequence as actual loss.

2. Improper Destination Host Networking

 13.|-- 4.69.168.254               0.0%    10  293.3 304.7 276.0 441.0  48.5

 14.|-- 4.69.161.105              10.0%    10  287.5 291.7 261.2 393.6  40.0

 15.|-- 4.69.137.50                0.0%    10  412.2 299.2 266.9 412.2  48.6

 16.|-- 4.69.134.146              10.0%    10  260.5 281.8 260.3 320.1  22.0

 17.|-- 4.69.134.129              10.0%    10  294.7 303.5 268.0 397.8  41.8

 18.|-- 4.69.132.177              10.0%    10  287.8 341.6 262.7 470.4  77.4

 19.|-- 4.71.162.50               10.0%    10  280.8 276.0 257.8 323.2  21.3

 20.|-- ???                       100.0    10    0.0   0.0   0.0   0.0   0.0

From the above example, it may look like the packets didn’t reach the destination. But it does reach the destination. This may be a result of improperly configured host or firewall rules to drop ICMP packets.

3. Timeout and Return Route Issue

Sometimes, routers will discard the ICMP and it will be shown as ??? on the output. Alternatively there can be a problem with Return route also.

  9.|-- 209.85.244.25              0.0%    10  260.6 147.0  78.1 260.6  75.3

 10.|-- ???                       100.0    10    0.0   0.0   0.0   0.0   0.0

 11.|-- 74.125.200.100             0.0%    10   84.8 112.4  75.6 234.4  63.9

In the above example, the router at hop 10 is either not responding to ICMP or there is a problem in the return route of the packet.