Що таке звіт MTR і чим він корисний

MTR – це інструмент, завдяки якому адміністратори мають можливість діагностувати і виправляти помилки мережі, а також формувати звіти про стан мережі.

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 [цільовий хост]

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

mtr -rw example.com

Щоб запустити MTR з вашого локального комп’ютера, вкажіть IP-адресу вашого сервера замість 185.67.0.0:

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.

Якщо у вас є питання або ви потребуєте допомоги — звертайтеся до нашої цілодобової техпідтримки. Ми з радість вам допоможемо.

Наш телеграм

з важливими анонсами, розіграшами й мемами

Приєднатися