В 28.12.2012 в 19:23, chetkiyparen сказал:
Добрый день!
Наблюдаю последнее время в логах микротикам подобные ошибки:
bfd error discarding BFD packet: unsupported verion 3
length in packet: 97
received lenght: 62
source: разные айпишники все время
Что это?
Блин, сколько всего понаписали 
. Сначала про bfd, потом про bfg, затем про bdf, и даже про idkfa. Осталось ещё 20 букаф в алфавите, можно немеряно комбинаций настрочить.
ТС-у на микрот прилетают чужие пакеты BFD, которые Микрот не опознаёт, а потому дропит, об чём и пишет в лог. Что с этим делать? Да много что:
1. Можно нанять спеца за большие деньги, а ещё лучше контору по обеспечению безопасности (Касперский Лаб и т.п.). Чем дороже заплатите, тем надёжнее будут защищать.
2. Можно пожаловаться в РКН и в отдел К МВД на тех, кто шлёт на вас неправильные BFD. Ибо нехер тут мешать работе правильным сетям связи.
3. Можно отключить у себя на Микроте BFD там, где он не нужен. В вашем случае, похоже, надо просто везде отключить.
4. Можно зафаерволить прилетающие BFD, если не жалко на это тратить ресурс цпу.
5. Купить ещё один Микрот.
6. А можно просто забить и жить с этим дальше.
Изменено 17 июля, 2020 пользователем nemo_lynx
|
211 / 40 / 0 Регистрация: 24.06.2012 Сообщений: 217 |
|
|
1 |
|
|
13.01.2021, 20:57. Показов 5408. Ответов 2
Добрый вечер.
Что за фигня и как с этим бороться?
0 |
|
4557 / 2004 / 425 Регистрация: 17.10.2015 Сообщений: 8,653 |
|
|
17.01.2021, 15:07 |
2 |
|
Решение Bidirectional Forwarding Detection (BFD) — протокол, позволяющий быстро обнаруживать проблемы связности маршрутизаторов на IP уровне и тем самым обеспечивающий быструю сходимость протоколов маршрутизации. Что с этим делать? Да много что: 1. Можно нанять спеца за большие деньги, а ещё лучше контору по обеспечению безопасности (Касперский Лаб и т.п.). Чем дороже заплатите, тем надёжнее будут защищать. 2. Можно пожаловаться в РКН и в отдел К МВД на тех, кто шлёт на вас неправильные BFD. Ибо нехер тут мешать работе правильным сетям связи. 3. Можно отключить у себя на Микроте BFD там, где он не нужен. В вашем случае, похоже, надо просто везде отключить. 4. Можно зафаерволить прилетающие BFD, если не жалко на это тратить ресурс цпу. 5. Купить ещё один Микрот. 6. А можно просто забить и жить с этим дальше.
1 |
Сообщение было отмечено ihappy как решение
|
211 / 40 / 0 Регистрация: 24.06.2012 Сообщений: 217 |
|
|
18.01.2021, 18:29 [ТС] |
3 |
|
romsan, спасибо.
0 |
-
dds
- Сообщения: 1
- Зарегистрирован: 19 апр 2016, 18:03
Доброго времени суток. Есть следующая схема:
Центральный узел и выносы. На центральном узле CCR1016, на выносах HEX Lite. С выноса настроены два канала до центрального узла (основной и резервный). На каналах настроены адреса /30. Поднято OSPF+BFD PtP. Основной и резервный канал разруливаю через COST в OSPF (настроены одинаково с обоих сторон, 10 и 20 соответственно). С центрального узла делаю инъекцию 0.0.0.0/0. Когда оба канала в работе — маршрутизация идет через основной канал с COST 10. Если он падает — OSPF в течении 2-3 сек меняет default route gw на резервный канал с COST 20 (0.0.0.0/0 не исчезает из таблицы маршрутизации). После того, как основной канал восстанавливается — по идее, должно быть безобрывное переключение на основной канал. Но у меня в момент переключения, из таблицы маршрутизации исчезает 0.0.0.0/0, и где то через 4-5 секунд снова появляется со шлюзом в основной интерфейс. Нормальное ли это поведение для Mikrotik??? Работал с Cisco и Alcatel, там возврат на основной канал происходит без обрывов. Как данную проблему можно решить? Спасибо!
-
vqd
- Модератор
- Сообщения: 3605
- Зарегистрирован: 26 сен 2013, 14:20
- Откуда: НСК
- Контактная информация:
19 апр 2016, 18:42
Чисто теоретически
Когда у вас переключение происходит то клиентским приложениям нужно поднять новое соединение что бы оно пошло через новый маршрут.
То есть микротик в базовой конфигурации не может работать с соединением в случае если оно было установлено через другой канал.
По сути вам нужно объяснить микротику что бы он не «заруливал» все тупо в действующий маршрут, а отправлял все соединения через тот канал/маршрут через которое они были установлены. Ну пока они не умрут.
Возможно в циске это как то предустановленно, в микротике нужно отдельно настраивать
-
wolf_ktl
- Сообщения: 417
- Зарегистрирован: 25 июн 2013, 18:12
15 июн 2016, 17:25
dds писал(а):Доброго времени суток. Есть следующая схема:
Центральный узел и выносы. На центральном узле CCR1016, на выносах HEX Lite. С выноса настроены два канала до центрального узла (основной и резервный). На каналах настроены адреса /30. Поднято OSPF+BFD PtP. Основной и резервный канал разруливаю через COST в OSPF (настроены одинаково с обоих сторон, 10 и 20 соответственно). С центрального узла делаю инъекцию 0.0.0.0/0. Когда оба канала в работе — маршрутизация идет через основной канал с COST 10. Если он падает — OSPF в течении 2-3 сек меняет default route gw на резервный канал с COST 20 (0.0.0.0/0 не исчезает из таблицы маршрутизации). После того, как основной канал восстанавливается — по идее, должно быть безобрывное переключение на основной канал. Но у меня в момент переключения, из таблицы маршрутизации исчезает 0.0.0.0/0, и где то через 4-5 секунд снова появляется со шлюзом в основной интерфейс. Нормальное ли это поведение для Mikrotik??? Работал с Cisco и Alcatel, там возврат на основной канал происходит без обрывов. Как данную проблему можно решить? Спасибо!
Какие туннели используешь?
Механизмы фильтрации и суммирования маршрутов, а также использования пассивных интерфейсов.
Нет комментариевПросмотров: 18262
Введение
В заключительной, четвёртой, части серии статей о протоколе OSPF будут рассмотрены механизмы фильтрации и суммирования маршрутов, а также использования пассивных интерфейсов.
Также будет рассмотрен пример использования OSPF в отказоустойчивых схемах и использование протокола BFD для увеличения скорости сходимости.
Использование входящих и исходящих фильтров
В RouterOS реализован механизм фильтрации маршрутов для гибкой конфигурации входящей и исходящей маршрутной информации. Для OSPF используются две цепочки: ospf-in для входящих маршрутов и ospf-out для исходящих. Используемые цепочки фильтрации указываются в настройках instance.
Для создания простейших фильтров достаточно указать три параметра:
- chain — имя цепочки, к которой будет применяться фильтр;
- prefix — адрес сети и маска для проверки соответствия;
- action — выполняемое действие. Различают следующие действия:
- accept — разрешить прохождение маршрутной информации;
- discard — отклонить прохождение маршрутной информации;
- jump — перейти к указанному фильтру;
- log — добавить в лог сообщение о совпадении и перейти к следующему правилу в цепочке;
- passthrough — перейти к следующему правилу в цепочке, инкрементировав счётчик совпадений для данного правила;
- reject — отклонить прохождение маршрутной информации (для входящих, в отличие от discard, заносит данную информацию в память, но маршрут не участвует в дальнейшей обработке;
- return — возвращение к предыдущей цепочке, из которой был совершён переход через jump.
В цепочку 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. Конфигурация оборудования:
Конфигурация устройств:
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.
Выделяют два типа суммирования маршрутов:
- inter-area (суммирование маршрутов на границе двух зон, совершаемое ABR);
- Inter-area (маршрутная информация о сетях в соседних областях, которые сообщает ABR в LSA type 3);
- external (суммирование маршрутов на границу AS, совершаемое ASBR).
Рекомендация по суммированию заключается в том, чтобы суммировать маршруты по направлению к 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
/routing ospf interface add interface=ether4 passive=yes
Вывод списка соседей на R2
Таблица маршрутизации на 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 в избыточной топологии для повышения отказоустойчивости. Отдельное внимание уделено скорости сходимости алгоритма и представлены рекомендации по увеличению скорости сходимости.
Механизмы фильтрации и суммирования маршрутов, а также использования пассивных интерфейсов.
Введение
В заключительной, четвёртой, части серии статей о протоколе OSPF будут рассмотрены механизмы фильтрации и суммирования маршрутов, а также использования пассивных интерфейсов.
Также будет рассмотрен пример использования OSPF в отказоустойчивых схемах и использование протокола BFD для увеличения скорости сходимости.
Использование входящих и исходящих фильтров
В RouterOS реализован механизм фильтрации маршрутов для гибкой конфигурации входящей и исходящей маршрутной информации. Для OSPF используются две цепочки: ospf-in для входящих маршрутов и ospf-out для исходящих. Используемые цепочки фильтрации указываются в настройках instance.
Для создания простейших фильтров достаточно указать три параметра:
- chain — имя цепочки, к которой будет применяться фильтр;
- prefix — адрес сети и маска для проверки соответствия;
- action — выполняемое действие. Различают следующие действия:
- accept — разрешить прохождение маршрутной информации;
- discard — отклонить прохождение маршрутной информации;
- jump — перейти к указанному фильтру;
- log — добавить в лог сообщение о совпадении и перейти к следующему правилу в цепочке;
- passthrough — перейти к следующему правилу в цепочке, инкрементировав счётчик совпадений для данного правила;
- reject — отклонить прохождение маршрутной информации (для входящих, в отличие от discard, заносит данную информацию в память, но маршрут не участвует в дальнейшей обработке;
- return — возвращение к предыдущей цепочке, из которой был совершён переход через jump.
В цепочку 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. Конфигурация оборудования:
Конфигурация устройств:
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
Метрика OSPF
Проанализируем таблицу маршрутизации и 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.
Выделяют два типа суммирования маршрутов:
- inter-area (суммирование маршрутов на границе двух зон, совершаемое ABR);
- Inter-area (маршрутная информация о сетях в соседних областях, которые сообщает ABR в LSA type 3);
- external (суммирование маршрутов на границу AS, совершаемое ASBR).
Рекомендация по суммированию заключается в том, чтобы суммировать маршруты по направлению к 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
Вывод списка соседей на R2
Таблица маршрутизации на 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 в избыточной топологии для повышения отказоустойчивости. Отдельное внимание уделено скорости сходимости алгоритма и представлены рекомендации по увеличению скорости сходимости.