Діагностика мережевих проблем за допомогою looking glass - блог компанії Селектел

Діагностика мережевих проблем за допомогою looking glass - блог компанії Селектел

Для багатьох наших клієнтів критерієм вибору серверних послуг є мережева зв'язність. Під мережевий связностью розуміється ступінь взаємодії мережі одного оператора з мережами інших операторів і, як наслідок, кількість маршрутів і кількість проміжних вузлів для інтернет-трафіку.

Перевірку мережевий зв'язності зручно здійснювати за допомогою сервісів, які називаються «Looking Glass» (в перекладі з англійської - дзеркало). Вони дозволяють перевіряти маршрутизацію з віддаленої мережі. Такі сервіси є у багатьох організацій (з інформацією про всі Looking Glass світу можна ознайомитися, наприклад, тут).

Інтерфейс нашого «Looking Glass» гранично простий:

Діагностика мережевих проблем за допомогою looking glass - блог компанії Селектел

Всі команди виконуються з двох маршрутизаторів, розташованих в Санкт-Петербурзі і в Москві (вибрати маршрутизатор можна, встановивши прапорець в полі Router; можна здійснювати перевірку з двох маршрутизаторів одночасно).

Наш сервіс «Looking Glass» виконує наступні команди (вибір команди здійснюється в випадаючому меню «Operation»):

команда ping

Результати команди ping можуть виглядати, наприклад, так:

З цього прикладу видно, що вузол призначення справно відповідає на запити, втрат пакетів немає. Розглянемо ще один приклад:

В даному випадку з результатів видно, що вузол призначення доступний, втрати пакетів немає, але час відповіді кілька збільшено через географічну віддаленість: вузол призначення знаходиться в Японії, а запити відправлялися з Санкт-Петербурга.

Іноді може мати місце і така ситуація:

Результати роботи команди в даному випадку показують, що жоден з пакетів не дійшов до мети і що вузол, швидше за все, недоступний, або не відповідає на ICMP-запити.

Таким чином, за допомогою запиту ping можна перевірити з'єднання з віддаленим вузлом. Сам факт успішного повернення запитів дає підстави припускати, що всі пристрої на шляху від маршрутизатора до зазначеного вузла працюють нормально. Слід зазначити, що втрата пакетів може мати місце навіть за відсутності несправностей: вона може бути обумовлена, наприклад, перевантаженістю мережі. Часто буває і так, що маршрутизатори дають діагностують пакетам низький пріоритет. Але якщо хоча б один з відправлених пакетів повертається, то це вже свідчить про наявність з'єднання та доступності вузла.

На підставі результатів запиту ping однозначного висновку про наявність несправності зробити неможливо. Можна лише висунути припущення, яке потребує додаткової перевірки за допомогою інших інструментів.

команда traceroute

Проблеми з доступністю веб-сервісів можуть також бути обумовлені технічними проблемами на проміжних вузлах, через які проходять пакети на шляху до хосту призначення. Виявити ці проблеми можна за допомогою команди traceroute.

Як працює ця команда? Однією з характеристик пересилаються по мережі пакетів є час життя (англ. Time to live, скорочено TTL) - число хопов (англ. Hop - стрибок, тобто перехід пакета від одного маршрутизатора - до іншого) або час в мілісекундах, протягом якого пакет може знаходитися в мережі. Кожен маршрутизатор, що обробляє пакет, зменшує значення TTL на одиницю. Коли TTL стає рівним нулю, пакет знищується, а відправнику надсилається IMCP-повідомлення time exceeded (час минув). Спочатку цей механізм використовувався для запобігання нескінченного копіювання мережевих пакетів при помилковому закільцювання мережі.

Отримавши команду traceroute, маршрутизатор відправляє в напрямку хоста призначення пакет з TTL = 1. Вузол, з якого приходить відповідь time exceeded, визначається як перший хоп (тобто перший крок на шляху до мети). Потім по черзі відправляються пакети з TTL = 2,3,4,5 і так далі - до тих пір, поки один з пакетів не досягне вузла призначення і не отримає від нього відповідь.

