Использование MTR для диагностики сети

MTR – это динамическая альтернатива программе traceroute. Объединяя функции ping и traceroute, mtr позволяет постоянно опрашивать удаленный сервер и отслеживать изменения задержки и производительности с течением времени.

В отличие от traceroute, в большинстве систем mtr не поставляется по умолчанию. Утилиту необходимо сперва установить.

Самый простой запуск:

mtr google.com
Start: Thu Nov  6 15:07:18 2014
HOST: my.eurohoster.org           Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- static-ip-188-138-124-67.  0.0%    10    1.4   1.2   1.1   1.4   0.0
  2.|-- static-ip-217-172-191-161  0.0%    10    0.2   2.5   0.2  19.8   6.1
  3.|-- 217.118.16.25              0.0%    10    3.3  11.0   3.3  51.4  16.8
  4.|-- 217.118.16.129             0.0%    10   26.2   6.1   3.4  26.2   7.1
  5.|-- de-cix20.net.google.com    0.0%    10    3.5   4.3   3.5   8.8   1.6
  6.|-- 209.85.251.150             0.0%    10    3.8   4.6   3.8   7.1   1.1
  7.|-- 209.85.242.185             0.0%    10    4.1   4.1   4.0   4.1   0.0
  8.|-- fra02s19-in-f0.1e100.net   0.0%    10    3.9   3.9   3.9   3.9   0.0

По умолчанию выполняется по 10 запросов.

Сначала вывод может показаться похожим на traceroute; но mtr имеет существенное преимущество – ее вывод постоянно обновляется. Это позволяет собирать  средние показатели, а также отслеживать тенденции и изменения производительности сети.

При запуске traceroute есть вероятность, что пакеты, отправленные на каждый хоп, были переданы должным образом, даже если маршрут пострадал от потери пакетов. Утилита MTR позволяет отслеживать подобные ситуации путем сбора данных в широком диапазоне времени.

Эта функция полезна при необходимости охватить более широкий спектр данных, предоставленных traceroute, не ограничиваясь реальным временем.

Рекомендуется запускать утилиту на 1000 запросов. Пример:

Опция -c 1000 говорит о том что посылается по 1000 пакетов.

mtr -nrc 1000 google.com
Start: Thu Nov  6 15:12:56 2014
HOST: my.eurohoster.org           Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- 188.138.124.67             0.0%  1000    1.5   1.1   0.9   6.0   0.3
  2.|-- 217.172.191.174            0.0%  1000    0.2   2.2   0.2  57.3   8.2
  3.|-- 217.118.16.29              0.0%  1000    0.7   2.5   0.3  45.8   4.8
  4.|-- 217.118.16.25              0.0%  1000    3.4   5.9   3.2  69.6   9.5
  5.|-- 217.118.16.129             0.0%  1000   14.8   6.3   3.3  61.1   8.0
  6.|-- 80.81.193.108             53.8%  1000    4.2   3.8   3.5  21.0   1.8
  7.|-- 209.85.251.150             0.0%  1000    3.8   6.4   3.7  32.8   5.8
  8.|-- 209.85.242.191             0.0%  1000    4.3   4.2   4.2 101.1   3.2
  9.|-- 173.194.113.39             0.0%  1000    3.7   3.7   3.6   4.0   0.0

Опция -n аналогична той что для traceroute. Да и в принципе для большинства утилит.

-r (--report) режим отчета. Только в этом режиме можно задать кол-во пакетов используя опцию -c. Также этот режим позволяет записать вывод в файл:

mtr -nrc 1000 google.com > google_mtr.log

Размер пакета задается опцией -s (--psize) в байтах.

Есть возможность запуска для проверки TCP пакетами - опция -T (--tcp):

mtr -nrc 1000 --tcp google.com

Tcp-порт задается опцией -P (--port).

Таймаус задается опцией --timeout.

Рассмотрим сделающий вывод:

mtr --report www.google.com
HOST: ducklington               Loss%   Snt   Last   Avg  Best  Wrst StDev
1. 63.247.74.43                  0.0%    10    0.3   0.6   0.3   1.2   0.3
2. 63.247.64.157                50.0%    10    0.4   1.0   0.4   6.1   1.8
3. 209.51.130.213                0.0%    10    0.8   2.7   0.8  19.0   5.7
4. aix.pr1.atl.google.com        0.0%    10    6.7   6.8   6.7   6.9   0.1
5. 72.14.233.56                  0.0%    10    7.2   8.3   7.1  16.4   2.9
6. 209.85.254.247                0.0%    10   39.1  39.4  39.1  39.7   0.2
7. 64.233.174.46                 0.0%    10   39.6  40.4  39.4  46.9   2.3
8. gw-in-f147.1e100.net          0.0%    10   39.6  40.5  39.5  46.7   2.2

