mtr - traceroute + ping в одном

Зачем mtr вместо traceroute

Обычный traceroute делает по 3 проба на каждый hop и показывает один результат. Если потеря 50% - traceroute может её пропустить.

mtr опрашивает все hop'ы непрерывно (раз в секунду), накапливает статистику и показывает в реальном времени:

• loss % на каждом hop
• последний RTT, среднее, лучшее, худшее, jitter
• количество отправленных проб

Это первый инструмент при жалобах «лагает», «теряются пакеты».

Минимальный запуск

mtr example.com

Интерактивный режим: каждую секунду строки обновляются. q - выйти.

Типичный вывод:

HOST: myhost                Loss%   Snt   Last   Avg  Best  Wrst

 1. _gateway                 0.0%    20    0.5   0.6   0.4   1.2

 2. 10.0.0.1                 0.0%    20    1.1   1.3   1.0   2.5

 3. provider-router          0.0%    20    5.2   5.4   5.1   8.0

 4. ???                     100.0%   20    0.0   0.0   0.0   0.0

 5. core1.isp.net            5.0%    20   12.1  12.5  11.8  15.0

 6. example.com             5.0%    20   25.3  25.5  24.9  28.0

Hop 4 = ICMP не отвечает (фильтруется), но трафик через него идёт - loss 5% на hop 5 и 6 настоящий, на hop 4 не считаем.

Как читать loss

• Loss растёт постепенно с одного hop'а - этот hop теряет пакеты (или его аплинк)
• Loss появляется и держится одинаковый дальше - проблема на том hop, где впервые появился
• Loss 100% на hop, но 0% на следующих - просто rate-limit ICMP, нормально, не баг

Опции

-n - без DNS-резолва

mtr -n 8.8.8.8

Не делает [[dns-resolution|reverse DNS]] для каждого hop'а - быстрее, меньше шума на медленном DNS.

-r - report mode (без интерактива)

mtr -r -c 100 example.com > report.txt

Сделать 100 проб, вывести один раз и выйти. Удобно скрипту или в issue.

-c N - количество проб

По дефолту бесконечно (в интерактиве). С -c 10 сделает 10 раундов.

-T - TCP вместо ICMP

mtr -T -P 443 example.com

Многие firewall'ы блокируют ICMP, но пускают TCP. -T -P 443 шлёт TCP SYN на 443 - реалистичная картина для веб-трафика.

-u - UDP

mtr -u -P 53 example.com

По дефолту traceroute классический работал через UDP - mtr с -u делает то же.

-i N - интервал

mtr -i 0.5 example.com

Раз в 0.5 секунды - чаще проб. Для быстрого набора статистики.

-s N - размер пакета

mtr -s 1500 example.com

Шлём 1500-байтные пакеты (или больше) - проверка MTU и фрагментации.

JSON-вывод

mtr -j -r -c 10 example.com > mtr.json

Структурированный вывод. Удобно автоматическому мониторингу.

Что mtr не покажет

• Возвратный путь (asymmetric routing) - mtr видит только прямой. Loss может быть на обратной дороге. Запусти mtr с целевого хоста обратно к источнику для проверки.
• L7-проблемы - если приложение виснет на TCP-handshake'е, а не на pure latency, mtr этого не увидит.
• QoS / shaping - провайдер может приоритизировать ICMP отдельно от TCP. Тогда mtr -T -P 443 покажет другую картину.

Когда что-то пошло не так

• Loss с первого hop'а - проблема на твоей машине / её аплинке
• Loss с какого-то hop'а внутри ISP - жалобу сетевикам ISP, не починишь
• Loss только в обратку - mtr -T к целевому, потом mtr с целевого хоста сюда
• «Loss 100% на hop X, но всё работает» - просто фильтрация ICMP, не настоящая потеря
• mtr не запускается - root нужен для raw socket; либо setuid, либо setcap cap_net_raw+ep $(which mtr)

Альтернативы

• traceroute - классика, без realtime stats
• pathping - аналог mtr в Windows
• tcptraceroute - traceroute через TCP SYN
• nexttrace - современный, быстрый, JSON-output
• WhatsMyMTR - онлайн-сервис когда нет доступа к консоли