Что такое отчет MTR и чем он полезен

MTR — это инструмент, благодаря которому администраторы имеют возможность диагностировать и иcправить ошибки Сети, а также формировать отчеты о состоянии сети.

MTR — эволюция команды traceroute, но с более подробной выборкой данных, как если бы она дополнялась выводом команды ping. Этот туториал предоставляет обзор MTR, разбор генерируемых ним данных и выводы на их основе.

Возможности сетевой диагностики

Инструменты диагностики сети для проверки трафика между двумя точками в Интернете используют пакеты протокола управляющих сообщений Интернета (ICMP). Когда пользователь выполняет эхо-запрос к узлу в Интернете, узлу отправляется серия пакетов ICMP, который отвечает, отправляя ответные пакеты. Затем клиент может вычислить время прохождения туда и обратно между двумя точками в Интернете.

Такие же инструменты, как traceroute и MTR, отправляют ICMP-пакеты с постепенно увеличивающимся TTL, чтобы посмотреть маршрут или серию переходов, которые пакет делает между источником и местом назначения. TTL (время жизни) контролирует, сколько прыжков сделает пакет, прежде чем вернется к хосту. Отправляя серию пакетов и заставляя их возвращаться после одного перехода, затем двух, затем трех, MTR может составить маршрут, по которому трафик проходит между узлами в Интернете. MTR собирает информацию о состоянии, подключении и быстродействии промежуточных узлов.

Далее мы расскажем, как установить программное обеспечение MTR и как прочесть полученные результаты.

Установить MTR

Linux

Debian/Ubuntu

apt update && apt upgrade
apt install mtr-tiny

CentOS/RHEL/Fedora

yum update
yum install mtr

Windows

Для Windows существует порт MTR под названием «WinMTR». Вы можете загрузить это приложение из апстрима WinMTR.

macOS

Установите MTR на macOS с помощью Homebrew или MacPorts. Чтобы установить MTR с Homebrew, запустите:

brew install mtr

Чтобы установить MTR с MacPorts, запустите:

port install mtr

Создать отчет MTR

Маршрут между двумя точками в Интернете может сильно различаться в зависимости от местоположения и настроек маршрутизаторов. Рекомендуем собирать отчеты MTR в обоих направлениях для всех узлов, испытывающих проблемы с подключением.
Хост, на котором запущен mtr, называется исходным хостом, а хост, на который направлен запрос, — хостом назначения.

Использование MTR для систем на основе Unix

Для создания MTR-отчетов, используйте:

mtr -rw [целевой хост]

То есть, если нужно проверить маршрут и качество подключения трафика к хосту назначения пример.com:

mtr -rw пример.com

Отчет MTR может быть запущен с вашего локального компьютера. Замените 185.67.0.0 IP-адресом вашего сервера:

mtr -rw 185.67.0.0

Подключитесь по SSH и соберите отчет MTR к вашей домашней сети. Замените 198.51.100.0 IP-адресом вашей домашней сети.

mtr -rw 198.51.100.0

Если вы не знаете свой домашний IP-адрес, используйте https://2ip.ua/ru/

Если потеря пакетов не обнаружена, можно выполнить интервал быстрее:

mtr -rwc 50 -rw 198.51.100.0

Если вы работаете в системе не из-под главного пользователя (root), то для использования этого флага могут потребоваться права суперпользователя:

sudo mtr -rwc 50 -rw 198.51.100.0

Примечание

Флаг опции r генерирует отчет (сокращение от —report).

Флаг опции w использует длинную версию имени хоста, чтобы увидеть полное имя хоста каждого прыжка (сокращение от —report-wide).

Флаг опции c устанавливает, сколько пакетов отправлено и записано в отчете. По умолчанию 10, но вы можете установить его на 50 или 100. При этом формирование отчета займет больше времени.

Используйте MTR в системах Windows

При запуске MTR в Windows используется графический интерфейс. Откройте WinMTR, введите целевой хост в поле при появлении запроса и выберите опцию запуска, чтобы начать создание данных отчета.

Чтение отчетов MTR

Вот пример отчета о локальном подключении к google.com:

