Пошук і усунення проблем маршрутизації за допомогою ping і debug в мережах cisco
Системного адміністратора дуже часто доводиться стикатися з проблемами маршрутизації. Ось недавно мені довелося, так що по старій пам'яті вирішив написати про це невелику статейку.
Маршрутизація в мережах Cisco не повинна викликати складнощів, а якщо все-таки щось не працює так, як потрібно - на допомогу нам прийдуть старі добрі ping-й.
Для тих, хто ще не в темі, утиліта PING існує у всіх популярних системах, починаючи від Windows, закінчуючи IOS в Cisco. З її допомогою формується icmp-пакет, що містить запит echo. Якщо протягом певного часу віддалений вузол зможе його отримати, обробити і відправити відповідь - вважається, що канал зв'язку стабільний і хости працюють правильно.
Наприклад у мене найпростіший спосіб діагностувати зниклий раптом інет:
- ping 192.168.1.100 - чи є зв'язок до шлюзу;
- ping 8.8.8.8 - чи є зв'язок на внешк;
- ping ya.ru - чи є зв'язок на DNS-сервера;
Отже, подивимося, як за допомогою ping можна діагностувати проблеми в мережі.
Я намалював просту топологію в GNS3, тут у нас 4 маршрутизатора, R1-R4 відповідно. Три / 24-их підмережі. Ділянка між 1 і 2 роутером - підмережа 12.0.0.0/24, між 2 і 3 - 23.0.0.0/24, між 3 і 4 - 34.0.0.0/24 відповідно. Тобто перший октет показує, між якими роутерами мережу. Так само, останній октет вказує безпосередньо роутер.
Таким чином сміливо можна сказати, що, наприклад, IP 23.0.0.3 знаходиться з боку R2 і R3 і належить інтерфейсу R3.
Топологія нашої мережі
Маршрути на ділянці я спеціально ніякі не призначав.
Насамперед розберемося з основними можливостями Cisco в плані діагностики.
Пошлемо ping запит з 12.0.0.1 на 12.0.0.2. Ці два інтерфейси з'єднані безпосередньо, тому побачимо щось подібне до цього:
Звичайне проходження ping
Яку інформацію ми тут побачимо:
Кожен символ "!" Означає успішне проходження пакета.
Тепер трохи розширимо висновок.
# Debug ip packet detail
І відправимо пінг повторно:
Детальний висновок ping
Як бачите, інформації в консолі видається набагато більше. Тут у нас мітка часу, протокол (IP), s = (source - джерело), d = (destination - призначення), ім'я порту (FastEthernet0 / 1), тип ICMP (8 - запит echo, 0 - відповідь) і т. д.
Для чого ця інформація нам може бути корисна? Наступні ситуації. Відправимо ping на R4 з R1. Не думаю, що пакети дійдуть, адже роутер просто не знає, куди посилати пакети для мережі 34.0.0.0/24.
Запит не увінчався успіхом
Відразу бачимо причину: unroutable (немає маршруту в точку призначення). Якби ми не вказали debug, то побачили б щось інше. Відключимо налагодження і подивимося:
# Undebug all
# Ping 34.0.0.4
Всього лише "... ..", де кожна точка означає невдалу передачу ping. Ніяких зачіпок.
Тепер зробимо трохи інакше. Пропишемо маршрут за замовчуванням на наступний роутер (R2), тому що нам (R1) все одно більше нікуди посилати пакети крім нього:
# Conf t
# Ip route 0.0.0.0 0.0.0.0 12.0.0.2
Тут бачимо вже 5 символів "U", що означають Unroutable. Чи не очевидно, де проблема, якщо ми не знаємо деталі маршрутизації між роутерами. По хорошому треба зараз дивитися всі чотири конфіга і шукати відповідності таблиць.
Включимо налагодження на R2 і повторимо пінг:
Незважаючи на те, що на R2 ми безпосередньо нічого не робили (тільки включили налагодження), в його консолі вилітають повідомлення про всіх, хто йшов пакетах.
Увага! Команди debug можуть сильно навантажити процесор роутера, тому користуватися ними потрібно з обережністю. Нижче я розповім, як можна трохи більш комфортно працювати з дебагом.
Отже, що ми бачимо в налагодженні R2 (коли з R1 пінгувати R4):
Передача icmp echo з 12.0.0.1 на 34.0.0.4 повернула результат unroutable, так як роутер 2 не знає, куди передавати пакет далі. Мережа 34.0.0.0/24 йому не знайома (зліва у нього 12.0.0.1, праворуч 23.0.0.3). Дамо йому невелику підказку. Для цього активуємо протокол динамічної маршрутизації RIP на маршрутизаторах R2 і R3:
R2 # conf t
R2 (config) # router rip
R2 (config-router) # network 12.0.0.0
R2 (config-router) # network 23.0.0.0
R2 (config-router) # exit
R3 # conf t
R3 (config) # router rip
R3 (config-router) # network 23.0.0.0
R3 (config-router) # network 34.0.0.0
R3 (config-router) # exit
Тобто на маршрутизаторах вказуємо відомі їм мережі. У роутера 2 мережі 12. * і 23. *, а у 3 - 23. * і 34. * відповідно. Про протоколі RIP ми ще обов'язково поговоримо пізніше. Отже, анонсували наші мережі. Повторюємо ping-запит з R1 на R4. На R1 і раніше глухо. А ось включення налагодження пакетів на R4 показує іншу картину:
Пакети приходять, але не йдуть
s = 12.0.0.1, d = 34.0.0.4 - дійшов, тобто запит echo до нас прибув. А ось зворотний:
s = 34.0.0.4, d = 12.0.0.1 - unroutable, недосяжний. Млинець. Просто не знаємо, куди посилати далі. Ну вже принаймні півдорозі виконали!
Зараз ми просто повідомимо, щоб R4 посилав все (взагалі все!) Пакети на R3 (бо йому більше нікуди слати), R3 сам розбереться, у нього RIP включений.
Ось тепер все в порядку!
Після додавання статичного маршруту на R4:
R4 (config) # ip route 0.0.0.0 0.0.0.0 34.0.0.3
Все запрацювало! З R1 доступний R4!
Вимкнемо налагодження на всіх роутерах, щоб не навантажувати процесор і не заливати консоль балками:
R2 # .... R3 # .... R4 # ... те ж саме.
Тепер, я сподіваюся, стало простіше діагностувати несправності маршрутизації, коли незрозуміло, до куди доходить пакет, а до куди - ще немає.
Тепер, як і обіцяв, трохи розповім про фічах. Ми часто бачимо в команді ping напис Type escape sequence to abort (натисніть ескейп-послідовність для скасування), стандартне лінуксових Ctrl + C тут не працює. Що ж робити? Для Cisco цієї послідовністю є Ctrl + 6. Таке ось неочевидне поєднання.
Далі, з приводу налагодження. Подивитися, що ми налагоджувати в дану секунду можна набравши команду
Ще один спосіб зменшити навантаження на консоль - формування висновку в буфер і наступний висновок його:
R4 (config) # no logging console
R4 (config) # logging buffered 5000
R4 (config) # do debug ip packet
R4 (config) # do ping 12.0.0.1
.
R4 (config) # do undebug all
R4 (config) # do show log
Ось остання команда покаже нам лог, який зберігався в буфер розмірі 5000 байт:
Налагодження в буфер
Ось в принципі і все, що я хотів поки розповісти. Далі розповім деталі роботи Traceroute.
Вам так само сподобається:
