Типы областей, возможности их взаиморасположения в схемах сетей и типы LSA, распространяемых в служебных сообщениях.
В первой части серии статей дано теоретическое описание основных процессов протокола OSPF.
В продолжении будет уделено внимание топологическим аспектам протокола: рассмотрены типы областей, возможности их взаиморасположения в схемах сетей и типы LSA, распространяемых в служебных сообщениях.
Маршрутная информация в OSPF распространяется через LSA-сообщения, помещаемые в служебные сообщения. В рамках протокола выделяют 7 типов LSA:
Если упростить предназначение всех LSA, то LSA type 1 и type 2 выстраивают топологию внутри area, LSA type 3 сообщает маршрутную информацию о соседних областях, LSA type 4,5,7 сообщают о внешних маршрутах.
Для пояснения принципов распространения LSA рассмотрим следующую схему:
В магистральную область помещены три маршрутизатора R1, R2, R4. Также, R2 и R4 имеют канал связи в областях 20 и 10 соответственно. Маршрутизатор R5, помещённый в область 10, имеет внешний канал связи в сеть 10.0.0.0/8.
Приглашаем пройти обучение в нашем тренинг-центре и научиться настраивать оборудование MikroTik на профессиональном уровне! Узнайте расписание ближайших курсов и бронируйте место!
R1:
/routing ospf instance set [ find default=yes ] router-id=1.1.1.1 /ip address add address=172.16.100.1/24 interface=ether1 network=172.16.100.0 /routing ospf network add area=backbone network=172.16.100.0/24 /system identity set name=R_1
R2:
/routing ospf area add area-id=0.0.0.20 name=area_20 /routing ospf instance set [ find default=yes ] router-id=2.2.2.2 /ip address add address=172.16.100.2/24 interface=ether1 network=172.16.100.0 add address=192.168.20.2/24 interface=ether4 network=192.168.20.0 /routing ospf network add area=area_20 network=192.168.20.0/24 add area=backbone network=172.16.100.0/24 /system identity set name=R_2
R3:
/routing ospf area add area-id=0.0.0.20 name=area_20 /routing ospf instance set [ find default=yes ] router-id=3.3.3.3 /ip address add address=192.168.20.3/24 interface=ether4 network=192.168.20.0 /routing ospf network add area=area_20 network=192.168.20.0/24 /system identity set name=R_3
R4:
/routing ospf area add area-id=0.0.0.10 name=area_10 /routing ospf instance set [ find default=yes ] router-id=4.4.4.4 /ip address add address=172.16.100.4/24 interface=ether1 network=172.16.100.0 add address=192.168.10.4/24 interface=ether4 network=192.168.10.0 /routing ospf network add area=backbone network=172.16.100.0/24 add area=area_10 network=192.168.10.0/24 /system identity set name=R_4
R5:
/routing ospf area add area-id=0.0.0.10 name=area_10 /routing ospf instance set [ find default=yes ] redistribute-connected=as-type-1 router-id=5.5.5.5 /ip address add address=192.168.10.5/24 interface=ether4 network=192.168.10.0 add address=10.0.0.5/8 interface=ether2 network=10.0.0.0 /routing ospf network add area=area_10 network=192.168.10.0/24 /system identity set name=R_5
Проанализируем список LSA на ABR R2 и R4:
На рисунке 16 видно, что в LSDB маршрутизатора R2 хранится 5 LSA type 1: три в backbone-area и два – в area 20. Причём LSA type 1 от маршрутизаторов R1 и R4 присутствуют в backbone, но отсутствуют в area 20. Это подтверждает, что Router LSA генерирует каждый маршрутизатор и они не распространяются в соседние области.
Число LSA type 2 соответствует числу каналов в областях, с которыми ассоциирован R2: один LSA type 2 генерирует R4, являющийся DR в сегменте 172.16.100.0/24 и один LSA type 2 формирует R3, который выбран DR в сегменте 192.168.20.0/24.
В backbone-area распространяется два LSA type 3 с информацией о сетях 192.168.10.0/24 от R4 и 192.168.20.0/24 от R2. Следует отметить, что при прохождении LSA type 3 через область у него подменяется источник. Так, источником LSA type 3 с информацией о сети 192.168.10.0/24 для area 20 является R2, а не R4, как в backbone.
Особняком в LSDB располагаются LSA type 5: поскольку данные сообщения распространяются через все области в неизменном виде, то их не ассоциируют с конкретной областью, а выделяют в отдельную категорию “external”. На иллюстрациях 16 и 17 видно, что в базе данных присутствует LSA type 5 от R5 с информацией о сети 10.0.0.0/8, т.е. R5 сгенерировал LSA type 5 в area 10, а оно распространилось через R4-R2 в область area 20.
Маршрутизатор R2, получив LSA type 5, ничего не знает о местонахождении R5, т.к. маршрутизатор расположен в другой области, а LSA type 1 с информацией о R5 не выходят за пределы area 10. Для решения этой проблемы маршрутизатор R4, являясь ABR, генерирует LSA type 4 для backbone area, что видно на иллюстрации 17.
Тем самым R4 рассказывает всем маршрутизатором backbone area о том, что R4 знает о расположении ASBR R5. Маршрутизатор R2, получив LSA type 4, подобно LSA type 3, распространяет его в area 20, но заменив источник сообщения на свой RID.
Также следует обратить внимание на то, что в area 10 отсутствует LSA type 4, поскольку маршрутизаторы этой области знают о местонахождении R5 из LSA type 1 и type 2.
Продемонстрируем таблицу маршрутизации R1:
Из иллюстрации 18 видно, что в таблице маршрутизации R1 есть маршрут к каждой из сетей нашей схемы, что справедливо и для остальных устройств OSPF-домена.
Для того, чтобы объяснить смысл LSA type 7, сконфигурируем area 10 как NSSA (команда на R4 и R5 /routing ospf area set [find name=area_10] type=nssa):
На иллюстрации 19 видно, что маршрутизатор R5 анонсирует внешнюю сеть 10.0.0.0/8 в area 10 используя LSA type 7. Поскольку LSA type 7 существуют только в рамках NSSA области, то маршрутизатор R4 передаёт данную маршрутную информацию в backbone area посредством LSA type 5. Таким образом, для всех остальных областей маршрутизатор R4 становится ASBR.
Также следует обратить внимание, что в рамках area 10 существует маршрут по умолчанию, анонсируемый R4 через LSA type 7. Это объясняется спецификой NSSA областей и будет рассмотрено ниже.
В RouterOS есть возможность детализации LSA (команда /routing ospf lsa print detail):
На иллюстрации 20 представлена детализация LSA type 1 и type 2 на маршрутизаторе R4. Видно, что в LSA type 1, формируемом R4, маршрутизатор говорит о том, что он является ASBR, его ip-адрес в backbone area 172.16.100.4 и RID=4.4.4.4, а в LSA type 2 перечисляет RID всех маршрутизаторов сегмента R1, R2, R4 и указывает используемую маску – 255.255.255.0.
Следует отметить, что RouterOS не позволяет удалить из конфигурации backbone area, т.е. в конфигурации R3 фактически представлены две области, backbone и area 20, но в рамках данной задачи используется только area 20.
Деление на области OSPF-домена, как уже было сказано, производится с целью снижения передаваемой маршрутной информации и уменьшения числа пересчётов SPT. Для идентификации номеров областей выделяется 32-битное число, которое может записываться либо в виде числа десятичной системы счисления, либо в форме ip-адреса.
В протоколе OSPF выделяют следующие типы областей:
Сконфигурируем area 20 как stub (команда /routing ospf area set [find name=area_20] type=stub) и проанализируем LSDB маршрутизатора R3:
По сравнению с рисунком 16, в area 20 исчезли LSA type 5, но появился новый LSA type 3 с маршрутом по умолчанию. Стоит отметить, что LSA type 3, присутствующие ранее с информацией о сетях 172.16.100.0/24 и 192.168.10.0/24 в LSDB присутствуют.
Изменим тип area 20 на totally stubby area. В RouterOS нет данного типа области в явном виде, однако его можно задать, изменив один из параметров для stub area (команда /routing ospf area set [find name=area_20] inject-summary-lsas=no). Проанализируем LSDB маршрутизатора R3:
По сравнению со stub area из LSDB исчезли LSA type 3 с информацией о сетях в других областях, однако LSA type 3 с маршрутом по умолчанию по-прежнему присутствует в базе данных. При этом таблица маршрутизации R3 будет выглядеть следующим образом:
В таблице маршрутизации присутствует только маршрут к непосредственно подключенной сети 192.168.20.0/24 и маршрут по умолчанию в сторону R2, выступающим в роли ABR для area 20.
В терминологии Cisco выделяется ещё один тип области - Totally-NSSA, в котором, в отличие от NSSA, отсутствуют LSA type 3 с маршрутной информацией из других областей, а маршрут по умолчанию передаётся в LSA type 3. Получить Totally-NSSA в RouterOS можно, выполнив следующую команду при конфигурации области: /routing ospf area set [find name=area_name] type=nssa inject-summary-lsas=no.
Согласно концепции OSPF, все области должны быть непосредственно подключены к backbone area, т.е. любые две области обмениваются маршрутами через магистральную область. Для того, чтобы преодолеть данное ограничение в протоколе предусмотрен инструмент виртуального канала (virtual link).
Виртуальный канал – это логическое соединение OSPF области с backbone area через другую область. Данный канал организуется на двух ABR: первый находится на стыке магистральной области с транзитной и называется точкой входа (entry point), а второй на стыке транзитной и присоединяемой областей. В этом случае организуется канал, который эмулирует непосредственное присоединение удалённой области к backbone.
Следует иметь в виду, что тип транзитной области обязательно должен быть standard – построение виртуального канала через stub и nssa области невозможно.
Обратимся к следующей схеме для демонстрации принципов работы виртуального канала:
В сети выделено три области: магистральная, область 10 и область 20. Маршрутизаторы R2 и R3 являются ABR, находясь на стыках двух областей. Маршрутизатор R4 имеет непосредственно подключенный канал во внешнюю сеть 10.4.4.0/24. Пусть в начальной конфигурации отсутствуют настройки виртуального канала.
R1:
/routing ospf instance set [ find default=yes ] router-id=1.1.1.1 /ip address add address=172.16.100.1/24 interface=ether1 network=172.16.100.0 /routing ospf network add area=backbone network=172.16.100.0/24 /system identity set name=R_1
R2:
/routing ospf area add area-id=0.0.0.10 name=area_10 /routing ospf instance set [ find default=yes ] router-id=2.2.2.2 /ip address add address=172.16.100.2/24 interface=ether1 network=172.16.100.0 add address=192.168.10.2/24 interface=ether2 network=192.168.10.0 /routing ospf network add area=backbone network=172.16.100.0/24 add area=area_10 network=192.168.10.0/24 /system identity set name=R_2
R3:
/routing ospf area add area-id=0.0.0.10 name=area_10 add area-id=0.0.0.20 name=area_20 /routing ospf instance set [ find default=yes ] router-id=3.3.3.3 /ip address add address=192.168.10.3/24 interface=ether2 network=192.168.10.0 add address=192.168.20.3/24 interface=ether3 network=192.168.20.0 /routing ospf network add area=area_10 network=192.168.10.0/24 add area=area_20 network=192.168.20.0/24 /system identity set name=R_3
R4:
/routing ospf area add area-id=0.0.0.20 name=area_20 /routing ospf instance set [ find default=yes ] redistribute-connected=as-type-1 router-id=4.4.4.4 /ip address add address=192.168.20.4/24 interface=ether3 network=192.168.20.0 add address=10.4.4.4/24 interface=ether1 network=10.4.4.0 /routing ospf network add area=area_20 network=192.168.20.0/24 /system identity set name=R_4
Проанализируем LSDB и FIB на R1:
В LSDB, ожидаемо присутствуют LSA type 1 и 2 из магистральной области. Также присутствует LSA type 3 с информацией о сети в area 10, который формирует ABR R2.
Поскольку LSA type 5 распространяются через весь OSPF-домен, то в базе данных R1 присутствует сообщение данного типа с информацией о внешней сети от R4, однако отсутствует LSA type 4 и R1 не знает о местонахождении источника LSA type 5. Кроме того, отсутствует маршрутная информация о сети 192.168.20.0/24.
Настроим виртуальный канал между R2 и R3, выполнив следующие команды:
R2:
/routing ospf virtual-link add transit-area=area_10 neighbor-id=3.3.3.3
R3:
/routing ospf virtual-link add transit-area=area_10 neighbor-id=2.2.2.2
Иллюстрация 26 подтверждает, что после настройки виртуального канала, на R1 появились все необходимые LSA и, соответственно, в таблице маршрутизации появились маршруты ко всем сетям схемы. Следует обратить внимание на то, что, поскольку area 20 логически подсоединена непосредственно к backbone, то и R2 и R3 передают LSA type 3 с информацией о сети 192.168.10.0/24.
Возможны схемы сети, в которых backbone area делится на несколько частей и соединена посредством виртуальных каналов. В этом случае, по аналогии с рассмотренным случае, виртуальный канал строится между двумя ABR, находящихся на стыке участков магистральной и транзитной областей.
В отличие от магистральной области, которая должна быть одна в рамках OSPF-домена, соединение участков немагистральных областей через виртуальные каналы не является обязательным требованием к схеме сети.
Усложним схему сети на рисунке 24, добавив ещё один маршрутизатор, помещённый в area 30:
В конфигурации маршрутизаторов, относительно примера выше, вносятся следующие изменения:
R3:
/ routing ospf virtual-link add transit-area=area_20 neighbor-id=4.4.4.4
R4:
/routing ospf area add area-id=0.0.0.30 name=area_30 /ip address add address=192.168.30.4/24 interface=ether4 network=192.168.30.0 /routing ospf network add area=area_30 network=192.168.30.0/24 /routing ospf virtual-link add neighbor-id=3.3.3.3 transit-area=area_20
R5:
/routing ospf area add area-id=0.0.0.30 name=area_30 /routing ospf instance set [ find default=yes ] redistribute-connected=as-type-1 router-id=5.5.5.5 /ip address add address=192.168.30.5/24 interface=ether4 network=192.168.30.0 add address=10.5.5.5/24 interface=ether1 network=10.5.5.0 /routing ospf network add area=area_30 network=192.168.30.0/24 /system identity set name=R_5
Area 30 удалена от backbone на две области, area 10 и 20, однако, несмотря на это, R1 получил список LSA со всеми используемыми сетями, что подтверждает таблица маршрутизации.
Таким образом, в случае необходимости, возможно построение OSPF-топологий с удалёнными от backbone областями, однако это не является общепринятой практикой и подобных схем необходимо избегать.
Во второй части серии статей о протоколе OSPF рассмотрены типы областей, выделяемых в протоколе, типы LSA с их функциональным предназначением и распространением в областях разного типа. Также рассмотрен механизм использования виртуального канала для присоединения отдалённых областей к backbone area.