Як читати traceroute: чому втрати на 5-му хопі зазвичай нічого не означають

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

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

Що traceroute робить насправді

Він надсилає пакети з навмисно малим TTL. Перший маршрутизатор зменшує його до нуля, здається і надсилає назад ICMP-повідомлення Time Exceeded. Саме з цієї відповіді ви й дізнаєтеся, що маршрутизатор існує. TTL 2 дає другий, і так далі, доки пакети не дійдуть до призначення.

Тож кожен рядок, крім останнього, - це не вимір вашого трафіку. Це вимір того, як швидко маршрутизатор вирішив згенерувати повідомлення про помилку щодо вашого трафіку. Це різні речі, і маршрутизатори ставляться до них по-різному.

Чому середні хопи брешуть

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

Через це хоп показує 40 відсотків втрат, пропускаючи при цьому 100 відсотків трафіку. Звідси два правила, які на місці закривають більшість таких тікетів:

Втрати, що не тривають до кінця, - це не втрати. Якщо на 5-му хопі 40 відсотків, а на хопах з 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