Как читать traceroute: почему потери на 5-м хопе обычно ничего не значат

Сайт работает медленно, кто-то запускает traceroute - и вот оно: 40 процентов потерь на 5-м хопе. Похоже на ответ. На деле это почти никогда не ответ, а попытки на него реагировать отправляют людей охотиться за маршрутизатором, который работает безупречно.

Traceroute - действительно полезный инструмент, построенный на хитрости, и именно эта хитрость делает его вывод таким удобным для неверного прочтения.

Что traceroute делает на самом деле

Он отправляет пакеты с намеренно маленьким TTL. Первый маршрутизатор доводит его до нуля, сдаётся и присылает обратно ICMP-сообщение Time Exceeded. Именно из этого ответа вы и узнаёте, что маршрутизатор существует. TTL 2 даёт второй, и так далее, пока пакеты не дойдут до назначения.

То есть каждая строка, кроме последней, - это не измерение вашего трафика. Это измерение того, как быстро маршрутизатор решил сгенерировать сообщение об ошибке по поводу вашего трафика. Это разные вещи, и маршрутизаторы относятся к ним по-разному.

Почему средние хопы врут

Генерировать ICMP-ответы - не работа маршрутизатора. Пересылка пакетов выполняется аппаратно; ответ на исчерпанный TTL обрабатывает control plane, то есть заметно более слабый процессор с более важными делами. Большинство маршрутизаторов ограничивает скорость таких ответов, а некоторые отбрасывают их полностью.

В результате хоп показывает 40 процентов потерь, пропуская при этом 100 процентов трафика. Отсюда два правила, которые на месте закрывают большинство таких тикетов:

Потери, которые не продолжаются до конца, - это не потери. Если на 5-м хопе сорок процентов, а на хопах с 6-го по 12-й ноль, ничего не потерялось. Просто 5-й не захотел отвечать.
Значение имеет только последняя строка. Настоящие потери - это устойчивые потери на точке назначения. Именно эту цифру стоит эскалировать.

Хоп с высокой задержкой ведёт себя так же. Маршрутизатор, который медленно отвечает на собственный ICMP, не обязательно медленно пересылает.

Половина, которой вы не видите

Traceroute показывает путь туда. О пути обратно он не говорит ничего, а они часто разные: ваши пакеты могут уходить через одного транзитного оператора, а ответы возвращаться через другого. В интернете это нормально и неисправностью не является.

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

По той же причине исправление иногда лежит в сети, которая не ваша и не наша. Когда у нас есть собственная AS и BGP-сессии, изменить путь, которым трафик возвращается, - это то, что можно подправить со стороны аплинков, а не только объяснить.

Пользуйтесь mtr

mtr - это traceroute и ping вместе. Он отправляет пакеты постоянно, так что вы видите потери в процентах за время, а не догадки по трём пробам:

mtr -rwzbc 200 dcxv.com

-r режим отчёта, печатает один раз и выходит
-w широкий вывод, чтобы длинные имена не обрезались
-z показывает номер AS каждого хопа, то есть чья это сеть
-b показывает и имя хоста, и IP
-c 200 отправляет 200 проб, потому что 10 ничего не скажут о периодических потерях

В Windows ту же работу делает WinMTR. Дайте ему поработать пару минут, прежде чем делать выводы.

Что отправить в поддержку

Самое полезное, что можно приложить, - это mtr в обе стороны: один с вашей машины до сервера и один с сервера до вашего адреса, снятые одновременно. Эта пара превращает одностороннюю догадку в данные, которые можно свести к конкретной сети.

Приложите IP назначения, свой публичный адрес, время с часовым поясом и то, постоянная это проблема или появляется периодически. Если периодически - укажите когда. Потери с суточной периодичностью обычно означают перегрузку где-то по дороге, и знание часа быстро сужает поиск.

Что не помогает: скриншот одного traceroute с красным кружком вокруг среднего хопа. Это самое частое вложение и наименее пригодное к действию.

Итог

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

Облачные и выделенные серверы в Чехии и Португалии, в собственной сети AS204057: dcxv.com/data-center#cloud