Поиск и устранение проблем маршрутизации с помощью 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-сервера;

Хотя, конечно, отсутствие отклика от какого-либо узла вовсе не означает, что он заглушен. Может быть административно настроено, что он не отвечает на ICMP-запросы, либо отвечает с определенных IP-адресов. Да мало ли как ещё захотел администратор, чтобы сложнее было вести конкурентную разведку.

Итак, посмотрим, как с помощью 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. Эти два интерфейса соединены непосредственно, поэтому увидим что-то вроде этого:

Какую информацию мы здесь увидим:

Отправка пяти стобайтных пакетов на целевой адрес, таймаутом в 2 секунды. Отдельно можно настроить параметры указывая просто команду ping без IP адреса.

Каждый символ “!” означает успешное прохождение пакета.

Теперь немного расширим вывод.

Введём команду:

# debug ip packet detail

И отправим пинги повторно:

Как видите, информации в консоли выдаётся намного больше. Здесь у нас метка времени, протокол (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!

Выключим отладку на всех роутерах, чтобы не нагружать процессор и не заливать консоль логами:

R1# undebug all

R2# …., R3#…., R4#… то же самое.

Готово!

Теперь, я надеюсь, стало проще диагностировать неисправности маршрутизации, когда непонятно, до куда доходит пакет, а до куда – ещё нет.

Теперь, как и обещал, немного расскажу о фичах. Мы часто видим в команде ping надпись Type escape sequence to abort (нажмите эскейп-последовательность для отмены), стандартное линуксовое Ctrl+C тут не работает. Что же делать? Для Cisco этой последовательностью является Ctrl+6. Такое вот неочевидное сочетание.

Далее, по поводу отладки. Посмотреть, что мы отлаживаем в данную секунду можно набрав команду

# show debug

Ещё один способ уменьшить нагрузку на консоль – формирование вывода в буфер и последующий вывод его:

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 байт: