≡ Menu

Finding out a bad or simply overloaded network link with MTR on a Linux & UNIX

Traditionally the traceroute (print the route packets take to network host) and ping (send ICMP ECHO_REQUEST to network hosts) programs are used as diagnostic tool to solve and isolate networking errors.

It may take some time to use both tools to diagnose network issues. However, you can use the mtr program instead of ping and traceroute. It is a network diagnostic tool and it is the combination of traceroute and ping programs (in terms of functionality) and works as a single network diagnostic tool.

How does mtr works?

Once mtr invoked it starts investigates the network connection between the hosts (workstation) mtr runs on and HOSTNAME by sending packets with purposely low TTLs (time to live). It will continue to send packets with low TTL, noting the response time of the intervening routers. This allows mtr to print the response percentage and response times of the internet route to HOSTNAME.

During this run if you notice a sudden increase in packet-loss or response time is an indication of overloaded link or a bad link.

Install mrt tool

Issue the following commands as per your Linux distro:

Installing MTR on a Debian and Ubuntu Linux

Type the following apt-get command to install the mtr:
$ sudo apt-get update
$ sudo apt-get install mtr-tiny

Installing MTR on a CentOS, RHEL and Fedora Linux

Type the following yum command to install the mtr:
$ sudo yum install mtr

Installing MTR on a Mac OS X

If you are using MacPorts, enter:
$ port install mtr
If you are using Homebrew, enter:
$ brew install mtr

Installing MTR on a FreeBSD Unix

To add the MTR package, run:
# pkg install net/mtr-nox11

Examples

The mtr command works on both GUI and curses based terminal interface. To start mtr just type the command
$ mtr upstream.router.isp.com
$ mtr sl-gw9-nyc-8-0.sprintlink.net
$ mtr -n router-ip
$ mtr -n 202.54.1.76
$ mtr gsrmum.vsnl.net.in

Sample outputs from GTK:

Force mtr to use the curses based terminal interface:
$ mtr -t www.cyberciti.biz
Sample outputs:

Here is an example of failed router (core-router.centramedia.net):
$ mtr core-router.centramedia.net
Sample outputs:

Use mtr from shell/perl scripts:$ mtr -c 5 -r gsrmum.vsnl.net.in >/tmp/output.vsnl.router
Where,

  • -c : Use this option to set the number of pings sent to determine both the machines on the network and the reliability of those machines.
  • -r : This option puts mtr into report mode.
  • -t: Force mtr to use the curses based terminal interface
  • -n : Disable DNS (i.e. not try to resolve the host names)

Task: Create an an MTR report

The syntax is:

 
mtr -r -w [dest_host|ip]
mtr --report --report-wide [dest_host|ip]
 

Where,

  1. -r or --report : This option puts mtr into report mode. When in this mode, mtr will run for the number of cycles specified by the -c option, and then print statistics and exit.
  2. -w or --report-wide : This option puts mtr into wide report mode. When in this mode, mtr will not cut hostnames in the report.

For example, the following command will sends 10 packets to the github.com and generates the output. Please note that MTR reports may take a few seconds to perform tests and generates the final reports:
# mtr -r -w github.com
Sample outputs:

Start: Wed Jun 24 05:04:12 2015
HOST: server1                                    Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- server1.cyberciti.biz                       0.0%    10    0.4   0.4   0.4   0.4   0.0
  2.|-- ae13.dar02.sr01.dal01.networklayer.com      0.0%    10    0.3   0.5   0.2   2.4   0.6
  3.|-- ae14.bbr01.eq01.dal03.networklayer.com      0.0%    10    0.3   0.3   0.3   0.5   0.0
  4.|-- ae54.edge5.dallas3.level3.net               0.0%    10    0.3   0.3   0.3   0.3   0.0
  5.|-- ae-1-60.edge3.Washington4.Level3.net        0.0%    10   33.6  34.3  33.5  40.2   2.0
  6.|-- ae-1-60.edge3.Washington4.Level3.net        0.0%    10   33.6  47.0  33.6 105.9  22.9
  7.|-- GITHUB-INC.edge3.Washington4.Level3.net     0.0%    10   34.5  34.5  34.5  34.6   0.0
  8.|-- 192.30.252.205                              0.0%    10   33.5  33.6  33.5  33.7   0.0
  9.|-- github.com                                  0.0%    10   33.2  33.2  33.1  33.3   0.0

Where,

  1. There are total 9 hopes i.e. routers on the Internet that packets transverse to get to github.com
  2. The Loss% column displays the percentage of packet loss at each hop.
  3. The Snt column displays the number of packets sent.
  4. The Last column displays measurements of latency in milliseconds of the last packet sent.
  5. The Avg column displays measurements of latency in milliseconds of the average latency of all packets.
  6. The Best column displays measurements of latency in milliseconds of the shortest round trip time for a packet.
  7. The Wrst column displays measurements of latency in milliseconds of of the longest round trip time for a packet.
  8. The StDev column displays the standard deviation of the latencies to each host.

In most cases you need to pay attention to the Loss% and Avg columns only.

How do I see packet loss?

# mtr -r -w github.com
Sample outputs:

Start: Wed Jun 24 05:04:12 2015
HOST: server1                                    Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- server1.cyberciti.biz                       0.0%    10    0.4   0.4   0.4   0.4   0.0
  2.|-- ae13.dar02.sr01.dal01.networklayer.com      0.0%    10    0.3   0.5   0.2   2.4   0.6
  3.|-- ae14.bbr01.eq01.dal03.networklayer.com      0.0%    10    0.3   0.3   0.3   0.5   0.0
  4.|-- ae54.edge5.dallas3.level3.net              30.0%    10    0.3   0.3   0.3   0.3   0.0
  5.|-- ae-1-60.edge3.Washington4.Level3.net       20.0%    10   33.6  34.3  33.5  40.2   2.0
  6.|-- ae-1-60.edge3.Washington4.Level3.net       50.0%    10   33.6  47.0  33.6 105.9  22.9
  7.|-- GITHUB-INC.edge3.Washington4.Level3.net    30.0%    10   34.5  34.5  34.5  34.6   0.0
  8.|-- 192.30.252.205                             50.0%    10   33.5  33.6  33.5  33.7   0.0
  9.|-- github.com                                 40.0%    10   33.2  33.2  33.1  33.3   0.0

Note down the Loss% column.

See also
Tweet itFacebook itGoogle+ itPDF itFound an error/typo on this page?

{ 3 comments… add one }

  • Anonymous April 24, 2006, 6:06 pm

    Very nice tool. Thanks for this great tutorial.

    Edinaldo La-Roque
    Author of XFwall
    http://sourceforge.net/projects/xfwall

  • Tiago November 8, 2006, 12:51 pm

    Well…great, but…

    What criteria is used for distint bad link of link overloaded ? How to identify the diference betwen overloaded and bad link?

    thanks…

  • nixCraft November 8, 2006, 1:09 pm

    Tiago,

    if you notice a sudden increase in packetloss or response time is an indication of overloaded link or a bad link.

Leave a Comment