Здесь мы видим потери пакетов между первым и вторым хопом. Это может происходить из-за лимита на частоту запросов у магистральных провайдеров. Это нормально. На конечном хопе, нашем хосте, потерь нет - 0%.

Второй пример:

mtr --report www.google.com
HOST: localhost                   Loss%   Snt   Last   Avg  Best  Wrst StDev
1. 63.247.74.43                   0.0%    10    0.3   0.6   0.3   1.2   0.3
2. 63.247.64.157                  0.0%    10    0.4   1.0   0.4   6.1   1.8
3. 209.51.130.213                60.0%    10    0.8   2.7   0.8  19.0   5.7
4. aix.pr1.atl.google.com        60.0%    10    6.7   6.8   6.7   6.9   0.1
5. 72.14.233.56                  50.0%   10    7.2   8.3   7.1  16.4   2.9
6. 209.85.254.247                40.0%   10   39.1  39.4  39.1  39.7   0.2
7. 64.233.174.46                 40.0%   10   39.6  40.4  39.4  46.9   2.3
8. gw-in-f147.1e100.net          40.0%   10   39.6  40.5  39.5  46.7   2.2

Здесь потери начинаются после второго хопа и держатся до последнего хопа. В этом выводе 40% потерь. На 3-5 хопах процент выше, но это может быть связано из-за ограничений частоты запросов у провайдеров. Стоит смотреть всегда следующий хоп.

Некоторые потери также можно объяснить проблемами в обратном пути. Пакеты могут быть доставлены по назначению без ошибок, но с трудом выполняться обратное их прохождение. По этой причине часто лучше выполнять MTR в обоих направлениях, чтобы исключить ошибочные суждения.

Третий пример:

mtr --report www.google.com
HOST: localhost                   Loss%   Snt   Last   Avg  Best  Wrst StDev
  1. 63.247.74.43                  0.0%    10    0.3   0.6   0.3   1.2   0.3
  2. 63.247.64.157                 0.0%    10    0.4   1.0   0.4   6.1   1.8
  3. 209.51.130.213                0.0%    10    0.8   2.7   0.8  19.0   5.7
  4. aix.pr1.atl.google.com        0.0%    10  388.0 360.4 342.1 396.7   0.2
  5. 72.14.233.56                  0.0%    10  390.6 360.4 342.1 396.7   0.2
  6. 209.85.254.247                0.0%    10  391.6 360.4 342.1 396.7   0.4
  7. 64.233.174.46                 0.0%    10  391.8 360.4 342.1 396.7   2.1
  8. gw-in-f147.1e100.net          0.0%    10  392.0 360.4 342.1 396.7   1.2

Здесь стоит обратить внимание на летентность запросов. 

В силу физических ограничений, задержка всегда возрастает с увеличением числа прыжков в маршруте. Тем не менее, этот рост должен быть последовательным и линейным. К сожалению, задержка часто относительная и очень зависит от качества связи между хостами и их физическим расстоянием. 

К сожалению, высокая латентность не всегда означает проблемы с текущего маршрута. Отчет выше говорит о том, что, несмотря на какою-то задержку с 4-го прыжка, трафик по-прежнему достигает хост назначения и возвращения к исходному хосту. Задержка может быть вызвана проблемой с обратном путь также. В приведенном выше примере, в то время как существует большой скачок в латентности между хостами 3 и 4 латентность не увеличивается в последующих хопах. Отсюда логично предположить, что есть некоторая проблема на 4-м маршрутизаторе.

Лимиты на частоту ICMP пакетов могут также проявлятся и в ланетности:

mtr --report www.google.com
HOST: localhost                   Loss%   Snt   Last   Avg  Best  Wrst StDev
  1. 63.247.74.43                  0.0%    10    0.3   0.6   0.3   1.2   0.3
  2. 63.247.64.157                 0.0%    10    0.4   1.0   0.4   6.1   1.8
  3. 209.51.130.213                0.0%    10    0.8   2.7   0.8  19.0   5.7
  4. aix.pr1.atl.google.com        0.0%    10    6.7   6.8   6.7   6.9   0.1
  5. 72.14.233.56                  0.0%    10  254.2 250.3 230.1 263.4   2.9
  6. 209.85.254.247                0.0%    10   39.1  39.4  39.1  39.7   0.2
  7. 64.233.174.46                 0.0%    10   39.6  40.4  39.4  46.9   2.3
  8. gw-in-f147.1e100.net          0.0%    10   39.6  40.5  39.5  46.7   2.2

Здесь также стоит обратить внимание на 6-й хоп, где латентность в норме.

MTR не всегда позволяет выяснить источник проблемы, но его вывод является помощником для сетевых администраторов при анализе проблемы.