Wednesday, September 11, 2013

Resource Management : MTR

mtr ( Matt’s Trace route) is powerfull network diagnostic tool that provides various options including allowing administrators to monitor and diagnose various network issues. It also allows us to provide various network related reports.

In this article , we will see some of the basic uses of the mtr command.

Network diagnostic tool like ping , trace route uses ICMP ( Internet control message Protocol ) packets. MTR combines the functions of both the standard programs ping and trace route. So when a user uses a ping to test whether the remote machine is up or not , a series of ICMP packets are sent to the remote host ( Much Like Ping ). The remote machine in return send the ICMP packets back again. The user's client is then able to compute the round trip time between two points on the Internet.

Tools such as trace route and MTR send ICMP packets with incrementally increasing TTLs in order to view the route or series of hops that the packet makes between the origin and its destination.

Like Trace Route , it sets the TTL( Time to Live ) or the number of maximum hops a packet can take over the network , to a low number, increasing with each attempt. The TTL, or time to live, controls how many "hops" a packet will make before "dying" and returning to the host.

MTR collects additional information regarding the state, connection, and responsiveness of the hosts. Because of this, it is recommended that you use MTR whenever possible to provide the most complete overview of the connection between two hosts on the Internet.

Analyze MTR Reports
Mtr reports can be a little complex to understand. Consider the example of connectivity to

The command is executed as “mtr –report” which sends 10 packets to the host and generates the output. Without the --report option, mtr will run continuously in an interactive environment.

[root@vx111a Desktop]# mtr --report
HOST:              Loss%   Snt   Last    Avg    Best   Wrst   StDev
1. abs-static- 0.0%    10      1.5     1.5    1.5       1.6     0.0
2. abs-cn- 0.0%    10      16.8   17.0   16.8     17.8   0.3
3.                        0.0%    10      16.5    27.1  16.5    120.1 32.7
4.                        0.0%    10      16.6    16.6   16.6   16.7   0.1
5.                          0.0%   10       48.2    50.6  47.9   72.1   7.6
6.                          0.0%   10       48.3    48.4   48.1   49.4   0.4
7.       0.0%   10       49.1    49.1    49.1  49.2   0.0

Mtr some times takes a few more minutes to obtain the information. In this case there are 7 hops.
"Hops" are the nodes, or routers, on the Internet that packets transverse to get to their destination. The packet travels through the local network to the last network with a couple of hosts in between.

The columns include

The Loss% column shows the percentage of packet loss at each hop.
The Snt column counts the number of packets sent.

The --report option will send 10 packets unless specified with "--report-cycles=[number-of-packets]", where [number-of-packets] represents the total number of packets that you want to send to the remote host.

The next four columns Last, Avg, Best, and Wrst are all measurements of latency in milliseconds (e.g. ms).

Last is the latency of the last packet sent
Avg is average latency of all packets
Best and Wrst display the best (shortest) and worst (longest) round trip time for a packet to this host

The final column, StDev, provides the standard deviation of the latencies to each host

In most circumstances, you may think of the MTR output in three major sections. Depending on configurations, the first 2 or 3 hops often represent the source host's ISP, while the last 2 or 3 hops represent the destination host's ISP. The hops in between are the routers the packet traverses to reach its destination.

So if we are running the mtr from our local system , the first 2 or 3 hops belong to your ISP. The last 3 hops belong to the remote machine. Any hops in the middle are intermediate hops. if you see an abnormality in the first few hops near the source, contact your local admin or investigate your local networking configuration and , if you see abnormalities near the destination you may want to contact the network support for that remote machine . Unfortunately, in cases where there are problems on the intermediate hops, both service providers will have limited ability to address.

More to Come On how to analyze network Issue with the mtr command.
Keep learning :-)