MTR и traceroute — два самых быстрых инструмента, когда «всё тормозит», соединение рвётся, в логах появляются таймауты, а мониторинг рисует непонятные latency spikes. На практике половина диагностики — не запуск команды, а правильная интерпретация: где реальный packet loss, где ограничения ICMP (icmp rate limit), почему прыгает jitter и как заметить asymmetric routing.
Ниже — пошаговый разбор: как запускать mtr и traceroute, какие режимы выбирать, какие поля важны, как отличать проблемы транзитного маршрутизатора от реальной деградации до конечной точки и что делать, когда «потери» видны только на одном из промежуточных hop’ов.
Что измеряют mtr и traceroute и чем они отличаются
traceroute (или tracert в Windows) строит путь до цели, увеличивая TTL и получая ответы от промежуточных узлов. Это «снимок маршрута», обычно 3 пробы на hop. Удобно для первичной карты сети и проверки, куда вообще уходит трафик.
mtr объединяет traceroute и ping: он не только показывает hops, но и непрерывно собирает статистику по задержке и потерям на каждом участке. Это особенно полезно, когда проблема плавающая: кратковременные spikes, микропотери, «дёрганье» RTT.
Если упростить:
- Нужно понять «какой маршрут?» — достаточно traceroute.
- Нужно поймать деградацию и увидеть статистику (loss/jitter/spikes) — почти всегда mtr.
Термины, которые важно различать
Latency (RTT) — время «туда-обратно». В mtr это обычно Last/Avg/Best/Wrst.
Jitter — вариативность задержки, то есть насколько сильно «гуляет» RTT от пакета к пакету. В mtr отдельного столбца jitter часто нет (зависит от сборки/ключей), но его можно прикинуть по разнице Wrst и Best и по нестабильности Last.
Packet loss — доля потерянных ответов на пробы. В mtr это Loss%. Важный нюанс: это потеря ответов на ICMP/UDP/TCP-пробы, а не обязательно потеря вашего прикладного трафика.
Latency spikes — редкие всплески RTT (например, раз в 30–60 секунд). В mtr проявляются большим Wrst при относительно нормальном Avg.
Asymmetric routing — асимметричная маршрутизация: путь «туда» и «обратно» различается. Из-за этого вы можете видеть «плохой» hop в одном направлении и не видеть его в другом, а также получать противоречивые результаты из разных точек.
ICMP rate limit — ограничение частоты ответов на ICMP (и иногда на TTL-expired). Это частая причина «ложного» loss на промежуточных hop’ах.
Как правильно запускать mtr: режимы и ключи
Самая частая ошибка — запускать mtr «как есть», посмотреть 5 секунд и делать выводы. Для плавающих проблем нужно время, достаточное число проб и правильный тип пробного трафика.
Linux: базовые варианты
Интерактивный режим удобен «вживую», но для тикета или сравнения лучше отчётный:
mtr example.commtr -r -w -c 200 example.comЧто важно в этих ключах:
-r— report (печатает итоговую таблицу и выходит);-w— wide (не режет колонки);-c 200— число проб. 200 — хороший минимум, при редких spikes ставьте 500–1000.
ICMP, UDP или TCP: почему это критично
По умолчанию mtr часто использует ICMP Echo. Но ваша проблема может проявляться только на TCP/443 (фильтрация ICMP, иной приоритет, особенности NAT, политики провайдера). Поэтому полезно прогонять минимум два режима и сравнивать.
ICMP:
mtr -r -w -c 200 -I example.comUDP (ближе к классическому traceroute, но зависит от фаерволов):
mtr -r -w -c 200 -u example.comTCP SYN на порт 443 (часто самый практичный режим для веба):
mtr -r -w -c 200 -T -P 443 example.comЕсли ICMP показывает «потери», а TCP — чисто, сервис может работать нормально: сеть нередко ограничивает ICMP или обрабатывает его с низким приоритетом.
Частота проб и «как не навредить»
Не нужно ставить экстремальные интервалы и «душить» маршрут сотнями пакетов в секунду: вы упрётесь в icmp rate limit на промежуточных устройствах и получите ложные «потери». Лучше дольше, но спокойнее. Если нужно управлять интервалом, в разных реализациях mtr используются разные ключи — проверьте вашу версию:
mtr --helpTraceroute: когда он полезнее mtr
Traceroute хорош, когда нужно быстро:
- понять, через какие сети идёт маршрут (например, внезапно пошёл «в другую сторону»);
- сравнить маршруты из разных локаций;
- поймать очевидную проблему на конкретном hop (например, резкий +80 мс на одном переходе и дальше так же).
Классический запуск в Linux (UDP):
traceroute example.comICMP-режим (часто лучше проходит через фильтры):
traceroute -I example.comTCP на 443 (как «почти реальный» веб-трафик):
traceroute -T -p 443 example.comWindows:
tracert example.compathping example.compathping в Windows — это упрощённая смесь traceroute и статистики потерь, иногда полезна как «быстрый mtr без установки».
Как читать отчёт mtr: быстрый алгоритм
Типичный отчёт mtr — таблица hops с колонками Loss%, Snt, Last, Avg, Best, Wrst, иногда StDev. Читаем сверху вниз, но выводы делаем по «хвосту»: важнее всего то, что происходит на последних строках.
Правило №1: важнее всего последний hop
Если loss есть на промежуточном hop’е, но на последующих hop’ах его нет, то чаще всего это:
- icmp rate limit (маршрутизатор ограничивает ответы на диагностические пакеты);
- низкий приоритет ICMP на control plane (CPU занят, ICMP «подрезается», а транзитный трафик идёт аппаратно);
- фильтрация или политики безопасности на конкретном узле.
В этом случае «красивые 30% потерь» на hop 5 не означают, что у вас 30% потерь до сервиса.
Правило №2: реальная потеря проявляется «ниже по цепочке»
Если loss начинается на каком-то hop и сохраняется на всех последующих, включая последний — это уже похоже на реальную деградацию (или на уровне линка, или из-за перегруза и очередей).
Пример логики интерпретации:
- Hop 3: 0%
- Hop 4: 5%
- Hop 5: 5%
- Последний hop: 5%
Это выглядит как потеря, появившаяся начиная с hop 4 (или на линке между 3 и 4).
Правило №3: spikes ищите по Wrst и по «ступеньке» RTT
Latency spikes в mtr обычно заметны так:
Avgумеренный, ноWrstв разы выше (например, Avg 18 ms, Wrst 220 ms).Lastпериодически «улетает», хотя в остальное время близок кBest.
Если при этом Loss% близок к нулю, возможные причины:
- очереди и буферизация на участке (перегруз, shaping, bufferbloat);
- микровсплески нагрузки на CPU/IRQ на одном из узлов;
- Wi-Fi или «последняя миля» (если измеряете от клиента);
- перекладка маршрутов (реже, но бывает).
Как оценить jitter по данным mtr
Практичный подход без «идеальной математики»:
- Если
BestиAvgрядом, аWrstчуть больше — jitter низкий. - Если
Wrstкратно вышеAvg— есть jitter/spikes, даже если среднее «красивое». - Если в вашей сборке есть
StDev, ростStDevна конкретном hop часто хорошо коррелирует с jitter.
Если вам нужна независимая точка измерения в другом регионе или у другого провайдера, удобно держать небольшой тестовый VDS и периодически снимать mtr/traceroute «снаружи».
Классические ловушки: ICMP rate limit и «потери» в середине маршрута
Самая популярная ситуация: mtr показывает 20–60% loss на каком-то промежуточном hop’е, но конечный hop — 0%. Это почти учебник по icmp rate limit.
Почему так происходит:
- Маршрутизатор обязан форвардить транзитный трафик быстро, часто аппаратно (ASIC).
- А вот отвечать на TTL-expired или echo-reply — это control plane, нередко на CPU.
- Чтобы не превращаться в «усилитель» диагностического трафика, устройства лимитируют ICMP-ответы.
Промежуточный hop может «терять» ответы на диагностику и при этом идеально пропускать транзит. Смотрите на последнюю строку и на распространение loss «вниз по таблице».
Как проверить, что это именно rate limit
- Сравните ICMP и TCP (
mtr -Iпротивmtr -T -P 443). - Увеличьте число проб (
-c) и не делайте тест слишком агрессивным по частоте. - Проверьте, распространяется ли loss на следующие hops и на последний.
Asymmetric routing: почему результаты «из разных мест» не сходятся
Asymmetric routing — нормальная реальность интернета: особенно между разными аплинками, точками обмена трафиком и при BGP-политиках. Для диагностики это означает две вещи:
- mtr измеряет путь «туда» (по TTL), но RTT зависит и от пути «обратно».
- Проблема может быть на обратном пути, и тогда mtr не покажет «виновника» красивой ступенькой на конкретном hop.
Признаки асимметрии в полевых условиях:
- Из одной точки всё плохо, из другой (другой провайдер или другой регион) — нормально.
- Traceroute до вас (если вы попросили клиента или коллегу) идёт по другому пути, чем вы видите до клиента.
- Задержка высокая, но «ступеньки» в mtr нет, или она появляется только ближе к концу.
Что делать:
- Снимать mtr с двух сторон (клиент → сервер и сервер → клиент).
- Если есть несколько точек мониторинга (например, отдельные машины в регионах), сравнить трассы.
- Для TCP-сценариев проверять на портах сервиса (443/22/5432), потому что маршрутизация и фильтры могут отличаться по протоколам.
Про практические нюансы туннелей и диагностики «между площадками» может пригодиться отдельный разбор: WireGuard site-to-site на VDS: настройка и диагностика.
Практический runbook: как собирать данные для обращения к провайдеру или внутрь команды
Чтобы диагностика была воспроизводимой, соберите минимальный пакет фактов. Обычно достаточно 10–15 минут, если проблема прямо сейчас воспроизводится.
1) Зафиксируйте цель и протокол
Запишите: домен, IPv4 или IPv6, порт (если TCP), время и часовой пояс. Для веба почти всегда полезно TCP/443, для SSH — TCP/22.
Если инцидент про IPv6 (а с IPv6 часто всплывает «асимметрия» и неожиданные маршруты), полезно свериться с базовыми механизмами адресации и маршрутизации: SLAAC vs DHCPv6 и маршрутизация IPv6.
2) Снимите mtr в двух режимах
mtr -r -w -c 300 -I example.commtr -r -w -c 300 -T -P 443 example.comЕсли проблема редкая — увеличьте -c до 800–1000 и запускайте в момент деградации.
3) Снимите traceroute как «карту маршрута»
traceroute -T -p 443 example.comЭто удобно, когда mtr «шумный», а вам нужно быстро показать маршрут. Даже без AS-номеров часто по rDNS видно, где начинается чужая сеть или конкретный аплинк.
4) Интерпретируйте по трём вопросам
- Есть ли loss на последнем hop? Если нет — очень осторожно с выводами о «потерях».
- Где появилась «ступенька» RTT и сохраняется ли она дальше?
- Есть ли spikes (большой
Wrst) и совпадает ли это по времени с жалобой приложения?
Если деградация связана с TLS (ошибки рукопожатия, странные таймауты на 443, жалобы браузеров), полезно проверить цепочки и срок действия сертификата и заранее перевыпускать его. Для продакшена удобнее держать нормальные коммерческие SSL-сертификаты с предсказуемой поддержкой и совместимостью.
Типовые сценарии и что они обычно означают
Сценарий A: loss на одном hop, дальше чисто
Почти всегда icmp rate limit или низкий приоритет ICMP. Проверяйте TCP mtr. Если TCP чистый и приложение не жалуется — это, скорее всего, не инцидент.
Сценарий B: loss начинается с hop N и тянется до конца
Похоже на реальную потерю. Частые причины: перегруз канала или очередей на участке, проблемы линка, ошибки на порту, дропы на «последней миле». Дальше нужны метрики интерфейса на вашей стороне (если это ваш роутер или сервер) и эскалация провайдеру с приложенными mtr.
Сценарий C: loss нет, но Wrst огромный (spikes), приложение иногда «подвисает»
Это классика jitter/spikes. Варианты проверки:
- Снимите mtr дольше (1000 проб), чтобы понять частоту и «рисунок» проблемы.
- Сравните ICMP и TCP: бывает, что spikes видны только на ICMP.
- Если измеряете от сервера: проверьте локальную нагрузку, softirq, очереди, возможный shaping.
Сценарий D: из одной сети всё плохо, из другой хорошо
Очень похоже на asymmetric routing или проблему конкретного транзита или пира. Здесь решают количество точек измерения и трассы с обеих сторон.
Вывод: как быстро получить «правильный» ответ
MTR и traceroute — не про «волшебную кнопку», а про дисциплину: выбрать правильный протокол, собрать достаточно проб и интерпретировать результаты по последнему hop и распространению симптомов вниз по маршруту. Если держать в голове icmp rate limit, природу jitter и реальность asymmetric routing, то даже простые команды дадут точную картину: это проблема вашей сети, транзита или конечного сервиса.
А дальше уже проще: либо вы локально устраняете узкое место, либо приходите к провайдеру с данными, где видно конкретный участок и характер деградации (loss или latency spikes), без ложных обвинений «виноват hop №5».
