MTR вместо traceroute: как читать колонки и не обвинить невиновный узел

MAATRIX

Запустили mtr, увидели строку с 40% в колонке Loss% где-то посередине трассы — и рука тянется написать в поддержку хостера, что у них «сеть сыпется». В девяти случаях из десяти это ложная тревога: цифра в колонке Loss% на промежуточном узле почти никогда не означает, что теряются именно ваши данные. Разберём по порядку, чем mtr отличается от traceroute, что означает каждая колонка в его выводе и по какому правилу отличать реальную проблему от диагностического шума.

Почему traceroute — это один снимок, а mtr — статистика за минуту

Traceroute шлёт по одному (или три, в зависимости от реализации) пакету на каждое значение TTL и один раз проходит по маршруту от вас до цели. Результат — снимок топологии в конкретную секунду: список хопов и разовая задержка на каждом. Временное дребезжание — всплеск потерь на одном узле, скачок задержки на другом — traceroute с высокой вероятностью просто не поймает или, наоборот, покажет случайный выброс, не отражающий типичную картину.

mtr (My TraceRoute, в некоторых дистрибутивах пакет называется mtr-tiny) решает эту проблему, объединяя логику traceroute и ping в одном инструменте. Он строит трассу так же, как traceroute — через постепенное увеличение TTL, — но затем не останавливается на одном проходе, а продолжает слать пробники на каждый хоп маршрута циклами, каждую секунду (по умолчанию), и накапливает статистику по каждому узлу: сколько пробников отправлено, сколько потеряно, какая у них была минимальная, средняя, максимальная задержка и насколько эта задержка стабильна.

# интерактивный режим — колонки обновляются в реальном времени,
# статистика накапливается, пока вы не нажмёте q
mtr 8.8.8.8

# то же самое, но без резолвинга DNS (быстрее и чище вывод)
mtr -n 8.8.8.8

Разница на практике: если на пятом хопе раз в 20 секунд теряется один пакет из-за перегрузки очереди, traceroute с вероятностью 95% этого не покажет вообще — он туда сходил один раз и ушёл дальше. mtr же за минуту работы отправит на этот хоп 50-60 пробников и покажет реальный процент потерь, а не случайное попадание или промах. Это главная причина, почему для диагностики почти всегда лучше mtr, а не разовый traceroute — особенно при жалобах на прерывистые (intermittent) проблемы, а не на полный обрыв связи.

Оба инструмента используют один и тот же трюк с TTL и видят один список промежуточных узлов. Но именно потому, что mtr держит опрос каждого хопа на протяжении всего замера, только он способен ответить на вопрос «эта потеря — разовая аномалия или системная проблема, которая повторяется прямо сейчас».

Разбор колонок mtr: что означает каждая цифра

Стандартный вывод mtr в широком формате (-w, без урезания длинных имён) выглядит так:

                                     Packets               Pings
Host                               Loss%   Snt   Last   Avg  Best  Wrst StDev
1. 192.168.1.1                      0.0%   120    0.4   0.5   0.3   1.9   0.2
2. 100.64.0.1                       0.0%   120    2.1   2.4   1.9   6.7   0.6
3. core1.transit.example.net       32.0%   120    -    11.2  10.8  12.1   0.3
4. core2.transit.example.net        0.0%   120   11.9  12.1  11.0  15.4   0.5
5. edge.hoster.example.net          0.0%   120   13.0  13.4  12.6  18.9   0.7
6. target.example.com               0.0%   120   14.1  14.6  13.8  22.0   1.1

Разберём каждую колонку отдельно, потому что путаница чаще всего начинается именно с непонимания, что каждая из них считает:

Частая ошибка новичков — судить о качестве связи только по Avg, игнорируя Best и StDev. Best показывает предел, к которому стремится задержка при отсутствии очередей на маршруте, а разница между Best и Wrst вместе со StDev показывает, насколько нестабилен путь. Если Best и Avg почти совпадают, а Wrst сильно выше — это разовые всплески, не постоянная деградация. Если же Avg заметно выше Best и StDev большой — узел (или канал перед ним) регулярно испытывает очереди, и это стоит воспринимать всерьёз даже без явных потерь в Loss%.

