Matt’s Traceroute (MTR) — это мощный кроссплатформенный инструмент сетевой диагностики, сочетающий в себе функции ping и traceroute. MTR — это эволюция traceroute, которая отображает подробную информацию, определяя маршрут пакета к узлу назначения. Отчет о пути содержит процент отклика и время отклика для всех переходов между исходным компьютером и целевым компьютером.
В статье подробно описывается работа MTR, приводятся некоторые примеры командной строки и объясняются данные, которые он генерирует. В конце концов, по выходным данным мы проводим анализ отчета.
Как работает MTR?
Инструменты сетевой диагностики, такие как ping, traceroute и MTR, проверяют соединение между двумя устройствами с помощью пакетов ICMP для устранения неполадок сетевого подключения. В то время как утилита ping использует ICMP echo_request и echo_replies, в отличие от этого, traceroute и MTR используют пакеты ICMP с TTL времени жизни.
Для анализа переходов сначала MTR устанавливает адреса коммутаторов, шлюзов и маршрутизаторов между локальными и удаленными устройствами. Затем он использует пакеты ICMP с TTL для проверки связи каждого перехода, так что TTL контролирует узлы, которые пакет достигнет перед смертью. Следовательно, он отправляет серию ICMP echo_request с TTL, установленным на один, два, три и так далее, пока MTR не соберет весь маршрут.
Вышеупомянутый процесс выводит статистику, которая содержит дополнительную информацию, такую как состояние перехода, сетевое соединение, скорость реакции узла, задержка сети и дрожание. Что самое интересное, она похожа на команду top, поскольку она постоянно обновляется с подключением к сети в реальном времени.
Установка MTR
По умолчанию инструмент находится в каталоге / user / sbin, поскольку он предустановлен в большинстве дистрибутивов. Если он недоступен, установите MTR с помощью стандартного диспетчера пакетов дистрибутива.
Для Ubuntu:
ubuntu@ubuntu:~$ sudo apt-get -y install mtr
Для RHEL:
ubuntu@ubuntu:~$ sudo yum -y install mtr
Для Arch:
ubuntu@ubuntu:~$ sudo pacman -y install mtr
Создание и чтение отчетов MTR в реальном времени
Как показано на снимках экрана выше, помимо перечисления сетевых переходов, MTR также отслеживает задержку. Другими словами, он также оценивает время приема-передачи от локального компьютера к каждому устройству на пути.
Чтобы лучше понять, используйте флаг —report для создания отчета, содержащего статистические данные о качестве сети. Пользователи также могут использовать это с параметром -c, так как он будет работать только в течение указанного им количества циклов и завершится после печати статистики.
ubuntu@ubuntu:~$ sudo mtr -r -c 5 google.com
На предыдущем снимке экрана выводится несколько полей / столбцов для доступа к сетевому трафику. Эти столбцы содержат следующую статистику:
- % Loss: процент потери пакетов на каждой машине
- Snt: количество отправленных пакетов
- Last: время приема-передачи для последнего пакета traceroute.
- Avg: среднее время приема-передачи для всех зондов.
- Best: наименьшее время прохождения пакета до определенного хоста туда и обратно.
- Wrst: наибольшее время прохождения пакета до хоста туда и обратно.
- StDev: стандартное отклонение задержек
В Snt к WRST столбцов измерения латентности в миллисекундах, но только Avg столбец имеет значение больше всего. Единственным недостатком создания отчетов о качестве сети является то, что он использует большой сетевой трафик, что снижает производительность сети.
Полезные опции
В следующем разделе приведены некоторые из наиболее полезных примеров команд MTR flags. Мы объясним детали вывода в разделе «Чтение отчетов MTR» позже.
IPv6: MTR использует IPv6 в качестве опции по умолчанию, что требует включения IP-адреса или доменного имени хоста назначения в качестве аргумента. Он будет отображать вывод в реальном времени, нажмите Ctrl + C или q для выхода:
ubuntu@ubuntu:~$ sudo mtr google.com
или
ubuntu@ubuntu:~$ sudo mtr 8.8.8.8
Только IPv4: переключатель IPv4 (-4) отображает только адреса IPv4 и включает полные доменные имена:
ubuntu@ubuntu:~$ sudo mtr -4 google.com
b: чтобы отобразить и доменные имена, и адреса IPv4, используйте флаг -b следующим образом:
ubuntu@ubuntu:~$ sudo mtr -b google.com
c: Как обсуждалось ранее, флаг ограничивает количество эхо-запросов, отправляемых на каждую машину. После завершения количества эхо-запросов он останавливает обновление в реальном времени и вскоре после этого выходит из MTR:
ubuntu@ubuntu:~$ sudo mtr -c7 google.com
T / u: заменить эхо-пакеты ICMP на датаграммы TCP SYN -T / —tcp или UDP -u / —udp:
ubuntu@ubuntu:~$ sudo mtr —tcp google.com
или
ubuntu@ubuntu:~$ sudo mtr —udp google.com
o: расположите поле вывода в соответствии с вашими требованиями. Например, данная команда отображает вывод следующим образом:
ubuntu@ubuntu:~$ mtr -o «LSDR NBAW JMXI» 8.8.8.8
m: укажите переходы между локальным хостом и удаленным компьютером. В следующих примерах устанавливается значение 5 переходов, а значение по умолчанию — 30:
ubuntu@ubuntu:~$ mtr -m 5 8.8.8.8
s: Проверить сеть, указав размер пакета ICMP, включая заголовки IP / ICMP в байтах:
ubuntu@ubuntu:~$ mtr -s PACKETSIZE -c 5 google.com
Отчет об анализе
Анализ выходного отчета MTR в основном состоит или сосредоточен на потере пакетов и задержке в сети. Давайте подробно обсудим каждый из них:
Потеря пакетов
Отчет MTR генерирует процентное значение поля потери пакетов на каждом шаге, чтобы указать на проблему. Однако провайдеры услуг имеют обычную практику пакетов MTR ICMP с ограничением скорости, что создает иллюзию потери пакетов, что не соответствует действительности. Чтобы определить, действительно ли потеря пакета связана с ограничением скорости, обратите внимание на потерю пакета на последующем переходе. Как и на скриншоте выше, для примера флага — o мы наблюдаем потерю пакетов в размере 16,7% на переходах 5 и 6. Если на следующем устройстве нет потери пакетов, то это происходит из-за ограничения скорости.
В другом сценарии, если отчеты представляют разные суммы потерь на начальных последующих переходах, а несколько более поздних устройств показывают одинаковый процент потери пакетов, тогда потеря на начальных машинах происходит из-за обоих факторов: ограничения скорости и фактических потерь. Следовательно, когда MTR сообщает о разных потерях пакетов на разных переходах, доверяйте потере на более поздних переходах.
Задержка в сети
Задержка сети увеличивается с увеличением количества переходов между двумя конечными точками. Однако задержка также зависит от качества сетевого соединения между локальной и удаленной машинами. Например, коммутируемые соединения показывают большую задержку, чем кабельные модемы.
Также важно отметить, что задержка в сети не означает неэффективный маршрут. Независимо от высокой задержки сети на различных узлах, пакеты могут достигать пункта назначения и возвращаться к источнику с нулевыми потерями.
В приведенном выше примере мы наблюдаем скачок задержки с 8-го перехода и далее. Но ни один пакет не был потерян, кроме как на узле назначения.
Заключение
Понимание основ MTR необходимо для выявления и выяснения наиболее распространенных проблем с подключением к сети, таких как неправильная конфигурация ISP / домашнего маршрутизатора и целевой сети хоста, тайм-ауты и ограничение скорости ICMP. Статья дает новичку возможность понять использование и работу MTR. В нем также показано, как создавать отчеты MTR и выполнять анализ для выявления проблем потери пакетов, связанных с ограничением скорости, и анализа задержки в сети.
