Настройка OSPF для одной зоны на маршрутизаторах Cisco
В данной статье описывается процесс настройки протокола динамической маршрутизации OSPF на маршрутизаторах Cisco. Перед прочтением статьи рекомендуется ознакомиться с общими принципами работы OSPF и основными понятиями. Кроме того, существует отдельная статья по настройке OSPF для работы с несколькими зонами.
Описание топологии и задач
Для демонстрации работы OSPF будем использовать следующий стенд. Подразумевается, что в начале, у нас подняты все необходимые интерфейсы и на них настроены ip адреса, у провайдера настроены статические маршруты в нашу сеть, соседние маршрутизаторы могут пинговать друг друга. Требуется настроить OSPF.
- ISP – маршрутизатор провайдера, он не входит в зону нашей ответственности и в OSPF процессе не участвует
- R1 – наш пограничный маршрутизатор, он должен обеспечить пропуск трафика из внутренних сетей к провайдеру и обратно. На нём следует настроить статический маршрут по умолчанию и передать его остальным маршрутизаторам с помощью OSPF
- R2, R3 и R4 – внутренние маршрутизаторы каждый из них отвечает за некую локальную сеть (192.168.2.0, 192.168.3.0 и 192.168.4.0), к которым подключаются клиенты. Чтобы не усложнять топологию, эти интерфейсы сети представлены в виде loopback, которые имитируют реальные интерфейсы.
Коммутатор не сконфигурирован, то есть, все маршрутизаторы находятся в одном VLAN и видят друг друга. В данном примере нет никакой необходимость его как-то настраивать. Приведём основные моменты конфигурации маршрутизаторов на начальный момент времени.
Базовая настройка OSPF
На каждом маршрутизаторе необходимо создать процесс OSPF командой router ospf номер-процесса, какой именно номер мы укажем – не имеет значения, для простоты будем везде использовать 1, далее надо описать все сети, входящие в процесс маршрутизации с помощью команды network. Когда мы указываем некоторую сеть, это приводит к двум последствиям:
- Информация об этой сети начинает передаваться другим маршрутизаторам (при условии, что на маршрутизаторе есть рабочий интерфейс в данной сети)
- Через интерфейс, находящийся в этой сети маршрутизатор начинает общаться с соседями.
Таким образом, необходимо указывать на каждом маршрутизаторе все сети, непосредственно подключенные к нему. Исключением является R1 – на нём не надо указывать сеть 10.10.10.0, так как, во-первых, с той стороны находится провайдер, который ничего не знает про наш внутренний OSPF и с ним не надо устанавливать соседских отношений (он просто прописывает статический маршрут в наши сети), с другой стороны к провайдеру итак пойдёт маршрут по умолчанию, поэтому именно про сеть 10.10.10.0 никому из внутренних маршрутизаторов знать не обязательно. Настроим маршрутизацию.
При добавлении сетей используется wildcard маска, обратная к маске подсети. В данном случае 255.255.255.255-255.255.255.252=0.0.0.3.
Видно, что как только мы прописали с двух сторон одну и ту же сеть, маршрутизаторы сразу же установили соседские отношения. Так же мы прописали нашу «локальную» сеть 192.168.1.0 – чтобы сообщить маршрутизаторам о ней. Список соседей можно увидеть:
Пока у R2 только один сосед – R1, так как на R3 и R4 – ещё не включен OSPF и не добавлена сеть 192.168.1.0
Диагностика OSPF
Как видно, маршрутизаторы установили друг с другом соседские отношения. Посмотрим снова таблицу соседей на R2:
- Все соседи выбрали себе Router ID – в данном случае это наибольший из адресов их loopback интерфейсов
- Маршрутизатор R3 – стал BDR, R4 – не стал ни DR ни BDR, таким образом, в сети со множественным доступом 192.168.1.0/24, DR-ом стал сам R2.
- Все соседские отношения установились, в последнем столбце таблицы видно, через какой именно интерфейс доступны соседи.
Эта команда важна для диагностики OSPF и именно с неё надо начинать диагностику, так как, если маршрутизатор отсутствует в таблице соседей, то это один класс проблем (перепутали ip адреса, не включили нужную сеть командой network, не включили интерфейс командой no shutdown, не совпадают значения Hello-интервалов с двух сторон линка). Если же маршрутизатор есть в таблице соседей, значит, скорее всего, сам OSPF работает нормально и надо проверить таблицу маршрутизации.
Как мы видим, все маршруты появились в таблицу с буквой «O», что означает работоспособность OSPF нам не хватает только маршрута по умолчанию, но об этом позже. Ещё одна полезная команда позволяет нам посмотреть содержимое LSDB – то есть, кто где с кем связан. По сути, это и есть полная карта сети:
Passive-interface
Появляется одна неочевидная проблема с безопасностью. Когда мы включаем некоторую сеть в процесс ospf, мы не только рассказываем про неё всем маршрутизаторам, но и начинаем слать в неё hello пакеты. Для клиентских сетей (в нашем примере – loopback) этого делать не нужно, так как там не должно быть маршрутизаторов. В то же время, если мы исключим такую сеть – то про неё никто не узнает и трафик в неё доставляться не будет. Решение – включать такую сеть, но прописывать команду passive-interface, которая запрещает слать на некоторые интерфейсы апдейты. Подробнее с ней можно ознакомиться в отдельной статье.
Передача статического маршрута по умолчанию средствами OSPF
Последняя задача, которую необходимо решить – сообщить всем внутренним маршрутизаторам о том, что у нас есть маршрут по умолчанию, смотрящий на провайдера. Задача эта решается достаточно просто на R1:
Первая строчка добавляет статический маршрут по умолчанию в направлении ISP, но этот маршрут пока локальный, то есть он известен только на R1. Команда default-information originate заставляет OSPF передавать этот маршрут остальным маршрутизаторам.
Как видно, на R1 маршрут статический (с буквой «S»). Если посмотреть таблицу маршрутизации на R4, то она выглядит следующим образом:
В последней строчке «O» означает, что маршрут получат с помощью OSPF, «*» – что он является маршрутом по умолчанию, а «E2» – что маршрут является внешним по отношению к OSPF, то есть изначально он получен не от OSPF (в данном случае был статическим), а OSPF используется только для передачи этого маршрута. Конфигурация из данной статьи доступна в формате Packet Tracer