Применение OSPF в MikroTik RouterOS (часть 1)

Заполнение таблицы маршрутизации (RIB — routing information base) может осуществляться тремя способами:

1. Информация о непосредственно подключенных сетях;
2. Статические маршруты, сформированные администратором вручную;
3. Маршруты, изученные с помощью одного из динамических протоколов маршрутизации.

В рамках данной статьи будет рассмотрен последний инструмент формирования RIB с помощью протокола OSPF.

OSPF (Open Short Path First — открытый протокол выбора кратчайшего пути) — внутренний протокол динамической маршрутизации, основанный на принципах отслеживания состояния каналов, использующий в своей работе механизм построения дерева кратчайших путей, базирующемся на одной из метрик.

Основными сценариями использования OSPF являются:

• Распространение маршрутной информации (снижение манипуляций по конфигурации маршрутов на устройствах сети за счёт динамического распространения маршрутной информации);
• Отказоустойчивость (автоматическое переключение на резервный канал связи в случае выхода из строя основного канала).

Для понимания принципов OSPF важно знать основные факты о протоколе:

• OSPF разработан сообществом IETF в 1988 году, т. е. является стандартным вендоронезависимым протоколом;
• На момент написания статьи актуальны две версии протокола: версия 2 для ipv4-сетей (RFC 2328) и версия 3 для ipv6-сетей (RFC 2740);
• Относится к классу протоколов динамической маршрутизации состояния каналов (link-state);
• Является протоколом внутренней маршрутизации, т.е. распространяет маршрутную информацию в рамках одной автономной системы (AS);
• Служебные сообщения OSPF инкапсулируются в ip-пакеты со значением поля «Протокол верхнего уровня» равным 89;
• Служебные сообщения распространяются с помощью групповой рассылки (multicast), за протоколом зарезервировано два групповых адреса: 224.0.0.5 — все маршрутизаторы, на которых запущен протокол OSPF и 224.0.0.6 — все выделенные маршрутизаторы (DR).

Для пояснения основных терминов OSPF обратимся к схеме, представленной ниже. Под управлением администратора находятся все устройства в автономной системе (AS) 200, которая имеет канал к сторонней AS 100: между R1 и R5 настроено соседство по протоколу BGP.

В AS 200 функционирует протокол OSPF, выделено две области Area 0 и Area 1. Маршрутизатор R4 территориально удалён от остального оборудования и подключается к R3 через канал провайдера ISP.

• Link/Interface (канал/интерфейс) — соединение маршрутизатора с одной из сетей. Примером может служить соединение R1 и R6, подключенных напрямую или канал провайдера между R3 и R4. В концепции OSPF выделяют три типа каналов: broadcast (широковещательный), NBMA (нешироковещательный интерфейс множественного доступа), PtP (интерфейс типа «точка-точка»). По умолчанию в статье используются широковещательные интерфейсы типа Ethernet.
• AS (autonomous system - автономная система) — совокупность устройств, находящихся под единым управлением. На рисунке представлены две AS: 200 — автономная система, находящаяся под управлением администратора и 100 — сторонняя автономная система. Внутри AS могут использоваться внутренние протоколы динамической маршрутизации (OSPF, RIP и др.), а между AS — внешние протоколы (BGP).
• SPT (shortest path tree — дерево кратчайших путей) — граф сети, отражающий кратчайший путь к каждой из известных подсетей относительно корня, в качестве которого выступает устройство, производящее расчёт графа. Таким образом, для двух устройств, принадлежащих одной сети, SPT будут отличаться.
• Distance (дистанция) — степень доверия к источнику маршрутной информации. Поскольку на маршрутизаторе могут одновременно работать несколько протоколов маршрутизации, как на R1, где работает OSPF и BGP, то необходимо ввести параметр, который будет указывать на то, какому из источников маршрутной информации доверять больше. Чем меньше величина distance, тем более доверительным является источник маршрутной информации. В контексте статьи будут интересны следующие значения distance:

connected-маршруты — 0;
static-маршруты — 1;
OSPF-маршруты — 110.

