Урок 33. Поиск и устранение неисправностей протокола RIP

 

Несмотря на свою простоту в работе протокола могут возникнуть проблемы, многие из которых вызваны человеческим фактором, то есть неправильной настройкой. Прежде, чем приступать к поискам неисправностей следует убедиться, что нет проблем на уровнях L1 и L2. 

Для поиска проблем с маршрутизацией можно воспользоваться встроенными средствами диагностики IOS: 

    • ping
    • tracert
    • show
    • debug

 В качестве дополнительных средств используют следующее: 

    • Wireshark - программа снятия сетевого дампа
    • SNMP - программы мониторинга работы сетевых устройств.

 Приведем основные причины неисправности: 

    1. Разные версии протоколов RIP
    2. Неправильная аутентификация
    3. Разные значения таймеров
    4. Суммаризация маршрутов

 Итак, обо всем по порядку.

 

Разные версии протоколов 

Самая распространенная ошибка, когда администратор забудет указать на одном из маршрутизаторов команду version 2. Рассмотрим на примере, что произойдет:

Сетевая диаграмма

Таблица маршрутизации R1

Таблица маршрутизации R2

 

Как видно в таблице маршрутизации R2 отсутствуют сети, анонсируемые R1. Дело в том, что RIPv2 не принимает пакеты RIPv1. Однако RIPv1 принимает и обрабатывает пакеты RIPv2.

В этом легко убедиться, если выполним команду ниже: 

Router# show ip protocols

Отображение версии протокола RIP в R1

Отображение версии протокола RIP в R2

 

Поэтому, если какой-нибудь маршрутизатор не обновляют свою таблицу, то  стоит в первую очередь проверить версию протокола. 

Очень часто при поиске неисправностей помогает команда debug. Она позволяет видеть что маршрутизатор принимает и передает и как обрабатывает информацию.  

В нашем случае, если мы введем debug ip rip events, то увидим следующее:

Режим отладки работы RIP

Режим отладки работы RIP в R2

 

С командой debug стоит обращаться осторожно, так как она загружает память и процессор. Для отключения всех команд debug выполните undebug all.

 

Неправильная аутентификация 

Протокол RIP поддерживает 2 способа аутентификации: открытым текстом и MD5.

Может возникнуть ситуация, когда на обоих маршрутизаторах будут задействованы разные методы аутентификации либо разные пароли. 

В этом легко убедиться, если запустим команду debug ip rip events:

Отображение неудачной аутентификации в отладочных сообщениях

 

Теперь сравним пароли на обоих маршрутизаторах. Для этого можно воспользоваться одной из двух команд show running-config:

Настройки RIP аутентификации в R1

 

Router# show key chain

Отображение пароля для RIP в R1

 

Убедившись в правильности пароли проверим режим аутентификации командой show running-configЕсли используется аутентификация открытым текстом, то мы не увидим никакого сообщения:

На R1 настроен пароль с открытым текстом

 

Если же настроено MD5, то мы это увидим:

На R2 настроен тип пароля с MD5 шифрованием

 

 

Разные значения таймеров 

Иногда сетевым администраторам может понадобиться изменить таймеры протокола. Делается это обычно в низкоскоростных и загруженных сетях, где частые анонсы протокола только излишне нагружают сеть. Однако значения таймеров должны быть абсолютно идентичны на соседних маршрутизаторах иначе это может привести к нестабильности в таблице маршрутизации. Для проверки таймеров выполним команду show ip protocol:

Отображение установленных таймеров RIP в R1

 

 

Суммаризация маршрутов 

По умолчанию в протоколе RIP включена функция автосуммирования маршрутов. Например, у нас имеются подсети 10.0.0.0/24 и 10.23.90.0/26. Если включено автосуммирование, то протокол RIP суммирует все сети до 10.0.0.0/8 и будет анонсировать именно эту сеть всем соседям вместо тех двух. В этом нет ничего плохого, так как это позволяет сэкономить на пропускной способности канала, а также уменьшить саму таблицу, чтобы остальные маршрутизаторы особо не заморачивались. 

Однако в некоторых случаях данная функция только мешает. Взглянем на сеть ниже:

Сетевая диаграмма

 

На всех маршрутизаторах включено  автосуммирование. Вот как выглядят таблицы маршрутов в R2 и R4:

Таблица маршрутизации R2

таблица маршрутизации на R4

 

На R2 видно, что маршрут 10.0.0.0/8 указывает сразу на 3 интерфейса. Попробуем запустить ping из сети 10.2.2.0.24 и посмотрим, что получится:

Неудачный Ping

 

Отследим маршрут наших пакетов с помощью команды tracert:

результат работы программы tracert

 

Как видно наши ICMP пакеты даже не смогли покинуть роутер R4. Ладно, не получается пинговать сети 10.0.0.0/8, попробуем к примеру 50.0.0.1:

Неудачный Ping

 

Но не тут то было. Пакеты от PC1 до R1 благополучно дойдут и R1 даже на них ответит, но вот только дойдя до R2 ответные пакеты снова теряются из-за записей в таблице маршрутов. Однако, если мы попробуем пинг на 50.0.0.1 с любого другого маршрутизатора, то результат будет положительным.

Решением будет отключить автосуммирование на всех маршрутизаторах R1, R2, R3, R4.  После этого таблица маршрутов будет выглядеть так:

таблица маршрутизации R4

Таблица маршрутизации RIP

 

А пинг будет успешный из любой точки сети.