Главное правило: Loss% на промежуточном хопе — это почти никогда не потеря ваших данных

Вот ключевая вещь, из-за которой этой статье вообще стоило появиться. ICMP-ответ Time Exceeded, который генерирует промежуточный роутер в ответ на пробник traceroute/mtr, — это не тот же трафик, который роутер обычно пересылает. Обычная пересылка пакета — операция форвардинга на скорости линии, которую выполняет выделенный сетевой процессор (ASIC/линейная карта). А генерация диагностического ICMP-ответа — операция control plane, которая на многих магистральных маршрутизаторах идёт через куда более медленный общий процессор с ограниченной пропускной способностью.

Чтобы шквал traceroute- и mtr-запросов от миллионов пользователей интернета не положил управляющий процессор дорогого магистрального маршрутизатора, операторы сетей намеренно ограничивают скорость генерации таких служебных ответов (ICMP rate limiting). Итог для вас на экране: роутер, который прекрасно и без единой потери пересылает ваш реальный TCP/UDP-трафик дальше по маршруту, при этом честно показывает 30%, 50%, а иногда и 100% Loss% в колонке mtr — просто потому что не успевает (или ему не разрешено) генерировать ICMP-ответы на каждый ваш диагностический пробник.

Отсюда практическое правило, которое стоит держать перед глазами при каждом чтении mtr:

Доверяйте Loss% буквально только на последней строке трассы — на самой цели. Именно там нет промежуточного оператора, который экономит ресурсы на диагностике: конечный хост либо отвечает на ваш пробник, либо реально его не получил (или ответ реально потерялся на обратном пути). Если последняя строка показывает 0.0% (или близко к нулю) и приложение работает нормально — можно закрывать mtr и не тратить время на страшные цифры в середине трассы, какими бы пугающими они ни выглядели.

Признаки, что Loss% на промежуточном хопе — это именно диагностический шум, а не реальная проблема:

• потери есть на одном-двух промежуточных хопах, а на всех хопах после них потери отсутствуют или минимальны;
• уровень потерь стабилен от запуска к запуску (например, всегда около 20-30%), а не растёт со временем;
• задержка (Avg) на этом хопе не выбивается из общей картины маршрута;
• последняя строка (цель) показывает Loss% около нуля.

Если все четыре пункта совпадают — это тот самый случай ICMP rate limiting, и писать в поддержку транзитного оператора не о чем: он ничего не нарушает, это штатное поведение большинства магистральных сетей.

Когда Loss% на промежуточных хопах всё-таки стоит учитывать

Правило «верить только последней строке» не значит, что промежуточные хопы вообще бесполезны — они играют роль, но только после того, как вы убедились, что потеря реальна, то есть присутствует и на последней строке тоже. В этом случае промежуточные хопы служат не доказательством проблемы, а инструментом её локализации.

Ключевой признак реальной, а не диагностической потери — накопление: если хоп №5 показывает 20% Loss%, а хоп №6 и все последующие вплоть до цели показывают столько же или больше — это уже не локальный ICMP rate limit одного узла, а трафик, который действительно теряется на этом участке и «тащит» потерю дальше. Сравните с ситуацией, где хоп №5 показывает 40%, а хоп №6 сразу возвращается к 0% — верный признак, что хоп №5 просто экономит на ICMP, а транзитный трафик проходит через него без проблем.

Практическая последовательность при подозрении на реальную потерю:

1. Смотрим на последнюю строку. Есть там Loss% выше единиц процента (для стабильного проводного соединения — выше долей процента) — значит, проблема реальна, идём дальше.
2. Ищем первый хоп, начиная с которого Loss% появляется и не исчезает на всех последующих хопах до самой цели.
3. Тот хоп (точнее, участок между ним и предыдущим, отвечавшим без потерь) — кандидат на источник проблемы.
4. Смотрим на StDev и Wrst вокруг этого хопа — если задержка там же резко и нестабильно растёт, это дополнительное подтверждение реальной перегрузки канала, а не диагностической аномалии.

Подробный разбор того, как делить маршрут на зоны ответственности — своя сеть, транзит, сторона сервера — и куда с этими данными обращаться, есть в статье про локализацию участка потерь пакетов. А если картина показывает, что трасса вообще идёт не туда, куда подсказывает карта — крюком через соседнюю страну при близком пункте назначения, — это отдельная тема, разобранная в статье о том, почему маршрут не совпадает с географией; сама по себе такая топология не проблема и не повод паниковать по Loss%.

StDev и джиттер: нестабильность задержки отдельно от потерь

Отдельный вопрос — задержка, а не потери. Даже если Loss% на всех хопах ноль, растущий StDev (или большая разница между Best и Wrst) на конкретном узле говорит о нестабильности: пакеты долетают, но время в пути скачет. Для обычного веб-серфинга это малозаметно, но для голосовых звонков, видеоконференций и онлайн-игр именно нестабильность задержки (джиттер), а не средняя цифра пинга, определяет субъективное качество связи.

Практический ориентир: если StDev на каком-то хопе резко вырастает по сравнению с соседними и держится большим на всех последующих — вероятная причина, очередь на исходящем интерфейсе, переполняющаяся в моменты пиковой нагрузки. Единичный скачок Wrst при низком StDev, наоборот, почти всегда разовый выброс и не говорит о системной проблеме.

Не выдумывайте точных числовых порогов «нормального» StDev или Avg для конкретного направления — они сильно зависят от расстояния, числа хопов и загрузки сети. Сравнивайте с собственной историей замеров того же направления, а не с абстрактным «эталоном».

Как правильно запускать mtr: права, режимы, флаги

mtr в режиме ICMP или UDP (по умолчанию на Linux/macOS часто используется ICMP) должен создавать сырые сетевые сокеты, а это на большинстве систем требует повышенных прав:

# Linux/macOS — обычный запуск с sudo
sudo mtr 8.8.8.8

# альтернатива без sudo на каждый запуск (Linux):
# выдать бинарнику capability на создание raw-сокетов один раз
sudo setcap cap_net_raw+ep $(which mtr)
mtr 8.8.8.8   # дальше можно запускать без sudo

Если ICMP на пути режется файрволом (частая ситуация с корпоративными сетями и некоторыми облачными провайдерами), переключитесь на TCP SYN до конкретного порта — так пробники будут больше похожи на реальный трафик приложения:

sudo mtr -T -P 443 example.com

Для скриптов, логирования и вставки в тикет поддержки интерактивный режим неудобен — нужен неинтерактивный отчёт фиксированной длины:

# -r — report-режим (вывести финальный отчёт и выйти)
# -w — широкий формат (не обрезать длинные имена хостов)
# -c N — число циклов (пробников на каждый хоп)
mtr -rwc 100 8.8.8.8 > mtr-report.txt

# без резолвинга DNS (быстрее, если резолвинг подвисает на промежуточных IP)
mtr -rwnc 100 8.8.8.8

# JSON для автоматической обработки, например в мониторинге
mtr -rc 100 --json 8.8.8.8 > mtr-report.json

Для ловли редких, эпизодических потерь 100 циклов может быть мало — это снимок примерно за 100 секунд при интервале по умолчанию. Если проблема проявляется раз в 10-15 минут, увеличивайте -c до 500-1000 или запускайте mtr в цикле, сохраняя каждый отчёт в отдельный файл с меткой времени.

На Windows штатного mtr нет — ближайший аналог по логике это pathping (строит маршрут как tracert, затем опрашивает каждый хоп около 25 секунд) либо сторонний графический WinMTR:

pathping -n 8.8.8.8

Оба подвержены той же особенности: Loss% на промежуточных узлах может быть результатом ICMP rate limiting, и правило «доверяем только последней строке» применимо к ним в равной мере.

Отдельно про VPN: если тестируете mtr через туннель, число хопов и распределение задержки закономерно изменится — трасса сначала уйдёт до VPN-сервера, а уже потом от него до цели. Подробности разобраны в статье про traceroute и ping через VPN.

Частые вопросы