• Area (область) — логическая единица деления OSPF-домена, применяемая для уменьшения пересылаемой маршрутной информации и снижения числа пересчётов SPT при изменениях на сети. Для работы OSPF обязательно наличие backbone-area (area c area-id=0). Все области должны присоединяться к backbone-area, как «ромашка», где в центре находится backbone-area, а «лепестки» — остальные области. Строгие ограничения по числу устройств в area отсутствуют и к делению домена на области необходимо подходить творчески, учитывая производительность маршрутизаторов, загрузку каналов связи и проект сети.
• Neighbors (соседи) — два маршрутизатора с запущенным процессом OSPF, имеющие общий канал связи, ассоциированный с одной и той же area. На рисунке 1, например, маршрутизаторы R2 и R1 являются соседями, т.к. соединены напрямую и их интерфейсы eth2 и eth1 ассоциированы с backbone-area.
• Adjacency (отношения соседства) — логическое соединение двух маршрутизаторов, являющихся соседями. Для отношений соседства необходимо выполнение ряда параметров, рассмотренных ниже. Два маршрутизатора, являющиеся соседями, устанавливают отношения соседства после полной синхронизации базы данных маршрутной информации LSDB.
• RID (router identificator — идентификатор маршрутизатора) — условный идентификатор маршрутизатора в домене OSPF, записываемый в форме ip-адреса. Рекомендуется, для упрощения диагностики, назначать RID вручную, однако, в случае, если идентификатор не задан, RID будет выбран автоматически из списка ip-адресов. Процесс выбора RID подробнее рассматривается ниже.
• Cost (стоимость) — условная метрика, используемая для выбора наилучшего маршрута при запуске алгоритма построения SPT. По умолчанию, в RouterOS всем интерфейсам присваивается стоимость равная 10, однако её можно изменить вручную в зависимости от решаемых задач. При настройках по умолчанию, стоимость маршрута к одной из сетей R6 от маршрутизатора R3 будет равна 30, т.к. пакет должен пройти три канала связи R3-R2-R1-R6.

• Hello-пакеты — служебные сообщения Hello-протокола, используемые для установления и поддержания соседских отношений.
• LSA (link-state advertisement — уведомление о состоянии канала) — данные, содержащие информацию о состоянии каналов связи и маршрутную информацию. LSA распространяются между маршрутизаторами, установившими соседские отношения. Выделяют одиннадцать типов LSA: 1-7 используются в OSPFv2, 8-11 — в OSPFv3 и не рассматриваются в рамках данной статьи.
• LSDB (link-state database — база данных о состоянии каналов) — совокупность LSA. LSDB хранится локально на каждом устройстве и должна быть синхронизирована в рамках одной area между всеми маршрутизаторами.
• DBD (database description — описание базы данных о состоянии каналов) — краткое описание LSA. При синхронизации LSDB, с целью уменьшения пересылаемой служебной информации, устройства обмениваются DBD, а после, по запросу, пересылают подробные LSA.
• LSR (link-state request — запрос о состоянии канала) — пакеты с помощью которых запрашиваются недостающая в LSDB информация после обмена DBD.
• LSU (link-state update — обновление о состоянии канала) — пакеты с помощью которых передаётся полная информация об LSA. Является ответом на LSU.
• LSAck (link-state acknowledgment — подтверждение о получении сообщения о состоянии канала) — пакеты, используемые для подтверждения LSU. Поскольку служебные сообщения не используют TCP, а передаются поверх ip, то используется данный механизм для контроля доставки.

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

Маршрутизаторы по функциональной роли в схеме сети бывают четырёх типов:

1. IR (internal router — внутренний маршрутизатор) — маршрутизатор, все интерфейсы которого ассоциированы с одной областью. Маршрутизаторы R3, R4, R6 на рисунке 1 являются внутренними.
2. ABR (area border router — пограничный маршрутизатор области) — маршрутизатор, расположенный на стыке областей, т.е. его интерфейсы ассоциированы с разными area. В соответствии с концепцией OSPF, хотя бы один из интерфейсов должен принадлежать backbone-area.
3. Backbone router (магистральный маршрутизатор) — маршрутизатор, у которого хотя бы один интерфейс ассоциирован с backbone-area. Маршрутизаторы R1, R2, R6 на рисунке 1 являются магистральными. Определение очень похоже на ABR, однако маршрутизатор R6 не является ABR, но является магистральным, т.к. все его интерфейсы ассоциированы с backbone-area.
4. ASBR (autonomous system border router — пограничный маршрутизатор автономной системы) — маршрутизатор, расположенный на стыке нескольких AS, или имеющий внешний канал связи. R1 на рисунке 1 является ASBR.

