Блокировка многоадресных адресов OSPF

Одна из неполадок в работе протокола OSPF может быть связана с блокировкой многоадресных адресов. Представим, что в нашем распоряжении есть 2 маршрутизатора и у нас возникла следующая проблема:

Интересно отметить следующее: R1 показывает, что наш сосед OSPF находится в состоянии INIT, при этом R2 не показывает ничего.

Как видно из примера выше, OSPF был настроен корректно на обоих интерфейсах. Так как R1 показывает состояние INIT, можно сделать вывод, что R1 получает что-то от R2. Так как R2 не показывает ничего, вероятнее всего, он ничего не получает от R1. Протокол OSPF использует пакеты приветствия для установления соседства OSPF, при этом они отправляются с применением многоадресного адреса 224.0.0.5.

Тут желательно проверить, а можем ли мы пропинговать адрес многоадресной рассылки, то есть адрес, который протокол OSPF применяет для пакетов приветствия. Как видим, и R1, и R2 не получают ответа оба.

Отправляем эхо-запросы друг другу — никаких проблем. Что же тогда может вызвать имеющиеся проблемы с отправкой и получением многоадресного трафика OSPF? А может, речь в списке доступа?

Так, что-то обнаружили. И это «что-то» заключается в том, что на R2 есть входящий список доступа с именем BLOCKSTUFF.

Вот так вот. Список доступа разрешает лишь TCP-, UDP- и ICMP-трафик. Протокол OSPF не использует TCP либо UDP, в результате чего он удаляется этим списком доступа по причине deny any. И пусть мы не видим этого в верхнем листинге, зато в нижней части access-list данный запрет существует.

Корректируем access-list так, чтобы разрешить трафик OSPF.

Ура, проблема решена.

Что же, теперь можно уже пинговать адрес многоадресной рассылки 224.0.0.5 OSPF, в результате чего мы увидим ответ с другой стороны.

Итог этого урока прост: не стоит блокировать многоадресные адреса OSPF 224.0.0.5 и 224.0.0.6 (DR/BDR).

Источник