$ mtr --report google.com
HOST: our.machine             Loss% Snt Last Avg Best Wrst StDev
1. inner-interface            0.0%  10  0.7  0.9  0.7  1.1  0.1
2. outer-interface            0.0%  10  1.4  1.3  1.0  1.7  0.2
3. provider.hop.net           0.0%  10  0.7  1.1  0.6  3.2  0.8
4. another.hop.net            0.0%  10  5.3  1.4  0.8  5.3  1.4
5. one.more.hop.net           0.0%  10  1.3  4.6  1.0  18.7  6.6
6. and.more.hop.net           0.0%  10  14.5  14.6 14.5 15.1 0.2
7. new.hop.net                0.0%  10  15.4  15.7 15.2 18.2 0.9
8. new2.hop.net               0.0%  10  15.7  15.5 14.9 17.9 0.8
9. finishing.distance.hop.net 0.0%  10  14.6  14.6 14.3 15.3 0.3
10. almost.finish.hop.net     0.0%  10  15.2  15.3 15.1 15.6 0.2
11. pre.final.hop.net.        0.0%  10  14.6  14.5 14.3 14.9 0.2
12. final.hop.net.            0.0%  10  15.0  14.7 14.4 15.7 0.4

Отчет был создан с помощью mtr —report google.com. . При этом используется параметр отчета, который отправляет 10 пакетов на хост google.com. Без опции —report mtr будет работать непрерывно в интерактивной среде. В большинстве случаев режим. —report предоставляет достаточно данных в удобном формате.

Пронумерованные строки в отчете — это прыжок (хоп). Хопы — это узлы Интернета, через которые проходят пакеты, по пути до места назначения.

Имена хостов определяются обратным поиском в DNS. Чтобы исключить отображение ptr-записей вместо IP-адресов, используйте параметр —no-dns:

% mtr --no-dns --report google.com
HOST: our.machine     Loss% Snt Last Avg Best Wrst StDev
1. 192.168.1.1        0.0%  10  2.2  2.2  2.0  2.7  0.2
2. 66.55.151.209      0.0%  10  0.8  0.7  0.5  0.8  0.0
3. 10.64.18.65        0.0%  10  3.3  2.0  1.0  7.7  2.1
4. 10.64.4.25         0.0%  10  1.4  2.2  1.2  8.7  2.2
5. 72.14.214.16.      0.0%  10  1.4  1.5  1.3  1.7  0.0
6. 108.170.248.33     0.0%  10  2.6  2.8  2.6  3.4  0.0
7. 142.250.46.191     0.0%  10  11.5  3.7  2.0  11.5 3.0
8. 142.250.64.110     0.0%  10  1.5  1.5  1.4  1.7  0.0

Столбец Loss% отображает процент потери пакетов при каждом переходе. В столбце Snt — количество отправленных пакетов. Параметр —report отправит 10 пакетов, если не указан с параметром —report-Cycle = [количество-пакетов], где [количество-пакетов] представляет собой общее количество пакетов, которые вы хотите отправить на удаленный хост.

Следующие четыре столбца — Last, Avg, Best и Wrst — измерения задержки в миллисекундах. Last — это задержка последнего отправленного пакета, Avg — это средняя задержка для всех пакетов. Best и Wrst отображают самое короткое и самое длинное время приема-передачи пакета к этому хосту.

Обращать внимание стоит показателю Avg.

Последний столбец, StDev, предоставляет стандартное отклонение задержек для каждого хоста. Чем выше стандартное отклонение, тем больше разница между значениями задержки.

Условно можно разделить результаты MTR на три основных раздела. В зависимости от конфигурации, первые 2 или 3 перехода часто представляют поставщика услуг Интернета исходного хоста, а последние 2 или 3 перехода представляют поставщика услуг Интернета конечного узла. Промежуточные переходы — это маршрутизаторы на пути пакета к пункту назначения.

Например, если MTR запускается с домашнего ПК к серверу, первые 2 или 3 хопа принадлежат вашему провайдеру. Последние несколько хопов принадлежат центру обработки данных, в котором находится ваш сервер. Любой хоп в середине — это промежуточный хоп. Если при локальном запуске MTR вы видите отклонение от нормы на первых нескольких переходах рядом с источником, обратитесь к вашему провайдеру или проверьте конфигурацию локальной сети. Если рядом с местом назначения — обратитесь к оператору целевого сервера или в службу поддержки сети этого устройства. В случаях, когда возникают проблемы на промежуточных переходах, оба поставщика услуг будут иметь ограниченные возможности для решения проблемы.

Анализировать отчеты MTR