В рамках канала связи выделяют три роли маршрутизаторов:

• DR (designated router — выделенный маршрутизатор) — роль маршрутизатора в рамках канала связи, обязывающая его контролировать рассылку LSA. Все маршрутизаторы сегмента устанавливают отношения соседства с DR и совершают синхронизацию LSDB исключительно с ним. В случае изменений в сети, маршрутизаторы делают рассылку служебных сообщений на DR, который распространяет их остальным устройствам. Маршрутизатор, являющийся DR в одном сегменте связи, не обязательно является DR в другом. Например, маршрутизатор R3 может быть DR в канале связи с R4 и являться BDR в канале связи с R2. Процесс выбора DR и BDR рассмотрен ниже.
• BDR (backup designated router — резервный выделенный маршрутизатор) — роль маршрутизатора сегмента связи, обязывающая его контролировать работоспособность DR и, в случае выхода его из строя, брать на себя роль DR. BDR, аналогично DR, устанавливает отношения соседства со всеми устройствами и получает уведомления об изменениях, однако не производит рассылку служебных сообщений для синхронизации LSDB.
• DROther (designated router other — маршрутизаторы не являющиеся выделенными) — роли маршрутизаторов, которые не были выбраны DR и BDR в данном сегменте связи. В случае выхода из строя DR, среди DROther проводятся выборы на роль BDR.

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

Основные этапы конфигурации OSPF в RouterOS выглядят следующим образом:

1. Запуск процесса OSPF. По умолчанию в RouterOS создан один процесс OSPF и backbone-area и для запуска процесса достаточно одной команды по добавлению сетей (/routing ospf network add area=backbone network=0.0.0.0/0 disabled=no). Представленная команда активирует OSPF на всех интерфейсах, сетевые адреса которых попадают под шаблон подсети. Команда активирует OSPF на всех интерфейсах маршрутизатора, т. к. шаблон 0.0.0.0/0 включает в себя все подсети. Важно, чтобы в шаблон сети, добавляемой в OSPF, попадал весь диапазон адресов канала связи, т. е. если сетевой интерфейс ассоциирован с адресом 172.16.0.2/24, а в меню OSPF указать подсеть 172.16.0.0/25, то процесс поиска соседей на этом интерфейсе запущен не будет.
2. Выбор RID. Каждый из маршрутизаторов запускает процедуру выбора RID, которая подробнее описывается ниже.
3. Определение параметров интерфейсов. После указания сетей, на интерфейсах которых будет осуществляться поиск соседей, можно более тонко указать параметры этих интерфейсов. Например, можно задать cost, указать на принадлежность интерфейса к пассивным, на которых не будут предприниматься попытки установления соседских отношений, и др.
4. Обнаружение соседей. Посредством Hello-пакетов, посылаемых на групповой адрес 224.0.0.5, на всех интерфейсах, которые добавлены в OSPF, будет производиться поиск соседей.
5. Установление отношений соседства. В случае, если необходимые параметры для установления соседских отношений соблюдены, маршрутизаторы устанавливают отношения смежности.
6. Распределение ролей. Для broadcast- и NBMA- сетей выбирается DR и BDR. Для PtP-сетей этот этап игнорируется. Маршрутизаторы, выбранные в качестве DR/BDR, начинают обработку служебных сообщений, отправленных на групповой адрес 224.0.0.6, который закреплён за DR.
7. Синхронизация LSDB. Устройства, установившие отношения соседства, должны синхронизировать базу данных маршрутной информации следующим образом:
   • Обмен DBD между соседями;
   • Формирование LSR о неизвестной маршрутной информации из DBD, полученных от соседа;
   • Отправка LSU, содержащих подробное описание запрошенной в LSR информации;
   • Отправка LSAck в качестве подтверждения получения LSU;
   • LSDB между соседями считается синхронизированной;
   • Повторение процедуры синхронизации LSDB с другими соседями, в том числе в других area.