В результаті на екран виводиться список всіх проміжних вузлів на шляху пакета від маршрутизатора до вузла призначення. Він може, виглядати, наприклад, так:

Що видно з представленого результату?

У дев'ятому переході замість одного з значень часу відповіді відображається зірочка. Це означає, що на якийсь із відправлених пакетів не було отримано відповіді. Це може бути викликано, наприклад, перевантаженням мережі. Або тим, що багато маршрутизаторів відкидають низькопріоритетні ICMP-пакети. Поява таких зірочок у висновку traceroute - цілком типова ситуація, яка не є причиною для занепокоєння.

Якщо для одного з проміжних маршрутизаторів відображається три зірочки, то це означає, що від нього не було отримано жодної відповіді. Але не слід робити висновку про наявність несправності на підставі одних лише цих зірочок. Їх поява може бути обумовлено різними причинами. Наприклад, маршрутизатори нерідко конфігурують таким чином, щоб вони "мовчки" відкидали застарілі пакети. В цьому випадку пакети благополучно переходять на наступний маршрутизатор.

Причина може полягати і в тому, що відповідні пакети від цього маршрутизатора йдуть занадто довго, і Looking Glass перестає чекати їх прибуття. Якщо ж три зірочки відображаються для вузлів в кінці маршруту (як у наведеному прикладі), то це, швидше за все, свідчить про те, що пакети до вузла призначення не дійшли.

Інтерпретація висновків traceroute є складнішою і тонку завдання, ніж це може здатися на перший погляд; більш докладно про це можна прочитати тут і тут (англійською мовою).

Команди для діагностики BGP

BGP (англ. Border Gateway Protocol, протокол граничного шлюзу) - це основний протокол динамічної маршрутизації в Інтернеті. Він призначений для обміну інформацією не між окремими маршрутизаторами, а між автономними системами. Автономною системою, згідно з визначенням, яке в RFC1930, називається система IP-мереж і маршрутизаторів, керованих одним або більшою кількістю постачальників і мають окрему політику маршрутизації з Інтернетом. Власне, Інтернет можна розглядати як набір пов'язаних між собою автономних систем.

За допомогою BGP-протоколу автономні системи повідомляють один одному: (1) про факт свого існування і (2) про те, які мережі можуть бути отримані через них. Вони також збирають інформацію про те, як дістатися до інших мереж в Інтернеті. Отримуючи інформацію про маршрутах до мети призначення, вони визначають з них найкращий (на основі правил мережі, а не технічних метрик) і додають в свої таблиці маршрутизації. Саме тому BGP-протокол іноді називають клеєм, сполучною весь Інтернет.

Протокол BGP був створений за часів, коли в Інтернеті не існувало багатьох проблем і небезпек, які існують сьогодні, і він характеризується підвищеною вразливістю. Помилки в роботі протоколу, які можуть бути викликані як технічними проблемами конкретної автономної системи, так і навмисними діями зловмисників, можуть призводити до дуже серйозних наслідків (більш докладно про це можна прочитати, наприклад, тут). В результаті цих помилок трафік перенаправляється і / або відкидається, не доходячи до мережі призначення - через це виникають проблеми з мережевою доступністю.

Перевірити роботу BGP-протоколу можна за допомогою команд bgp route detail, bgp route terse і bgp summary. Результатом роботи команди bgp route detail є таблиця маршрутизації c переліком всіх автономних станцій на шляху руху пакетів. Команда bgp terse виводить на екран скорочений варіант таблиці маршрутизації. Команда bgp summary виводить список всіх автономних систем, з якими є зв'язність у наших маршрутизаторів.

висновок

З самого початку надання послуг оренди й розміщення виділених серверів в вартість було включено гарантований канал 10 Мбіт / с. Судячи зі статистики, цієї швидкості до сих пір вистачає для більшості серверів, але потужність серверів і їх можливості продовжують рости, а трафік значно зміщується в бік «важкого» он-лайн медіа і канал стає обмежуючим фактором навіть для невеликих.