Механизмы фильтрации и суммирования маршрутов, а также использования пассивных интерфейсов.
В заключительной, четвёртой, части серии статей о протоколе OSPF будут рассмотрены механизмы фильтрации и суммирования маршрутов, а также использования пассивных интерфейсов.
Также будет рассмотрен пример использования OSPF в отказоустойчивых схемах и использование протокола BFD для увеличения скорости сходимости.
В RouterOS реализован механизм фильтрации маршрутов для гибкой конфигурации входящей и исходящей маршрутной информации. Для OSPF используются две цепочки: ospf-in для входящих маршрутов и ospf-out для исходящих. Используемые цепочки фильтрации указываются в настройках instance.
Для создания простейших фильтров достаточно указать три параметра:
В цепочку ospf-out маршрутная информация попадёт только в том случае, если маршрутизатор сам является источником этого LSA, т.е. в случае, если один из маршрутизаторов AS фильтрует исходящий маршрут, полученный от ASBR, то передаваемый LSA type 5 не будет попадать в цепочку фильтрации.
Для фильтрации маршрутов, как и для ACL, существует рекомендация по настройке фильтров в точках ближайших к источникам этой информации. Это позволяет отбрасывать нежелательные маршруты как можно раньше, не используя ресурсы сети на их распространение. Признаком хорошего тона считается конфигурация фильтров исключительно по отношению к внешним маршрутам.
Рассмотрим следующую схему:
На представленной схеме присутствуют четыре маршрутизатора, помещённые в одну магистральную область. Маршрутизатор R4 подключен к двум внешним сетям 192.168.10.0/24 и 192.168.20.0/24, маршруты к которым он инжектирует в OSPF, как E1.
Пусть стоит задача, фильтровать для пользователей маршрутизаторов R2 и R3 маршрут к сети 192.168.10.0/24 и для пользователей R3, дополнительно, маршрут к сети 192.168.20.0/24. На R1 при этом должны присутствовать маршруты к обеим внешним сетям.
Попробуем решить задачу, фильтруя исходящую маршрутную информацию на R1 о сети 192.168.10.0/24 и входящий маршрут на R3 к сети 192.168.20.0/24. Конфигурация оборудования:
Приглашаем пройти обучение в нашем тренинг-центре и научиться настраивать оборудование 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=ether2 network=172.16.100.0 add address=172.16.50.1/24 interface=ether3 network=172.16.50.0 add address=172.16.150.1/24 interface=ether1 network=172.16.150.0 /routing filter add action=discard chain=ospf-out prefix=192.168.10.0/24 /routing ospf network add area=backbone network=172.16.100.0/24 add area=backbone network=172.16.50.0/24 add area=backbone network=172.16.150.0/24 /system identity set name=R_1
R2:
/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 /routing ospf network add area=backbone network=172.16.100.0/24 /system identity set name=R_2
R3:
/routing ospf instance set [ find default=yes ] router-id=3.3.3.3 /ip address add address=172.16.50.3/24 interface=ether1 network=172.16.50.0 /routing filter add action=discard chain=ospf-in prefix=192.168.20.0/24 /routing ospf network add area=backbone network=172.16.50.0/24 /system identity set name=R_3
R3:
/routing ospf instance set [ find default=yes ] redistribute-connected=as-type-1 router-id=4.4.4.4 /ip address add address=172.16.150.4/24 interface=ether1 network=172.16.150.0 add address=192.168.10.4/24 interface=ether2 network=192.168.10.0 add address=192.168.20.4/24 interface=ether4 network=192.168.20.0 /routing ospf network add area=backbone network=172.16.150.0/24 /system identity set name=R_4
Проанализируем таблицу маршрутизации и LSDB на R3:
На приведённой иллюстрации видим, что маршрутизатор получает LSA type 5 с информацией о сетях 192.168.10.0/24 и 192.168.20.0/24, несмотря фильтрацию исходящих маршрутов R1. Это происходит потому что R1 не является источников данных сообщений. Стоит отметить, что несмотря на присутствие LSA type 5 о двух внешних каналах, в таблицу маршрутизации добавляется только маршрут к сети 192.168.10.0/24, т.к. срабатывает входящий фильтр ospf-in, отклоняющий маршрут к сети 192.168.20.0/24.
Изменим конфигурацию устройств для решения поставленной выше задачи и проанализируем таблицы маршрутизации R2 и R3:
R1:
/routing filter remove [find chain=ospf-out]
R2 и R3:
/routing filter add chain=ospf-in prefix=192.168.10.0/24 action=discard
Таблица маршрутизации R2 при фильтрации 192.168.10.0/24
Таблица маршрутизации R3 при фильтрации 192.168.10.0/24 и 192.168.20.0/24
Из иллюстраций видно, задача выполнена и в таблице маршрутизации R3 отсутствуют внешние маршруты, при этом внутренние присутствуют, а в таблице R2 отсутствует только маршрут к 192.168.10.0/24.
Под суммированием маршрутов в протоколах маршрутизации понимается преобразование нескольких маршрутов с более узкой маской в один с более широкой, например, вместо четырёх маршрутов в сети 10.0.0-3.0/24 будет сформирован один маршрут в сеть 10.0.0.0/22.
Выделяют два типа суммирования маршрутов:
Рекомендация по суммированию заключается в том, чтобы суммировать маршруты по направлению к backbone area для того, чтобы из магистральной области в другие области распространялся один LSA о суммированных сетях вместо нескольких.
Суммирование маршрутов настраивается в разделе “/routing ospf area range” и имеет следующие настройки:
| Параметр | Описание | Возможные значения | Значения по умолчанию |
| advertise | Формирование LSA о суммированных сетях | yes/no | yes4 |
| area | Область, ассоциированная с данным диапазоном | — | — |
| cost | Стоимость нового LSA | 1-65535 | Наибольшая стоимость среди всех объединяемых LSA |
| range | Сеть, которая будет указана в новом LSA. Все LSA, попадающие данный диапазон будут заменены новым. | — | — |
Рассмотрим схему, в которой реализуем суммирование inter-area маршрутов:
В OSPF-домене выделено две области: backbone с внутренним маршрутизатором R1 и area 10. R2 установлен на стыке областей и является ABR. Помимо интерфейса в сторону R1, интерфейсы R2 ассоциированы с сетями 192.168.0-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=ether6 network=172.16.100.0 add address=192.168.0.2/24 interface=ether1 network=192.168.0.0 add address=192.168.1.2/24 interface=ether2 network=192.168.1.0 add address=192.168.2.2/24 interface=ether3 network=192.168.2.0 add address=192.168.3.2/24 interface=ether4 network=192.168.3.0 add address=192.168.4.2/24 interface=ether5 network=192.168.4.0 /routing ospf network add area=backbone network=172.16.100.0/24 add area=area_10 network=192.168.0.0/24 add area=area_10 network=192.168.1.0/24 add area=area_10 network=192.168.2.0/24 add area=area_10 network=192.168.3.0/24 add area=area_10 network=192.168.4.0/24 /system identity set name=R_2
Таблица маршрутизации и LSDB на R1 до настройки суммирования
На рисунке представлены FIB и LSDB маршрутизатора R1. Видно, что R2 анонсирует в backbone area пять LSA type 3 с информацией о подключенных сетях 192.168.0-4.0/24. Полученные LSA экспортируются в таблицу маршрутизации.
Настроим суммирование маршрутов на ABR, объединив маршрутную информацию о сетях 192.168.0.0/24 и 192.168.1.0/24. Для этого выполним на R2 следующую команду: /routing ospf area range add advertise=yes area=area_10 range=192.168.0.0/23/.
Таблица маршрутизации и LSDB на R1 с суммированием диапазона 192.168.0.0/23:
На иллюстрации видно, что вместо двух маршрутов к сетям 192.168.0.0/24 и 192.168.1.0/24, в LSA R2 анонсирует один маршрут к сети 192.168.0.0/23.
Расширим маску для суммированного маршрута, выполнив на ABR следующую команду:
/routing ospf area range set [find range=192.168.0.0/23] range=192.168.0.0/21
На иллюстрации видно, что R2 стал анонсировать один LSA type 3 вместо исходных пяти. Таким образом, с помощью суммирования маршрутов на ABR удалось сократить пересылаемую маршрутную информацию, а также число записей таблицы маршрутизации.
Однако, у демонстрируемого решения есть скрытый недостаток: согласно таблице маршрутизации, R1 считает, что сеть 192.168.0.0/21 расположена за R2, т.е. неиспользуемые сети 192.168.5-7.0/24 также, с точки зрения R1, располагаются за R2. Таким образом, при расширении сети и использовании указанных сетей, могут возникнуть проблемы с маршрутизацией.
При построении сети возможны ситуации, когда необходимо анонсировать в OSPF тупиковую“ сеть, в которой отсутствуют устройства, с которыми необходимо устанавливаться соседские отношения. Добавляя данную подсеть в OSPF на маршрутизаторе, мы запускаем процесс обнаружения соседей по Hello-протоколу на интерфейсе в сторону этой сети.
Чтобы снизить служебный трафик и ресурсы маршрутизатора на формирование сообщений OSPF, интерфейсы в такие сегменты сети можно объявить как пассивные. В этом случае маршрутизатор не будет отправлять и принимать OSPF-трафик на данном интерфейсе, при этом данная сеть будет анонсироваться с других OSPF-интерфейсов.
Схема сети для примера использования пассивных интерфейсов:
В схеме присутствует три маршрутизатора, помещённые в магистральную область и подключенные по цепочке R1-R2-R3. Интерфейсы eth4 маршрутзаторов R2 и R3 подключены к сетям 10.0.10.0/24 и 10.0.20.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 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=172.16.50.2/24 interface=ether2 network=172.16.50.0 add address=10.0.10.2/24 interface=ether4 network=10.0.10.0 /routing ospf network add area=backbone network=172.16.100.0/24 add area=backbone network=172.16.50.0/24 add area=backbone network=10.0.10.0/24 /system identity set name=R_2
R3:
/routing ospf instance set [ find default=yes ] router-id=3.3.3.3 /ip address add address=172.16.50.3/24 interface=ether2 network=172.16.50.0 add address=10.0.20.3/24 interface=ether4 network=10.0.20.0 /routing ospf network add area=backbone network=10.0.20.0/24 add area=backbone network=172.16.50.0/24 /system identity set name=R_3
Проанализируем FIB на маршрутизаторе R1 и список соседей на R2.
Таблица маршрутизации на R1:
Вывод списка соседей на R2:
На иллюстрациях видно, что маршрутизатор R2 устанавливает соседские отношения с R1 и R2 в состоянии Full, в таблице маршрутизации R1 присутствуют записи о всех известных сетях AS.
Сконфигурируем интерфейсы eth2 и eth4 на маршрутизаторе R2 как пассивные (команда /routing ospf interface add interface=ether2 passive=yes, /routing ospf interface add interface=ether4 passive=yes) и повторно проанализируем вывод.
Таблица маршрутизации на R1:
Вывод списка соседей на R2:
На иллюстрациях видно, что R2 и R3 разорвали соседские отношения, что подтверждает R1, который удалил из FIB маршрут к сети 10.0.20.0/24, расположенной за R3. Дело в том, что после объявления интерфейса eth2 маршрутизатора R2 в роли пассивного, был запрещён трафик Hello-протокола на канале между R2 и R3.
Как следствие, спустя Dead-interval, R2 и R3 признал друг друга недоступными и разорвали соседские отношения, удалив полученную от соседей маршрутную информацию из LSDB, SPT, FIB.
Следует обратить внимание, что маршрут к сетям 10.0.10.0/24 и 172.16.50.0/24 присутствует в таблице маршрутизации R1, несмотря на то, что интерфейсы, ассоциированные с этими сетями, отмечены как пассивные.
Исправим ошибки в приведённой конфигурации: поскольку за интерфейсами eth4 маршрутизаторов R2 и R3, согласно схеме, присутствуют только пользовательские устройства и отсутствуют OSPF-маршрутизаторы, то такие интерфейсы можно отметить как пассивные. Выполним следующие команды и повторим вывод FIB и списка соседей:
R2:
/routing ospf interface set [find interface=ether2] passive=no
R3:
/routing ospf interface add interface=ether4 passive=yes
Таблица маршрутизации на R1:
Вывод списка соседей на R2:
Рассмотрим простейшую схему с резервированием. Три маршрутизатора соединены по кругу друг с другом, т.е. один из каналов является избыточным. За маршрутизаторами R1 и R3 есть клиентские устройства в сетях 192.168.10.0/24 и 192.168.30.0/24 соответственно. На канале, соединяющем R1 и R2 настроена повышенная стоимость, чтобы этот канал являлся резервным.
Простейшая схема с резервированием:
R1:
/routing ospf instance set [ find default=yes ] router-id=1.1.1.1 /ip address add address=172.16.100.1/24 interface=ether2 network=172.16.100.0 add address=172.16.50.1/24 interface=ether3 network=172.16.50.0 add address=192.168.10.1/24 interface=ether4 network=192.168.10.0 /routing ospf interface add cost=100 interface=ether2 add interface=ether4 passive=yes /routing ospf network add area=backbone network=172.16.100.0/24 add area=backbone network=172.16.50.0/24 add area=backbone network=192.168.10.0/24 /system identity set name=R_1
R2:
/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=172.16.150.2/24 interface=ether3 network=172.16.150.0 /routing ospf interface add cost=100 interface=ether1 /routing ospf network add area=backbone network=172.16.100.0/24 add area=backbone network=172.16.150.0/24 /system identity set name=R_2
R3:
/routing ospf instance set [ find default=yes ] router-id=3.3.3.3 /ip address add address=172.16.150.3/24 interface=ether2 network=172.16.150.0 add address=172.16.50.3/24 interface=ether1 network=172.16.50.0 add address=192.168.30.3/24 interface=ether4 network=192.168.30.0 /routing ospf interface add interface=ether4 passive=yes /routing ospf network add area=backbone network=192.168.30.0/24 add area=backbone network=172.16.50.0/24 add area=backbone network=172.16.150.0/24 /system identity set name=R_3
В текущей схеме пакеты с PC1 будут идти к PC3 по пути PC1-R1-R3-PC3, поскольку стоимость канала на R1 в сторону R2 выше, чем в сторону R3.
Вывод проверки доступности PC3 с PC1:
На иллюстрации видно, что в процессе проверки потерялось два пакета. В этот момент в таблице маршрутизации R1 изменился маршрут к PC3 — теперь пакеты отправляются в сторону R2 и идут по пути PC1-R1-R2-R3-PC3, что демонстрируется на рисунке ниже. Проверка маршрута к PC3 на R1:
Преобразуем схему с резервированием, установив в разрыв между R1 и R3 коммутатор. Конфигурацию устройств приведём к начальной, т.е. включим интерфейс eth1 на R3 (команда /interface ether set ether1 disabled=no):
Простейшая схема с резервированием с добавлением коммутатора:
Повторим манипуляции: запустим проверку доступности PC3 с PC1, отключив в процессе проверки интерфейс eth3 на SW1:
В процессе проверки доступности, как видно на рисунке, пропало 18 пакетов. Обратив внимание на параметр ttl, можно сказать, что ситуация предыдущего примера повторилась и пакеты стали ходить по пути PC1-R1-R2-R3-PC3, однако на перестроение таблицы маршрутизации R1 потребовалось больше времени.
Данная ситуация возникает потому что при отключении интерфейса на R3, R3 тут же совершает соседям рассылку LSU, в которых сообщает о недоступности канала связи. Данный LSU доходит до R1 через R2 и маршрутизатор корректирует LSDB и FIB, пуская пакеты по другому каналу связи. Во втором примере становится недоступным интерфейс на коммутаторе и маршрутизаторы, участвующие в OSPF об этом не знают. R1 обновит LSDB в тот момент, когда не будет принято ни одного Hello-пакета от R3, т.е. в течении Dead-interval, что в настройках по умолчанию может достигать сорока секунд.
Для того, чтобы уменьшить время обнаружения потери связи на сети, можно использовать протокол BFD.
BFD (Bidirectional Forwarding Detection) — протокол двусторонней проверки связи) – протокол, предназначенный для обнаружения неисправности каналов. В отличие от подобных механизмов в протоколах маршрутизации, является более “лёгким” с точки зрения трафика.
BFD работает независимо от среды, протоколов данных и протоколов маршрутизации. Служебные пакеты BFD помещаются в UDP-дейтаграммы с портом назначения 3784 и динамически определяемым портом отправителя в диапазоне 49152-65535. По сути, является hello-протоколом обнаружения соседа, но с меньшими значениями таймеров и описан в RFC 5880, 5881, 5882.
Настройки BFD расположены в меню /routing bfd interface. Основные параметры настройки:
| Параметр | Описание | Возможные значения | Значения по умолчанию |
| interface | список интерфейсов, на которых будет запущен BFD | — | all |
| interval | интервал отправки служебных сообщений | 0.01-10 секунд | 0.2 секунды |
| min-rx | минимальный интервал между принимаемыми сообщениями | 0.01-10 секунд | 0.2 секунды |
| multiplier | Число непринятых пакетов, после которых канал будет считаться недоступным | 1-100 пакетов | 5 пакетов |
Вернёмся к схеме
— включим интерфейс eth3 на SW1 и настроим работу протокола BFD, выполнив следующие команды:
R1:
/routing ospf interface add interface=ether3 /routing ospf interface set [find interface=ether2] use-bfd=yes /routing ospf interface set [find interface=ether3] use-bfd=yes
R2:
/routing ospf interface add interface=ether3 /routing ospf interface set [find interface=ether1] use-bfd=yes /routing ospf interface set [find interface=ether3] use-bfd=yes
R3:
/routing ospf interface add interface=ether1 use-bfd=yes /routing ospf interface add interface=ether2 use-bfd=yes
Проверим соседские отношения по BFD на R1:
Теперь вновь запустим процесс проверки доступности PC3 с PC1 и отключим интерфейс eth3 на SW1:
Как видно на рисунке, при проверке было потеряно два пакета, т.е. использование BFD помогает серьёзно ускорить процесс проверки доступности каналов связи и перестроения таблицы маршрутизации.
В заключительной части статьи представлены описание и примеры конфигураций схем с фильтрацией и суммированием маршрутной информации. Рассмотрены примеры схем с применением пассивных интерфейсов и указана целесообразность их применения.
В завершении серии статей представлена схема использования OSPF в избыточной топологии для повышения отказоустойчивости. Отдельное внимание уделено скорости сходимости алгоритма и представлены рекомендации по увеличению скорости сходимости.