8. Запуск алгоритма построения SPT. После того, как базы данных каналов связи синхронизированы между всеми маршрутизаторами OSPF-домена, каждое устройство рассчитывает путь к каждой из сетей назначения в LSDB. При этом маршрутизатор представляет себя корневым устройством и выстраивает дерево, целью которого является наличие пути к каждой из сетей и отсутствие петель.
9. Экспорт в таблицу маршрутизации. После построения дерева кратчайших путей, данная информация экспортируется в RIB маршрутизатора. Помимо маршрутной информации от протокола OSPF, RIB содержит маршруты к непосредственно подключенным сетям, статические маршруты и данные о маршрутах от других протоколов маршрутизации. Однако, при принятии решения о перенаправлении пакетов, маршрутизатор руководствуется содержимым FIB (forwarding information base), которая формируется из RIB. Важно понимать, что не все OSPF-маршруты будут активными в FIB, поскольку устройство может получать маршрутную информацию из нескольких источников и при их сравнении руководствуется величиной distance.
10. Отслеживание состояния сети. После того, как алгоритм работы OSPF завершён, устройства проверяют доступность друг друга с помощью Hello-протокола и информируют своих соседей об изменениях.

Для демонстрации процедуры выбора RID рассмотрим следующую схему:

Для четырёх маршрутизаторов backbone-area выделена подсеть 172.16.100.0/24. Также на каждом маршрутизаторе создан loopback-интерфейс с ip-адресом из другой сети, причём на маршрутизаторе R3 loopback-интерфейс находится в состоянии disable. В RouterOS отсутствует интерфейс типа loopback в явном виде, поэтому используется интерфейс типа bridge.

Для маршрутизатора R1 будет явно задан RID в настройках OSPF равным 1.1.1.1. В OSPF на всех маршрутизаторах, кроме R4 будут добавлены все сети, т.е. используется шаблон 0.0.0.0/0, на R4 — только подсеть 172.16.100.0/24.

R1:

R2:

R3:

R4:

Согласно документации RouterOS, в первую очередь, в качестве RID выбирается значение, установленное вручную. В случае, если RID не задан явно, то используется значение наименьшего ip-адреса на всех активных интерфейсах маршрутизатора.

Проверим выбранные значения RID, отобразив таблицу соседей на любых двух маршрутизаторах, т.к. они расположены в одном широковещательном домене (команда /routing ospf neighbor print).

Вывод списка соседей маршрутизатора R2:

Вывод списка соседей маршрутизатора R4:

Как видно на рисунке, в качестве RID маршрутизатор R1 установил значение, заданное вручную. R2 выбрал RID=10.0.0.2, поскольку идентификатор не задан вручную и этот ip-адрес является наименьшим среди адресов, ассоциированных с активными интерфейсами.

На иллюстрации 3 видно, что R3 установил RID=172.16.100.3, несмотря на то, что в его конфигурации есть ip-адрес меньший по значению. Это объясняется тем, что ip-адрес 10.0.0.3 ассоциирован с неактивным интерфейсом br_loopback. Идентификатор R4 равен 10.0.0.4, несмотря на то, что эта подсеть не добавлена в OSPF, выбирая наименьший адрес среди всех активных интерфейсах, в соответствии с алгоритмом.

Общепринятой практикой является конфигурация RID вручную, как это сделано на R1, что упрощает диагностику работы сети. Также следует упомянуть о том, что RID должен быть уникальным в рамках OSPF-домена.

Для того, чтобы два маршрутизатора установили соседские отношения, необходимо, чтобы выполнялись следующие условия:

