What is MTR Tool?
Network status monitoring is one of the primary duties of server management. There are various tools for communication monitoring; however, MTR (My TraceRoute) is among the most powerful ones. This tool helps the network manager to diagnose errors and obtain a report on the overall status of the network.
The objectives of this article are to:
- Inspect the MTR tool,
- MTR production data,
- And, the method of analyzing the tool produced data.
A Brief Review of Primary Tools Functions in Network Error Detection
The network error detection tools, such as TraceRoute, Ping, and MTR, employ the Internet Control Message Protocol (ICMP) to test the communication and traffic exchange between two endpoints on the internet. While pinging an IP, the source transfers some ICMP packets to the destination, and, in response, the destination retrieves back some ICMP packets. According to the response exchange between the endpoints, the user can measure the Round Trip Time (RTT) value between them.
However, tools such as MTR and TraceRoute use the Time to Live (TTL) field on the IP packet header to measure the hops between the endpoints. TTL determines the number of hops through which a packet can travel before expiration. The TraceRoute or MTR applies the following method to measure the hop numbers:
- It, first, transfers some ICMP messages equal to the least TTL value (=1),
- Then the value (of the TTL) gradually increases until the packet finally reaches the destination.
We can introduce the MTR as a combination of two tools: Ping and TraceRoute. Besides a general overview of the route through which the traffic travels from the source to the destination, MTR provides more information about the hops' status, communication, and responsiveness between the endpoints.
How to Install an MTR
Unlike Ping and TraceRoute, MTR has not been installed on most systems by default. Therefore, apply the following commands to install this tool to suit your operating system:
- Ubuntu / Debian
- CentOS / RHEL / Fedora
Employ the WinMTR upstream to install the MTR on your Windows.
To install the MTR on MacOS X, use Homebrew or MacPorts. Apply the following command to install the tool if you are using Homebrew:
And the following command to install if you are using MacPorts:
How to Create an MTR Report
We can also consider MTR as a directional tool because it provides a view of the route through which the packet travels from the source to the destination. The round trip traffic routes may not be the same; therefore, assembling data through using MTR on both sides is recommended if you intend to check the communication problems between the endpoints.
One way of employing MTR is to insert the mtr command along with a URL or an IP address. See the following example:
The MTR great advantage over TraceRoute is that the MTR output is continuously updated, and you can observe the network functioning changes through time.
Another way of using MTR is to produce a report by the following command:
You can also add the n- option to the mtr command so that it displays every hop IP instead of displaying the hostnames. For example, the following command applies MTR to obtain a report from the Google public DNS:
Each one of the above output columns indicates specific information about the transferred packet:
- Host: It represents the hostname or the IP of every hop through which the packet has traveled,
- Loss: This shows the percentage of Packet Loss per hop,
- Snt: It displays the number of transferred packets,
- Last: This represents the last sent packet latency in milliseconds,
- Avg: You can see the average latency of all the packets in milliseconds,
- Best: It displays the minimum Round Trip Time of a packet in milliseconds,
- Wrst: It represents the maximum Round Trip Time of a packet in milliseconds,
- StDev: Here, you can view the latency standard deviation for every host.
Analyzing the MTR Output
The primary objective of using the MTR reports is to check the Packet Loss and Latency:
- Inspecting Packet Loss
The Packet Loss can be the result of one of the following issues:
- There is a problem with one of the routers on the packet travel route toward the destination,
- Or, the service provider puts a rate-limiting on the ICMP traffic.
Be noted that the packet loss does not indicate any problem with the latter one. For example, you can see that packet loss has occurred in the following figure; however, the reason is to employ rate-limiting on the 2nd hop.
The occurrence of Packet Loss in over one hop may signify a problem with routing or a single route on the traveling route to the destination. Be noted that packet loss and rate-limiting may sometimes occur concurrently. However, when the packet loss occurs in various hops, the value represented for the last one always indicates the precise percentage of the packet loss.
For example, in the following output, the precise packet loss is 30 percent, which is for the last hop (the 9th hop). The 4th, 5th, and 6th hops have used rate-limiting.
Hint: Remember that up to number 10 for the packet loss value is ordinary. However, if this percentage increases, it indicates a problem that requires more investigation. We suggest again that you apply MTR in both directions to obtain more exact information.
When employing MTR on a PC, if you encounter a large number of packet loss in the first steps, it signifies a problem with your ISP connection. However, if you meet such an issue on the final steps, it indicates a problem with the destination-side.
- Inspecting Latency
The Latency parameter depends on the distance between the endpoints as well as the line quality. There are different factors, such as incorrect router configuration on the route to the destination, link saturation, so on, that directly affect its value increase. While analyzing the MTR output, you should continually consider sudden increases in the Latency value - it may signify a problem with that hop router.
For example, in the following output sample, everything is normal until you arrive at the 6th hop. The Latency value suddenly increases in this hop and does not decrease in the following ones. According to this data, there is a problem with the router on the 6th hop.
If the Latency sudden increase is only on a hop and then it decreases, it can be the result of using rate-limiting. Notice that besides having an impact on the packet loss, rate-limiting affects Latency as well. As mentioned earlier, similar to that of packet loss, you should pay attention to the last hop data to measure the Latency amount.