Теперь рассмотрим как можно проанализировать отчеты MTR.

Проверить потерю пакетов

При анализе MTR вы ищите две вещи: потери и задержки. Если вы видите процент потерь на каком-либо конкретном переходе, это может указывать на наличие проблемы с этим маршрутизатором. Но это не всегда так, поскольку у некоторых поставщиков услуг существует ограничение ICMP-трафика, используемого MTR. Что может создать иллюзию потери пакетов, когда потери нет. Чтобы разобраться существует ли потеря, посмотрите на следующий хоп. Если этот хоп показывает потерю 0,0%, то скорее всего, дело в ограничении ICMP-пакетов:

root@localhost:~# mtr --report www.google.com
HOST: our.machine              Loss% Snt Last Avg Best Wrst StDev
1. provider.hop.net.           0.0%   10  0.3 0.6 0.3  1.2   0.3
2. another.hop.net             50.0%  10  0.8 0.7 0.5  0.8   0.0
3. one.more.hop.net            0.0%   10  3.3 2.0 1.0  7.7   2.1
4. and.more.hop.net            0.0%   10  1.4 2.2 1.2  8.7   2.2
5. finishing.distance.hop.net  0.0%   10  1.4 1.5 1.3  1.7   0.0
6. almost.finish.hop.net       0.0%   10  3.3 2.7 2.5  3.3   0.0
7. pre.final.hop.net.          0.0%   10  3.9 2.5 2.0  3.9   0.5
8. final.hop.net.              0.0%   10  1.5 1.6 1.4  2.8   0.3

В этом случае потеря между хопами 1 и 2 связана с ограничением пакетов на втором хопе. Поскольку у следующих восьми хопов, после второго хопа, нет потери пакетов. Если потери больше чем на одном хопе, возможно, есть потеря пакетов или проблемы с маршрутизацией. Обратите внимание, что потеря и ограничение скорости могут быть одновременно. В этом случае возьмите самый низкий процент потерь в последовательности как фактическую потерю:

root@localhost:~# mtr --report www.google.com
HOST: our.machine              Loss% Snt Last Avg Best  Wrst StDev
1. provider.hop.net            0.0%  10  0.3  0.6  0.3  1.2 0.3
2. another.hop.net             0.0%  10  0.4  1.0  0.4  6.1 1.8
3. one.more.hop.net            60.0% 10  0.8  2.7  0.8  19.0 5.7
4. and.more.hop.net            60.0% 10  6.7  6.8  6.7  6.9 0.1
5. finishing.distance.hop.net  50.0% 10  7.2  8.3  7.1  16.4 2.9
6. almost.finish.hop.net       40.0% 10  39.1 39.4 39.1 39.7 0.2
7. pre.final.hop.net           40.0% 10  39.6 40.4 39.4 46.9 2.3
8. final.hop.net               40.0% 10  39.6 40.5 39.5 46.7 2.2

В этом случае потеря 60% между хопами 2 и 3, а также между хопами 3 и 4. Вы можете предположить, что третий и четвертый хопы, теряют некоторый объем трафика, потому что ни один из последующих узлов не сообщает о нулевых потерях. Тем не менее некоторые потери связаны с ограничением пакетов, поскольку некоторые из последних хопов теряют только 40%. Когда сообщается о различных потерях, всегда изучайте отчеты следующих хопов.

Некоторую потерю также можно объяснить проблемами на обратном пути. Пакеты дойдут до места назначения без ошибок, но им будет сложно вернуться. По этой причине при возникновении проблемы следует собирать отчеты MTR в обоих направлениях.

Интернет-протоколы устойчивы к некоторой деградации сети, а маршруты, по которым данные проходят через Интернет, могут колебаться в ответ на нагрузку или другие проблемы маршрутизации. Если ваш отчет MTR показывает небольшие потери в районе 10%, не стоит беспокоиться, поскольку прикладной уровень компенсирует потери, которые являются временными.

Задержка в сети

MTR также поможет оценить задержку соединения между вашим хостом и целевым хостом. В силу физических ограничений задержка всегда увеличивается с количеством переходов в маршруте. Однако увеличение должно быть последовательным и линейным.

К сожалению, задержка часто бывает относительной и очень зависит от качества соединений хоста и их физического расстояния.

Качество соединения также может повлиять на величину задержки. Dial-up соединения будут иметь большую задержку, чем соединения с кабельным модемом к тому же месту назначения. Следующий отчет MTR показывает высокую задержку:

root@localhost:~# mtr --report www.google.com
HOST: our.machine               Loss% Snt Last Avg Best Wrst StDev
1. provider.hop.net             0.0%  10  0.3  0.6  0.3  1.2 0.3
2. another.hop.net              0.0%  10  0.4  1.0 0.4   6.1 1.8
3. one.more.hop.net             0.0%  10  0.8  2.7 0.8   19.0 5.7
4. and.more.hop.net             0.0%  10  388.0 360.4 342.1 396.7 0.2
5. finishing.distance.hop.net   0.0%  10  390.6 360.4 342.1 396.7 0.2
6. almost.finish.hop.net        0.0%  10  391.6 360.4 342.1 396.7 0.4
7. pre.final.hop.net            0.0%  10  391.8 360.4 342.1 396.7 2.1
8. final.hop.net                0.0%  10  392.0 360.4 342.1 396.7 1.2

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

К сожалению, высокая задержка не всегда означает проблему с текущим маршрутом. Отчет, подобный приведенному выше, означает, что, несмотря на некоторые проблемы с 4-м хопом, трафик все еще достигает хоста назначения и возвращается к хосту-источнику. Задержка также может быть вызвана проблемой с обратным маршрутом. Обратный маршрут не будет отображаться в вашем отчете MTR, и пакеты могут идти по совершенно разным маршрутам в конкретный пункт назначения и обратно.

В приведенном выше примере, несмотря на большой скачок задержки между хостами 3 и 4, задержка не увеличивается на любых последующих хопах. Из этого логично предположить, что с 4-м роутером есть какая-то проблема.

Ограничение ICMP-трафика также может создавать видимость задержки:

root@localhost:~# mtr --report www.google.com
HOST: our.machine             Loss% Snt Last Avg Best Wrst StDev
1. provider.hop.net            0.0% 10  0.3  0.6  0.3  1.2  0.3
2. another.hop.net             0.0% 10  0.4  1.0  0.4  6.1  1.8
3. one.more.hop.net            0.0% 10  0.8  2.7  0.8  19.0  5.7
4. and.more.hop.net            0.0% 10  6.7  6.8  6.7  6.9   0.1
5. finishing.distance.hop.net  0.0% 10  254.2 250.3 230.1 263.4 2.9
6. almost.finish.hop.net       0.0% 10  39.1  39.4  39.1 39.7 0.2
7. pre.final.hop.net           0.0% 10  39.6  40.4  39.4 46.9 2.3
8. final.hop.net               0.0% 10  39.6  40.5  39.5 46.7 2.2

На первый взгляд обращает на себя внимание задержка между хопами 4 и 5. Однако после пятого хопа задержка резко падает. Фактическая задержка равна около 40 мс. В подобных случаях MTR обращает внимание на проблему, которая не влияет на работу службы. При оценке отчета MTR учитывайте задержку до последнего перехода.

Общие отчеты MTR

Рассмотрим общие отчеты MTR и их корректность.

Сеть целевого хоста настроена неправильно

В следующем примере конечный хост теряет 100% из-за неправильно настроенного маршрутизатора. Кажется, что пакеты не достигают хоста, но это не так.

root@localhost:~# mtr --report www.google.com
HOST: our.machine              Loss% Snt Last Avg Best Wrst StDev
1. provider.hop.net            0.0%  10  0.3  0.6  0.3  1.2  0.3
2. another.hop.net             0.0%  10  0.4  1.0  0.4  6.1  1.8
3. one.more.hop.net            0.0%  10  0.8  2.7  0.8  19.0 5.7
4. and.more.hop.net            0.0%  10  6.7  6.8  6.7  6.9  0.1
5. finishing.distance.hop.net  0.0%  10  7.2  8.3  7.1  16.4 2.9
6. almost.finish.hop.net       0.0%  10  39.1 39.4 39.1 39.7 0.2
7. pre.final.hop.net           0.0%  10  39.6 40.4 39.4 46.9 2.3
8. final.hop.net               100.0 10  0.0  0.0  0.0  0.0  0.0

Трафик действительно достигает хоста назначения. Но в отчете MTR мы наблюдаем потерю, потому что хост назначения не отправляет ответ. Это может быть результатом неправильно настроенных правил сети или брандмауэра (iptables), из-за которых хост отбрасывает ICMP-пакеты.

Чтобы определить, что потеря произошла из-за неправильно настроенного хоста, нужно посмотреть на переход, который показывает 100% потерю. Из предыдущего отчета вы видите, что это последний хоп и что MTR не переходит к следующему хопу. Хотя трудно изолировать эту проблему без базовых измерений, ошибки такого рода довольно распространены.

Пользовательский или бизнес-маршрутизатор

Пользовательские шлюзы иногда вызывают вводящие в заблуждение отчеты:

% mtr --no-dns --report google.com
HOST: our.machine    Loss% Snt Last Avg Best Wrst StDev
1. 192.168.1.1      0.0%  10  2.2  2.2  2.0  2.7  0.2
2. ???             100.0  10  8.6  11.0 8.4  17.8  3.0
3. 10.64.18.65      0.0%  10  3.3  2.0  1.0  7.7  2.1
4. 10.64.4.25       0.0%  10  1.4  2.2  1.2  8.7  2.2
5. 72.14.214.16     0.0%  10  1.4  1.5  1.3  1.7  0.0
6. 108.170.248.33   0.0%  10  2.6  2.8  2.6  3.4  0.0
7. 142.250.46.191   0.0%  10  11.5  3.7  2.0 11.5 3.0
8. 142.250.64.110   0.0%  10  1.5  1.5   1.4 1.7  0.0

100% потеря на втором хопе, не указывает на наличие проблемы, так как на следующих хопах нет потерь.

Маршрутизатор интернет-провайдера настроен неправильно

Иногда маршрутизатор неправильно настроен, и ваши пакеты могут никогда не достичь места назначения:

root@localhost:~# mtr --report www.google.com
HOST: our.machine    Loss% Snt Last Avg Best Wrst StDev
1. 66.55.151.209     0.0%  10  0.8  0.7  0.5  0.8  0.0
2. 10.64.18.65       0.0%  10  3.3  2.0  1.0  7.7  2.1
3. 10.64.4.25        0.0%  10  1.4  2.2  1.2  8.7  2.2
4. 72.14.214.16      0.0%  10  1.4  1.5  1.3  1.7  0.0
5. ???               0.0%  10  0.0  0.0  0.0  0.0  0.0
6. ???               0.0%  10  0.0  0.0  0.0  0.0  0.0
7. ???               0.0%  10  0.0  0.0  0.0  0.0  0.0
8. ???               0.0%  10  0.0  0.0  0.0  0.0  0.0
9. ???               0.0%  10  0.0  0.0  0.0  0.0  0.0
10. ???              0.0%  10  0.0  0.0  0.0  0.0  0.0

Знаки вопроса появляются, когда нет дополнительной информации о маршруте. Иногда плохо настроенный маршрутизатор отправляет пакеты в цикле. Как на следующем примере:

root@localhost:~# mtr --report www.google.com
HOST: our.machine    Loss% Snt Last Avg Best Wrst StDev
1. 66.55.151.209      0.0% 10  0.8  0.7  0.5  0.8  0.0
2. 10.64.18.65        0.0% 10  3.3  2.0  1.0  7.7  2.1
3. 10.64.4.25         0.0% 10  1.4  2.2  1.2  8.7  2.2
4. 72.14.214.16       0.0% 10  1.4  1.5  1.3  1.7  0.0
5. 108.170.248.33     0.0% 10  0.0  0.0  0.0  0.0  0.0
6. 108.170.248.32     0.0% 10  0.0  0.0  0.0  0.0  0.0
7. 108.170.248.33     0.0% 10  0.0  0.0  0.0  0.0  0.0
8. 108.170.248.32     0.0% 10  0.0  0.0  0.0  0.0  0.0
9. 108.170.248.33     0.0% 10  0.0  0.0  0.0  0.0  0.0
10. 108.170.248.32    0.0% 10  0.0  0.0  0.0  0.0  0.0
11. 108.170.248.33    0.0% 10  0.0  0.0  0.0  0.0  0.0
12. ???               0.0% 10  0.0  0.0  0.0  0.0  0.0
13. ???               0.0% 10  0.0  0.0  0.0  0.0  0.0
14. ???               0.0% 10  0.0  0.0  0.0  0.0  0.0

Эти отчеты показывают, что маршрутизатор на 4 хопе неправильно настроен. В данном случае, чтобы решить проблему, нужно обратиться к оператору сетевого администратора на исходном узле.

Ограничение ICMP-пакетов

Ограничение ICMP-трафика может вызвать явную потерю пакетов. Когда происходит потеря пакета для одного хопа, которая не сохраняется для последующих хопов, потеря вызвана ограничением ICMP:

root@localhost:~# mtr --report www.google.com
HOST: our.machine              Loss% Snt Last Avg Best Wrst StDev
1. provider.hop.net            0.0%  10  0.3  0.6  0.3  1.2  0.3
2. another.hop.net             0.0%  10  0.4  1.0  0.4  6.1  1.8
3. one.more.hop.net            0.0%  10  0.8  2.7  0.8  19.0 5.7
4. and.more.hop.net            0.0%  10  6.7  6.8  6.7  6.9  0.1
5. finishing.distance.hop.net  60.0% 10  27.2 25.3 23.1 26.4 2.9
6. almost.finish.hop.net       0.0%  10  39.1 39.4 39.1 39.7 0.2
7. pre.final.hop.net           0.0%  10  39.6 40.4 39.4 46.9 2.3
8. final.hop.net               0.0%  10  39.6 40.5 39.5 46.7 2.2

В этом отчете нет причин для беспокойства. Ограничение пакетов — обычная практика, и оно уменьшает перегрузку, чтобы отдавать приоритет более важному трафику.

Таймауты

Таймауты могут возникать по разным причинам. Некоторые маршрутизаторы отклоняют ICMP, и отсутствие ответов обозначено на выходе как таймауты (???). В качестве альтернативы может быть проблема с обратным маршрутом:

root@localhost:~# mtr --report www.google.com
HOST: our.machine     Loss% Snt Last Avg Best Wrst StDev
1. provider.hop.net   0.0%  10  0.3  0.6  0.3   1.2  0.3
2. another.hop.net    0.0%  10  0.4  1.0  0.4   6.1  1.8
3. one.more.hop.net   0.0%  10  0.8  2.7  0.8   19.0 5.7
4. and.more.hop.net   0.0%  10  6.7  6.8  6.7   6.9  0.1
5. ???                0.0%  10  7.2  8.3  7.1   16.4 2.9
6. ???                0.0%  10  39.1  39.4 39.1 39.7 0.2
7. pre.final.hop.net  0.0%  10  39.6  40.4 39.4 46.9 2.3
8. final.hop.net      0.0%  10  39.6  40.5 39.5 46.7 2.2

Таймауты необязательно указывают на потерю пакета. Пакеты по-прежнему достигают места назначения без значительной потери пакетов или задержки. Тайм-ауты могут быть связаны с тем, что маршрутизаторы отбрасывают пакеты для целей QoS (качества обслуживания), или могут возникать проблемы с обратными маршрутами, вызывающими тайм-ауты. Это еще один ложный результат.

Продвинутые методы MTR

Новые версии MTR теперь могут работать в режиме TCP на указанном TCP-порту, по сравнению с протоколом ICMP (ping) по умолчанию. Однако в большинстве случаев этот режим не следует использовать, поскольку отчеты TCP могут вводить в заблуждение при диагностике проблем между маршрутами. TCP MTR будет использовать пакеты SYN вместо эхо-запросов ICMP, и большинство маршрутизаторов интернет-уровня не будут отвечать на них, ошибочно указывая на потерю.

Тест TCP полезен для определения того, блокируют ли правила брандмауэра на маршрутизаторе протокол или порт, из-за того, что переадресация портов не корректно настроена. Выполнение теста TCP через определенный порт может выявить это, тогда как тест ICMP — нет.

Для запуска MTR в режиме TCP на большинстве машин потребуются права суперпользователя:

sudo mtr --tcp --port 80 --report --report-cycles 10 www.google.com
sudo mtr --tcp --port 22 --report --report-cycles 10 91.239.232.223

Обратите внимание! После «—report-cycles» мы указываем количество отправленных пакетов для проверки каждого «хопа».

Решите проблемы маршрутизации и сети, указанные в вашем отчете MTR

Большинство проблем с маршрутизацией, отображаемых в отчетах MTR, являются временными и исчезают сами спустя время. Если проблемы наблюдаются длительный период, стоит информировать поставщика об этом, предоставив отчет MTR.

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

Наш телеграм

с важными анонсами, розыгрышами и мемами

Присоединиться