• Совпадение сети и маски сети (условие является необязательным в PtP-сетях);
• Совпадение MTU на интерфейсах в сторону канала связи;
• Совпадение интервала отправки Hello-сообщений (по умолчанию значение равно 10 секунд);
• Совпадение Router dead interval. В случае, если маршрутизатор не получает Hello-сообщений в течении dead interval, то он считает соседа недоступным и информирует об этом других соседей домена (по умолчанию значение равно 40 секундам, т. е. четырём Hello-interval);
• Совпадение area-id;
• Совпадение параметров аутентификации;
• Совпадение флага, указывающего на принадлежность области к stub-area.

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

Два маршрутизатора соединены друг с другом напрямую, однако для интерфейса eth1 маршрутизатора R1 зададим MTU равным 1400, тогда как на eth1 маршрутизатора R2 MTU будет равен значению по умолчанию, т. е. 1500.

R1:

R2:

Проверим статус установления отношений соседства на R1:

Как видно из рисунка 6, маршрутизатор R1 обнаружил соседа R2, однако установление соседских отношений находится на стадии ExStart (завершение синхронизации LSDB соответствует статусу Full, что будет рассмотрено ниже). Можно заключить, что отношения соседства не установлены и обмен маршрутной информации не выполняется.

Попробуем найти причину, обратившись к логам R1 (команда /log print):

В части диагностики OSPF, лог-записи RouterOS, настроенные по умолчанию, достаточно информативны. Видно, что произвести обмен DBD не удаётся, поскольку не совпадает значение MTU: на локальном маршрутизаторе R1 выставлено значение 1400, а на удалённом R2 — 1500.

Зададим значение MTU на eth1-интерфейсе R1 равным 1500 и убедимся в том, что отношения соседства установились (команда /interface ethernet set ether1 mtu=1500):

Следует иметь в виду, что реализация протокола OSPF на оборудовании различных вендоров может отличаться. Так, например, на оборудовании Cisco отношения соседства не устанавливаются на secondary-адресах интерфейсов. Проверим работу RouterOS в данных условиях, добавив подсети, к которым принадлежат secondary-адреса, в OSPF (команда на R1 и R2 /routing ospf network add network=172.16.100.0/24 area=backbone).

Список соседей маршрутизатора R1:

На иллюстрации видно, что R1 установил соседские отношения с R2 по двум каналам связи, т.е. поведение протокола OSPF в Cisco IOS и RouterOS в этой части отличаются, что необходимо учитывать при построении гетерогенных сетей.

Как было упомянуто, при установлении отношений соседства маршрутизаторы проходят несколько стадий. Рассмотрим их подробнее:

1. Down. Состояние, в котором от соседа не принято Hello-пакета;
2. Init. Состояние, в котором получен Hello-пакет от соседа, однако двухсторонние отношения ещё не установлены, поскольку в полученных Hello-пакетах отсутствует собственный RID;
3. 2-Way. Состояние, в котором двухстороннее соединение считается установленным. Также на этом этапе происходит процесс выбора DR и BDR, который подробно рассматривается ниже. Важно понимать, что если в сегменте сети присутствует более 3 маршрутизаторов, то попытки перейти к следующим стадиям соседских отношений предпринимаются только с DR/BDR, т.е. каждый из DROther устанавливает отношения с другим DROther в состояние 2-Way;
4. ExStart. Маршрутизатор с более высоким RID становится master, второй — slave. Master назначает начальный номер для первого DBD-пакета и начинает обмен DBD;
5. Exchange. Маршрутизаторы обмениваются DBD о собственной LSDB;
6. Loading. Производится обмен маршрутной информацией с применением служебных пакетов LSR, LSU, LSAck;
7. Full. Синхронизация LSDB выполнена. В широковещательной сети каждый из DROther устанавливает Full-state соседство с DR и BDR.

Обратимся к схеме на рисунке 2 и спискам соседей на иллюстрациях 3 и 4. В данном примере R4 выбран в качестве DR, R3 — в качестве BDR, что подтверждает вывод команд: на рисунке 4 маршрутизатор R4 устанавливает Full-state отношения с каждым из маршрутизатором широковещательного сегмента, на рисунке 3 маршрутизатор R2 устанавливает Full-state отношения с R3 и R4 и 2-Way с R1, поскольку R1 и R2 являются DROther.

