Меню
Контакты
109147, Москва, ул.Воронцовская, 35Б, корп.2 офис.11, 4 этаж
Пн-Пт: с 9-00 до 17-00   Сб-вс: выходной
Интернет-магазин
сетевого оборудования
Москва +7 (495) 103-41-03 +7 (915) 420-28-94
109147, Москва, ул.Воронцовская, 35Б, корп.2 офис.11, 4 этаж
Пн-Пт: с 9-00 до 17-00   Сб-вс: выходной
Заказать звонок

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

 10 Май 2018    MikroTik, О настройках и установке оборудования производителя Mikrotik, Практика и программирование MikroTik

Типы областей, возможности их взаиморасположения в схемах сетей и типы LSA, распространяемых в служебных сообщениях.

Введение

В продолжении будет уделено внимание топологическим аспектам протокола: рассмотрены типы областей, возможности их взаиморасположения в схемах сетей и типы LSA, распространяемых в служебных сообщениях.

Типы LSA

Маршрутная информация в OSPF распространяется через LSA-сообщения, помещаемые в служебные сообщения. В рамках протокола выделяют 7 типов LSA:

  • Type 1 — router LSA. Сообщения, распространяемые всеми маршрутизаторами внутри области, которые содержат информацию о непосредственно подключенных каналах, их стоимости и соседях на этих каналах. LSA не передаются в другие области через ABR и ASBR.
  • Type 2 — Network LSA. Сообщения распространяет маршрутизатор, выбранный DR, внутри области. В них содержится информация о всех маршрутизаторах, подключенных к сети и маска сети. Аналогично LSA type 1, сообщения не передаются в другие области.
  • Type 3 — Summary LSA. Данный тип сообщений генерирует ABR, включая туда информацию о сетях соседней области. Тем самым обеспечивается обмен маршрутной информацией между зонами. Следует понимать, что маршрутизатор одной области, получив LSA type 3, не может построить схему соединений маршрутизаторов в соседней области, а только знает о том, что список сетей соседней зоны находятся за ABR.
  • Type 4 — ASBR Summary LSA. Сообщение содержит адрес ASBR для областей, с которыми данный ASBR не ассоциирован. Сообщение генерирует ABR.
  • Type 5 — External LSA. Сообщение содержит информацию о внешних маршрутах для OSPF-домена. Маршруты могут быть изучены с помощью другого протокола динамической маршрутизации, прописаны статично и непосредственно присоединены. Данный тип сообщений генерирует ASBR и в неизменном виде распространяется сквозь все области.
  • Type 6 — Group Membership LSA. Определяет Multicast-расширение для OSPF. В RouterOS данный тип сообщений не поддерживается.
  • Type 7 — Type 7 LSA. Данный тип сообщений является аналогом LSA type 5, которые распространяются в NSSA областях.

Если упростить предназначение всех LSA, то LSA type 1 и type 2 выстраивают топологию внутри area, LSA type 3 сообщает маршрутную информацию о соседних областях, LSA type 4,5,7 сообщают о внешних маршрутах.

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

Схема сети для демонстрации типов LSA

В магистральную область помещены три маршрутизатора R1, R2, R4. Также, R2 и R4 имеют канал связи в областях 20 и 10 соответственно. Маршрутизатор R5, помещённый в область 10, имеет внешний канал связи в сеть 10.0.0.0/8.

Конфигурация устройств

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:

Список LSA на R2 Список LSA на 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:

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

Из иллюстрации 18 видно, что в таблице маршрутизации R1 есть маршрут к каждой из сетей нашей схемы, что справедливо и для остальных устройств OSPF-домена.

Для того, чтобы объяснить смысл LSA type 7, сконфигурируем area 10 как NSSA (команда на R4 и R5 /routing ospf area set [find name=area_10] type=nssa):

Список LSA на R4 в 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):

Фрагмент детализации LSDB на R4

На иллюстрации 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.

Типы Area

Деление на области OSPF-домена, как уже было сказано, производится с целью снижения передаваемой маршрутной информации и уменьшения числа пересчётов SPT. Для идентификации номеров областей выделяется 32-битное число, которое может записываться либо в виде числа десятичной системы счисления, либо в форме ip-адреса.

В протоколе OSPF выделяют следующие типы областей:

  • Standard area. Нормальная область не имеет отличительных признаков: может содержать ABR, ASBR и в LSDB может содержать все типы LSA. В конфигурации RouterOS для обозначения нормальных областей используется type=default;
  • Backbone area. Магистральная область является частным случаем нормальной, имея идентификатор 0.0.0.0. По умолчанию на всех маршрутизаторах RouterOS такая область присутствует в конфигурации. Все остальные области должны пристыковываться к backbone area;
  • Stub area. Тупиковая область отличается тем, что в этой области не может находиться ASBR. Кроме того, в такие области не распространяются LSA type 5 с маршрутной информацией о внешних каналах связи, однако, вместо этого, ABR инжектирует в область LSA type 3 с маршрутом по умолчанию;
  • Totally stubby area. Совсем тупиковая область отличается от stub area тем, что в неё не попадают LSA type 3 с маршрутной информацией о соседних областях, однако ABR обязательно формирует LSA type 3 с маршрутом по умолчанию. Использование stub и totally stubby area позволяет существенно уменьшить LSDB в области и, как следствие, размер таблицы маршрутизации;
  • NSSA (not-so-stubby-area). Не совсем тупиковая область является аналогом stub area с тем отличием, что может содержать ASBR, однако в рамках этой области внешняя маршрутная информация будет передаваться в LSA type 7, а при выходе в другую область ABR преобразует этот LSA в type 5, указывая себя в качестве источника. Кроме того маршрут по умолчанию, передаваемый в stub area в LSA type 3, в данном типе областей передаётся в LSA type 7.
Особенности распространения LSA в standard area и NSSA были рассмотрены в предыдущем разделе. Обратимся к схеме на рисунке 15 для анализа поведения stub и totally stubby area, имея в виду, что область 10 сконфигурирована как standard.

Сконфигурируем area 20 как stub (команда /routing ospf area set [find name=area_20] type=stub) и проанализируем LSDB маршрутизатора R3:

Список LSA на R3 в stub area

По сравнению с рисунком 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:

Список LSA на R3 в totally stubby area

По сравнению со stub area из LSDB исчезли LSA type 3 с информацией о сетях в других областях, однако LSA type 3 с маршрутом по умолчанию по-прежнему присутствует в базе данных. При этом таблица маршрутизации R3 будет выглядеть следующим образом:

Таблица маршрутизации R3 в totally stubby area

В таблице маршрутизации присутствует только маршрут к непосредственно подключенной сети 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.

Virtual Link

Согласно концепции 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 и 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
Вывод LSDB и FIB на R1

Иллюстрация 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
Вывод LSDB и FIB на R1

Area 30 удалена от backbone на две области, area 10 и 20, однако, несмотря на это, R1 получил список LSA со всеми используемыми сетями, что подтверждает таблица маршрутизации.

Таким образом, в случае необходимости, возможно построение OSPF-топологий с удалёнными от backbone областями, однако это не является общепринятой практикой и подобных схем необходимо избегать.

Заключение

Во второй части серии статей о протоколе OSPF рассмотрены типы областей, выделяемых в протоколе, типы LSA с их функциональным предназначением и распространением в областях разного типа. Также рассмотрен механизм использования виртуального канала для присоединения отдалённых областей к backbone area.

Источник