Трассировку довольно часто используют в рамках работ по диагностике сети. Такой инструмент как traceroute позволяет определить через какие узлы проходит пакет, который следует от вашего хоста до определённого IP-адреса. Эту довольно-таки простую команду логично применять, если необходимо проследить маршрут пакета. Если же нужно провести диагностику потерь пакетов, функционала traceroute будет не достаточно. Для таких целей полезно использовать более многогранный инструмент – My Traceroute (MTR).
Введение в MTR
Несмотря на то, что и My Traceroute, и traceroute умеют работать с разными типами трассировок, на практике, как правило, используются два их основных типа – ICMP и UDP.
В обоих случаях приложение, запускающее трассировку, отправляет пакеты таким образом, что каждый следующий пакет имеет TTL на один больше, чем у предыдущего. TTL (Time to Live) представляет собой число переходов от узла к узлу, которые может осуществить пакет прежде чем прекратить своё существование. Первый из отправляемых пакетов имеет TTL равный единице. То есть, на первом же маршрутизаторе такой пакет будет признан недействительным. Следующий пакет уже будет иметь TTL=2, и, соответственно, будет отклонён на маршрутизаторе номер два. Третий пакет, при TTL=3, закончит свой путь на третьем узле. И так далее. В итоге мы сможем построить список путей от исходного IP-адреса до конечного с использованием таймингов сообщений о превышении времени TTL.
Не все узлы будут отправлять сообщения о превышении времени TTL для ICMP, UDP или обоих сразу. Например, чтобы запустить трассировку с использованием протокола ICMP, необходимо набрать команду traceroute с ключом -I.
$ sudo traceroute -I 8.8.8.8
Для MTR использование протокола ICMP включено по умолчанию, поэтому дополнительных ключей вводить не нужно.
$ mtr 8.8.8.8
Вывод команды содержит следующую информацию:
- IP-адрес или имя хоста.
- Процент потерь пакетов на каждом из узлов.
- Число пакетов, отправленных на каждый из узлов.
- Время, затраченное на получение ответа.
- Отклонение времени с момента начала трассировки (среднее, лучшее, худшее, стандартное).
Если нужно, чтобы команда не производила преобразование IP-адреса в имя хоста, при запуске команды mtr используйте ключ -n.
$ mtr -n 8.8.8.8
Использование опции -b позволяет отображать как имена узлов, так и их IP-адреса.
$ mtr -b 8.8.8.8
Как уже упоминалось, по умолчанию MTR использует ICMP-запросы. Чтобы сделать трассировку при помощи UDP-датаграмм, применяется опция --udp.
$ mtr --udp 8.8.8.8Потери пакетов
На скриншоте ниже видно, что на пятом прыжке – выделяющийся на общем фоне высокий показатель потерь пакетов. На самом деле, это не является проблемой, так как потеря пакетов, либо увеличение времени приёма-передачи RTT (Round Trip Time) на каком-либо узле вполне ожидаемы. Вероятно, на данном узле происходит ограничение скорости, с которой он отправляет ICMP-запрос. Главное, что необходимо помнить, это – то, что такие потери не являются проблемой в случае, если они не наблюдаются на каждом узле до самого конца трассировки.
В свою очередь, показатель RTT – довольно полезная метрика. RTT сообщает нам о времени, которое потребовалось пакету, чтобы достигнуть определённого узла по сравнению с предыдущим. И опять же, если его увеличение не наблюдается на каждом прыжке до конечного узла, это не является проблемой.
Прямой и обратный путь
То, как отправленный пакет проходит от начального IP-адреса до конечного, далеко не всегда совпадает с тем, как тот же пакет возвращается обратно. Другими словами, когда вы запускаете ping на какой-либо IP-адрес, то весьма возможна ситуация, когда echo request пойдёт по иному пути нежели его ответ, то есть echo reply. Это значит, что при трассировке вы вполне можете наблюдать потерю пакетов на каком-то определённом узле, и это совершенно не обязательно тот самый узел, на котором существует проблема.
Допустим, вы запускаете трассировку от вашего IP-адреса до IP-адреса чьего-либо чужого хоста, и трассировка показывает большую потерю пакетов между конечным IP и провайдером, который находится перед ним. Казалось бы, проблема должна быть на хосте, куда вы запустили трассировку. Но это не совсем так. У конечного хоста может быть другой путь для отправки echo request из своей сети. Возможно, потери пакетов, которые вы наблюдаете, на самом деле являются потерями ответных пакетов. И теряются они уже после того, как отправлены с конечного IP. Уточнить это можно только отправив трассировку как с вашего IP-адреса, так и с конечного IP. По правде говоря, это далеко не всегда возможно, так как обычно цель трассировки – хост, к которому у вас нет доступа для отправки пакетов с его IP.