Для анализа установления соседских отношений можно использовать лог-записи, предварительно включив логирование для протокола OSPF (команда /system logging add topics=ospf action=memory), однако необходимо быть готовым к большому объёму записываемой информации.

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

Следует отметить, что выборы DR/BDR проходят на каждом из сегментов независимо, т.е. один и тот же маршрутизатор, подключенный к нескольким каналам связи, может быть DR на одном и не быть DR на другом, т.е. роль закрепляется не за устройством, а за интерфейсом.

Роли распределяются в соответствии с приоритетами интерфейсов: интерфейс с большим значением приоритета назначается DR, с меньшим — BDR, а остальные — DROther. В случае, если приоритеты интерфейсов совпадают, то выборы осуществляются исходя из RID: устройство с бОльшим RID назначается DR.

По умолчанию, значение приоритетов равно 1 и администратор вручную может назначить приоритет в диапазоне от 0 до 255. В случае, если выставлен приоритет равным 0, маршрутизатор не будет участвовать в выборах DR.

Если маршрутизатор, являющийся DR, выходит из строя, то BDR становится DR. При этом нет необходимости заново синхронизировать LSDB, т.к. все маршрутизаторы устанавливают соседские отношения как с DR, так и с BDR. Среди DROther будет выбран BDR в соответствии с принципами обозначенными выше.

Для демонстрации процесса выбора DR/BDR обратимся к следующей схеме:

Схема для демонстрации процесса выбора DR/BDR

Все пять маршрутизаторов помещены в магистральную область OSPF. Маршрутизаторы R1, R2, R3, R4 находятся в одном широковещательном домене, для которого выделена сеть 172.16.100.0/24.

Маршрутизатор R5 подключен напрямую к R4, для этого сегмента выделена сеть 172.16.50.0/24. Для eth1-интерфейса R1 вручную выставлено значение приоритета равным 100, для eth1-интерфейса R4 — 0.

R1:

R2:

R3:

R4:

R5:

Проанализируем вывод списка соседей на маршрутизаторе R4:

Из иллюстрации 11 видно, что в сегменте с четырьмя маршрутизаторами в качестве DR выбран R1, BDR — R3. R1 выбран в роли DR, поскольку для него явно задано значение приоритета, равным 100. При выборе BDR сравнивается значение RID и, поскольку R4 не участвует в выборах (приоритет eth1-интерфейса задан равным 0), то эта роль назначена R3.

В сегменте с двумя маршрутизаторами DR — R5, BDR — R4 по величинам RID. Таким образом R4 является DROther в первом канале связи и BDR во втором.

Изолируем R1 от сети, отключив интерфейс eth1 (команда /interface ethernet set ether1 disabled=yes) и проанализируем распределение ролей.

Вывод списка соседей на R4:

На иллюстрации 12 видно, что маршрутизатор R3 из BDR стал DR, а новым BDR назначен R2. Изолируем маршрутизатор R2 от сети, отключив интерфейс eth1:

Несмотря на то, что в первом сегменте осталось всего два маршрутизатора R3 и R4, R4 не присваивается роль BDR в соответствии с нулевым приоритетом. Восстановим схему, включив интерфейсы eth1 на R1 и R2 (команда /interface ethernet set ether1 disabled=no):

На иллюстрации 14 видно, что R3 сохранил за собой роль DR, несмотря на то, что в сети появилось устройство с большим приоритетом, т.е. в выборах DR нет преемственности для того, чтобы не запускать заново процесс синхронизации LSDB. BDR был выбран среди всех маршрутизаторов сегмента в соответствии с изложенными принципами и им был выбран R1, поскольку приоритет его интерфейса был выше, чем у R2.

Необходимо иметь в виду, что DR и BDR производят больше операций, чем DROther, что требует большей вычислительной мощности. Для маршрутизаторов с низкой аппаратной производительностью можно использовать нулевой приоритет на интерфейсе.

В первой части серии статей о протоколе OSPF рассмотрены теоретические основы протокола: представлена терминология и описаны основные этапы алгоритма работы OSPF с примерами конфигураций и методов диагностики.