BGP VPLS на MikroTik распространяет информацию L2VPN между PE. Девятая часть рассматривает, как различать клиентские пути, когда VPLS и TE используют loopback-адреса одних и тех же маршрутизаторов.
Это учебная схема RouterOS v6 с несколькими взаимодействующими протоколами. Перед изменением одного слоя проверьте OSPF, MPLS, TE и BGP отдельно, чтобы не маскировать причину ошибки.
Нам необходимо найти место, которое было доступнее всего для “центрального” маршрутизатора iBGP RR.
Первый вариант — использовать R10, на нём и так будет BGP, плюс он должен быть самым производительным, но нам сильно производительный маршрутизатор для RR не нужен, он будет только пересылать информацию об услугах клиентов.Если интерфейс между маршрутизатором R10 и R5 упадёт, то клиенты не смогу получить доступ в интернет, а также потеряют услуги L2VPN или L4VPN.Вариант не подходит.
Второй вариант — использовать один из маршрутизаторов PE, во первый непонятно какой именно выбрать, во вторых обычно PE маршрутизаторы находятся физически по краям сети и возможно, что данный сегмент может “отсохнуть”.Вариант не подходит.
Третий вариант — поднять отдельную машину поднять VPLS туннели до всех маршрутизаторов P и объявить его RR, да, но сколько связей необходимо сделать, чтобы был отказоустойчивым.Вариант не подходит.
Четвёртый вариант — использовать R5, он имеет с ядром три связи, в идеале сделать ещё по одной связи с R1 и R3, но пока не финансово не физически мы сделать этого не можем.Попробуем данный вариант.
Нам необходимо выбрать AS для внутреннего использования.Выберем 65000 из приватного диапазона.
Установить AS можно следующей командой на всех PE маршрутизаторах, а также R5 и R9.Естественно указать router-id такой же, как loopback интерфейса.
Теперь нам необходимо настроить peer на R9 и до R5.Когда мы будем говорить, что нам необходимо настроить peer, мы сразу будем иметь в виду, что peer будет строиться до R5, естественно на адрес loopback.
Обратите внимание, что мы установили значение route-reflect другими словами роль RR. Возможно у вас появился вопрос, а чем нам на R9 peer? Дело в том, что мы предоставляем услугу pppoe, а для того, чтобы pppoe поднялось, необходим один broadcst домен между клиентом и серверов, эту роль будет выполнять VPLS.
Подключение клиентов
У нас почти всё готово для того, что бы мы могли предоставить клиентом услугу интернет.
Давайте рассмотрим на примере CE-1 первого клиента, далее всем по аналогии надо будет сделать также с другими.Естественно мы не трогаем клиентское оборудование, на нём всё должно заработать автоматически.
Первым, делом нам необходимо для уникального клиента выбрать уникальный адрес loopback, я предлагаю использовать отдельный loopback, для того чтобы router-id в mpls-te не поменял свой номер, это не критично, но и не хочется чего-то не предвиденного.
И так создадим отдельный loopback для уникальности каждого клиента, делается только одни раз, на всех PE маршрутизаторах, напоминаю у нас всего два маршрутизатора PE.
/interface bridge add name=Br-loClient
Далее нам необходимо выбрать для каждого клиента уникальный адрес loopback, пока у нас мало клиентов поэтому поступим следующим образом и используем 172.31.253.0/24 префикс и каждый порядковый номер клиента это последний октет в адресе.
Для первого клиента, будем использовать адрес loopback 172.31.253.1/32
После данной настройке на всех маршрутизаторах, должен прилететь маршрут до loopback адреса.
Также нам необходимо для первого клиента создать Bridge, назовём его Bridge-1 и добавить в него интерфейс, который смотрит в сторону клиента, для первого клиента это будет ether3 (смотри схему), отключите протокол rstp/stp.
Команды в статье меняют сетевую конфигурацию. Перед работой сохраните экспорт, подготовьте способ восстановления доступа и применяйте изменения сначала в тестовой среде.
RSVP-TE на MikroTik сигнализирует LSP для MPLS Traffic Engineering. В восьмой части настраиваются атрибуты OSPF-TE и туннели с заданным направлением и требованиями.
Трафик не обязательно попадёт в TE-туннель только потому, что LSP поднят. Отдельно проверьте механизм направления трафика, резерв полосы и поведение при отказе.
/routing ospf instance set default mpls-te-area=backbone mpls-te-router-id=Br-Lo
После того как вы выполните команду на всех маршрутизаторах провайдера, мы увидим, что в OSPF появился новый тип LSA — 10.Называется OPAQUE
Пока нет нечего интересного в данных, так как мы только объявили, то что наша area OSPF поддерживает MPLS-TE, но собственно пока данных не каких мы не вводили описывающие пропускную возможность интерфейсов.
Как раз, мы начнём с того, что опишем пропускную способность интерфейсов.
Вспомним нашу схему сети
Необходимо на каждом маршрутизаторе интерфейсы которые описывают OSPF, в TE указать пропускную способность данных интерфейсов.Делается это следующей командой.
Как только мы объявим доступную пропускную способность, TE интегрирует в LSA OSPF, а так как LSA на всем маршрутизаторах синхронизирован в одной area, все маршрутизаторы будут в курсе, какие есть интерфейсы и с какими они возможностями.
1.Тип LSA 10 2.Router-ID владелец данной записи LSA. 3.IP адрес на интерфейсе. 4.Ширина интерфейса.
Есть ещё дополнительные параметры, например TE метрика, но об этом чуть попозже.
К сожалению, в RouterOS LSA вы не увидите, данной информации, данные не преобразуются из байт-кода только увидите записи тип
Задание
1.На всех маршрутизаторах провайдера объявите работу OSPF в расширенном режиме MPLS-TE 2.На всех маршрутизаторах провайдера, укажите интерфейсы и их пропускную способность для TE.
Как проверить результат
Проверьте running state и фактический path TE tunnel.
Сравните зарезервированную и доступную полосу на каждом линке.
Отключите один участок и проверьте перестроение или переход на резервный LSP.
Команды в статье меняют сетевую конфигурацию. Перед работой сохраните экспорт, подготовьте способ восстановления доступа и применяйте изменения сначала в тестовой среде.
MPLS Traffic Engineering на MikroTik строит явные LSP с учётом дополнительных ограничений. Седьмая часть начинает отдельную лабораторию TE с новой топологией и адресацией.
RSVP-TE не заменяет проектирование IGP и MTU. Серия написана для RouterOS v6; доступность и синтаксис TE в вашей версии и архитектуре нужно сверять по официальной документации.
С чистого листа
Сбросьте все маршрутизаторы чистую конфигурацию, Если необходимо, то сделайте резервную копию.
Схема
И так новая схема, со всеми описаниями и как положено со всеми настройками.
Многие написали, что GNS и EVE-ng не тянет такие скорости. Также на одном интерфейсе не очень наглядно увидеть как работает TE, решил немного переиграть скорости, чтобы было намного нагляднее.
Необходимо дать пояснение к схеме.
Маршрутизаторы, которые занимаются только пересылкой MPLS трафика, называются label switch, они же просто буква P - Provider — Маршрутизатор.Маршрутизатор выполняет функции только доставки трафика на другие маршрутизаторы провайдера, в нашем случае это маршрутизаторы R1,R2,R3,R6,R5,R7.
Обратите внимание на то, что поменялись имена маршрутизаторов, они теперь все имеют суффикс R.
Маршрутизатор к которому подключены непосредственно клиенты имеет название Edge Label Switch, Маршрутизатор на границе MPLS облака, так же отмечается аббревиатурой как PE - Provider EDGE.Маршрутизатор, который стоит на границе сети провайдера, и занимается подключением клиентов.В нашем случае это маршрутизаторы R8 и R7.Если по простому, клиенты отправляют на PE обычный трафик, а роль PE сводится к тому, что необходимо назначить метку и отправить в нужном направлении.Также если на PE приходит трафик который надо доставить до клиента, то задача PE маршрутизатора снять все метки и отправить обычный IP или ethernet фрейм, всё зависит от задачи.
CE - Client EDGE маршрутизатор клиента.Обычный маршрутизатор.
Напомню, общую идеологию:
На всех маршрутизаторах провайдера, поднять loopback c именем Br-Lo.И Данному Loopback указан IP адрес со схемы.
Все интерфейсы между всеми маршрутизаторами (кроме клиентских) имеет сеть /30 и она помещается в префикс 172.31.252.0/24 не перепутайте и не используйте другую, так чтобы дальнейшие лабы у нас поднялись.
Адресация на интерфейсах идёт по принципу от меньшего к большему, если вы соединяете два маршрутизатора R30 и R40, то первый адрес из /30 сети вы назначаете на маршрутизатор R30, так как его порядковый номер меньше противоположенного маршрутизатора.
R9 маршрутизатор, которые будет выступать в роли PPPoE сервера, чтобы мы могли выдать услугу клиентам в виде интернета.
R10 Маршрутизатор, у которого настроен peer, с другим провайдером, на нём есть дефолтный маршрут, и у нас есть сеть собственный префикс для анонса
Отличия от прошлых лаб
Обратите внимание, что мы сеть Loopback тоже объявили в network OSPF, чуть позже объясню какие есть плюсы, а какие минусы и когда можно так делать, а когда нельзя.
Также фильтры роутинга OSPF мы оставим пустыми, я не в коем случае не предлагаю делать так в production сетях, но для нас пока “так пойдёт”, не хочу расписывать, пока все нюансы которые вас ждут, так что пока оставляем как есть без фильтров.Естественно в конце мы всё поправим.
Я приведу конфигурацию, каждого маршрутизатора, чтобы мы начали с чистого листа, но и не теряли время, вам должны быть известны многие настройки.
Выступает в роли пограничного маршрутизатора, которые знает как выйти в интернет.
Легенда такая, у нас есть префикс 123.0.0.0/24 который мы объявляем нашему соседу пиру по протоколу eBGP и номер нашей AS 100.Мы не принимаем FullView, нам наш провайдер отдаёт default.Сильно на данном этапе зацикливаться не будем, скажем этот Peer не позволяет выйти в интернет.Единственное, что мы сделали, это добавили на всех маршрутизаторах так называемые null-ed маршруты, чтобы трафик из сетей BOGON не покидал пределы нашей AS.
Маршрутизатор, который нам будет выходом в интернет.
default-originate=always — отдаём дефолтный маршрут маршрутизатору R10.Также необходимо настроить на маршрутизаторе интернет, в моём случае я получаю настройки по DHCP через ether2 интерфейс.Создайте правило srcnat которое позволит нашей сети 123.0.0.0/24 всё-таки выйти в интернет.
Команды в статье меняют сетевую конфигурацию. Перед работой сохраните экспорт, подготовьте способ восстановления доступа и применяйте изменения сначала в тестовой среде.
VPLS и OSPF на MikroTik в шестой части собраны в пошаговое решение для CE и PE. Цель — сравнить собственную конфигурацию с эталонной и найти расхождения.
Команды относятся к RouterOS v6 и учебной адресации серии. Не копируйте их в рабочую сеть без замены адресов, интерфейсов, фильтров и проверки версии.
CE-3
Задать имя маршрутизатору и включить romon если надо.
/system identity set name=CE-3
/tool romon set enabled=yes
И добавить интерфейс ether4 в LDP протокол, чтобы заработал MPLS.
/mpls ldp interface
add interface=ether4
Ну, что же давайте взглянем на то, что у вас должно было получится.
На маршрутизаторе CE-1 вы должна видеть два VPLS туннеля и все для клиента C1.
[admin@CE-1] /interface print
Flags: D - dynamic, X - disabled, R - running, S - slave
# NAME TYPE ACTUAL-MTU L2MTU MAX-L2MTU MAC-ADDRESS
0 R ether1 ether 1500 0C:C6:06:90:91:00
1 R ether2 ether 1500 0C:C6:06:90:91:01
2 R Br-Lo bridge 1500 65535 82:0B:BC:CB:6B:73
3 R bridge-C1 bridge 1500 1500 02:3D:28:22:B2:81
4 R bridge-C2 bridge 1500 65535 C2:3A:68:B1:06:87
5 DRS vpls35 vpls 1500 1500 02:3D:28:22:B2:81
6 DRS vpls36 vpls 1500 1500 02:1C:49:73:BD:B8
На маршрутизаторах CE-2 и CE-3 одни и веже клиенты поэтому поднимется одинаковое количество VPLS интерфейсов.
[admin@CE-2] > /interface print
Flags: D - dynamic, X - disabled, R - running, S - slave
# NAME TYPE ACTUAL-MTU L2MTU MAX-L2MTU
0 R ether1 ether 1500
1 R ether2 ether 1500
2 R ether3 ether 1500
3 R Br-Lo bridge 1500 65535
4 R bridge-C1 bridge 1500 1500
5 R bridge-C2 bridge 1500 1500
6 DRS vpls31 vpls 1500 1500
7 DRS vpls34 vpls 1500 1500
8 DRS vpls38 vpls 1500 1500
Ну и соответственно интерфейсы в Bridge-ах.
[admin@CE-2] > /interface bridge port print
Flags: X - disabled, I - inactive, D - dynamic, H - hw-offload
# INTERFACE BRIDGE HW PVID PR PATH-COST INTERNA... HORIZON
0 D vpls31 bridge-C1 1 0x 10 10 10
1 D vpls34 bridge-C2 1 0x 10 10 10
2 D vpls38 bridge-C1 1 0x 10 10 10
Посмотрим как это выглядит на схеме.
Первый клиент C1
Первый клиент, всё понятно одни интерфейс один туннель, между двумя маршрутизаторами
И второй клиент
А со вторым клиентом значительно интереснее, поднялся fullmesh.Данная схема наглядно показывает, что если не применять технологию horizon будет петля, так как у нас полносвязная топология VPLS.А если применять RSTP/STP то трафик будет ходить не оптимально.
Обратите внимание, что направление стрелок на схеме не указывает, на то через какие маршрутизаторы пойдёт трафик между маршрутизаторами, за next-hop отвечает протокол OSPF.
Задание
В этот раз не будет как таковых заданий.Приведите сетевые настройки к общему виду, если они не соответствуют нашей схеме.
Это была последняя статья по LDP на этой лабе, далее будет другая лаба в которой мы будет управлять утилизировать каналы с помощью TE.
Как проверить результат
Сравните identity, loopback, адреса и фильтры с вашей схемой.
Проверьте OSPF neighbor и маршруты до PE/CE loopback.
Проверьте VPLS state и L2-связность отдельно для каждого клиента.
Команды в статье меняют сетевую конфигурацию. Перед работой сохраните экспорт, подготовьте способ восстановления доступа и применяйте изменения сначала в тестовой среде.
VPLS на MikroTik использует MPLS-ядро для передачи клиентских Ethernet-кадров между PE. Пятая часть связывает путь метки, роли маршрутизаторов и будущую сигнализацию клиентского сервиса.
Перед VPLS проверьте IP-связность loopback, LDP и MPLS MTU. Клиентский L2-домен может переносить широковещательный трафик, поэтому лабораторную схему не следует подключать к рабочей сети без ограничений.
Когда маршрутизатор добавляет метку к пакету, такая процедура называется push.Метка добавляется между заголовков IP и ethernet именно поэтому MPLS называют протоколов уровня L2.5 OSI.
Ниже анимация формирования пакета MPLS.
Нечего интересного в данном процессе нет, просто добавили к пакету метку, не более чем.А вот дальнейший процесс будет показывать нагляднее почему MPLS выигрывает у обычного процесса IP маршрутизации.
Взгляните на процесс forward при работающим MPLS.Процесс IP маршрутизации не происходит как такового.Так как до него просто пакет не доходит.Из таблицы forward MPLS маршрутизатор сверил метку 5000, понял, что её надо поменять на 8888 сменил метку (SWAP) и отправил next-hop-у.
Снятие метку называется процедура POP, процесс сложнее о нём мы поговорим немного позже.Так как снятие происходит, не на последнем маршрутизаторе, а на предпоследним, и само снятие не всегда приводит конкретно к снятию метки, а к изменению метки на специальные номера, те самые которые зарезервированные от 0 до 15.
Скорее всего появился вопрос “что нам дал MPLS”, ну в первую очередь конечно ускорение процесса маршрутизации и всё! Сам MPLS в чистом виде, не так очевиден и зачастую не используется в том виде как это сделано сейчас у нас.Но появляется возможность использовать такие технологии как PW он же VPLS, а также VPN4.
VPLS — это туннель, которые позволяет, пропустить через себя ethernet трафик, т.е, для того чтобы предоставить услугу L2 VPN, по сути аналогичную роль в RouterOS выполняет EoIP туннель.
VPN4 — это способ доставки IP пакета, через MPLS сеть, т.е предоставление клиенту услуги L3 VPN, но самое главное, что клиент может использовать любые сети, и они не будут влиять на ваши сети и сети других ваших клиентов.
Но мы же провайдер, поэтому ручной метод нам не подходит, мы бы хотели всё и вся оптимизировать.
BGP
Перед тем как начать, настраивать BGP нам надо осознать, что всё что мы до этого делали, необходимо было для работы в BGP между Loopback адресами.
Уточним задачу, у нас есть клиент которому необходимо предоставить услуги L2VPN, между двумя маршрутизаторами CE.
И так нам необходимо связать два маршрутизатора CE с помощью протокола BGP и указать чем будет заниматься BGP протокол.Напомню, что он может распространять не только маршрутную информацию, но и распространять дополнительную информацию, именно эту дополнительную информацию мы будем распространять.
Точно так же как и в OSPF у BGP маршрутизатора есть RouterID значение должно быть уникальным в пределах одной AS.
AS — автономная система, помимо того что это номер 16 бит, а сейчас и все 32 бита, это ещё и политическая сущность, которая определяет единую политику настройки маршрутизаторов в одной AS.
Для наших задач мы будем использовать отдельный instance и номер автономной системы 65000.Необходимо напомнить что диапазон номеров AS разделён на две части приватный и публичный, примерно так же как и BOGON адреса, только есть одно серьёзное отличие, эти диапазоны намертво вшиты в протокол и его реализацию в RouterOS, поэтому вы ОБЯЗАНЫ использовать именно из приватного диапазона номера AS от 64512 до 65535.Публичный диапазон только если у вас есть своя AS либо на стендах когда вы делаете “один к одному”.
И так сначала нам необходимо на CE маршрутизаторах создать BGP instance
remote-address=172.31.243.2 — Указываем адрес противоположенного пира.
update-source=172.31.253.1 — Указываем адрес с которого будет строиться соединение, тут надо уточнить.Вы можете указать не адрес, а интерфейс, но если на интерфейс будет несколько IP адресов может произойти fuckup.
remote-as=65000 — Удалённая AS, если её номер совпадает с instance указанным в instance=bgp65000 то такое соединение считается как iBGP internal т.е.Внутренним.Если значения AS разные, то такое поведение называется eBGP т.е.Внешнее соединение.
address-families=l2vpn,l2vpn-cisco,vpnv4 — так называемые типы данных которые будут передаваться с помощью данного пира BGP.
После того вы сделаете на всех маршрутизаторах, проверить то, что мы идём по верной дороге и всё у нас получается.Узнать состояние Peer
[admin@CE-1] > /routing bgp peer print
Flags: X - disabled, E - established
# INS..REMOTE-ADDRESS REMOTE-AS
0 E bgp..172.31.253.2 65000
Состояние соединения должно быть Established, слева флаг E.
VPLS
Когда мы строим VPLS то у пакета появляется не одна метка, а две (стек меток), первая метка обеспечивает прохождение трафика по MPLS сети, вторая метка указывает непосредственно на PW туннель.
Для того чтобы запустить нашу “Трубу” или PW, нам необходимо подготовить инфраструктуру.Надеюсь вы помните, что CE маршрутизатор, это тот маршрутизатор к которому подключается непосредственно клиенты.
Нам необходимо подготовить Bridge в котором будут порты для оборудования клиента, также можно сделать и с vlan.Мы не будем добавлять интерфейсы нам достаточно для понимания самого принципа построения таких сетей.
И так необходимо создать Bridge c отключенным rstp\stp, мы не будем мешать нашему клиенту делать петли, если ему надо будет делать петли, пусть делает это его желание, наша задача предоставить ему L2 туннель между точками включения на маршрутизаторах CE.
route-distinguisher=172.31.253.1:0 — Уникальное значение для каждого маршрутизатора, и в некоторых случаях может быть уникальным значением для разных ролей на одном маршрутизаторе.С помощью данного значения создаётся уникальность информации которая передаётся средствами BGP.Лучше всего укажите адрес loopback и просто порядковый номер, пока это неважно.
bridge=bridge-C1 — Когда VPLS поднимется, то интерфейс добавится автоматически в Bridge нашего клиента.
bridge-horizon=10 — Технология, которая позволит нам поднять fullmesh связь между все маршрутизаторами и защититься от возможной петли, если не указать, то она будет 100% при подключении следующего маршрутизатора.Смысл технологии очень простой если фрейм придёт в интерфейс Bridge, и у интерфейса с которого пришло фрейм установлено значение horizon.Фрейм не будет отправлен в интерфейсы у которых значение horizon аналогичное.Будьте пределы аккуратны, если на Bridge будет отключен rstp/stp и вы не установите значение horizon у вас будет L2 Loop.
pw-type=raw-ethernet — указываем какого типа PW.
site-id=1001 — уникальное значение, для всей AS и для каждого маршрутизатора.Тут надо быть внимательным, необходимо найти такой способ, чтобы сделать это значение с двух стороны уникальным и это значение не должно больше использоваться.Лучше все использовать такой подход, берём номер маршрутизатора умножаем на 1000 и прибавляем номер клиента.Получается, что значение site-id на первом маршрутизаторе будет для первого клиента 1001, а для второго 1002, на маршрутизаторе CE-3 3001 и соответственно 3002.Уникальность значения требуется из-за того, что значение site-id используется для расчёта номера метки MPLS, но просто давать порядковые номера не очень удобно, ввиду того, что придётся вести где-то документацию.Я несколько не призываю отказываться от документации, но всегда можно упростить себе жизнь прибегая к определённым шаблонам.
А наверное самое главное.
export-route-targets=65000:1 — хорошим кейсом (Вообще так и задумывалось, но некоторые игнорируют даней аспект) считается указывать сначала номер AS, а далее через разделитель двоеточие, номер клиента. Чтобы понять для чего этот параметр необходим, это уникальный идентификатор данного туннеля.Ключевое слово export т.е.Данный маршрутизатор будет “вещать” раскатывать всем своим пирам, о том что у него есть такой туннель VPLS.На стороне клиента данное значение должно быть указанно в поле import-route-targets.
import-route-targets=65000:1 — тип записи который мы ожидаем для сопоставления с данным VPLS туннелем.Часто мы должны указать значение которое указанно на противоположенной стороне в export-route-targets.
Задачи
Создать BGP instance на CE маршрутизаторах.AS 65000
Создать BGP Peer на двух CE маршрутизаторах.FullMesh
Создаёте Bridge для нашего клиента.
Опубликуйте через BGP VPLS туннели на CE маршрутизаторах. Чтобы закрепить результат
Необходимо к маршрутизатору PE-1 подключить ещё один CE маршрутизатор CE-3.
К маршрутизатору CE-1 подключен только клиент C1
К маршрутизатору CE-2 подключены клиенты C2 и С3
К маршрутизатору CE-3 подключены клиенты C2 и С3
Итого у нас есть два клиента C1 и C2
Как проверить результат
Проверьте MPLS forwarding до каждого PE loopback.
Создайте один тестовый VPLS и проверьте running state.
Передайте кадры между двумя CE и просмотрите learned MAC на обоих концах.
Команды в статье меняют сетевую конфигурацию. Перед работой сохраните экспорт, подготовьте способ восстановления доступа и применяйте изменения сначала в тестовой среде.
MPLS и LDP на MikroTik добавляют пересылку по меткам поверх уже работающей IP-маршрутизации. В четвёртой части лаборатория переходит от OSPF к распределению меток.
До MPLS должны стабильно работать loopback и IGP. Значения MTU и поддержка функций зависят от интерфейсов и оборудования; проверяйте их до передачи клиентского трафика.
Нет повести печальнее на свете, чем повесть о BGP c MPLS-ом.
о MPLS
Настал тот час, когда мы уже должны каким то образом реализовать нашу сеть.
И конечно MPLS нам здесь поможет сам MPLS это всего лишь процесс маршрутизации пакетов на основании меток. Особое место занимает не процесс маршрутизации, а процесс распространения меток по маршрутизаторам. Все маршрутизаторы в сети должны знать какую метку надо ожидать с интерфейса и в какой интерфейс с какой меткой его необходимо перенаправить.
И для данного кейса в RouterOS есть два варианта, это протокол LDP и протокол Traffic-Engineering.
LDP протокол тупой как танк, его задача найти соседей обменяться с ним сетями и метками и создать таблицу forward. Особенность LDP заключается в том, что он полностью подчиняется маршрутизации. Как таблица маршрутизации решит куда отправлять трафик, туда LDP и будет отправлять трафик с метками. А так как у нас таблицей маршрутизацией заведует протокол OSPF, и часто его схождение требует приличного времени, полагаться на данный способ можно, но… мы пойдём другим путём.
Кто-то из вас скажет “но ведь можно изменить Hello интервалы или использовать BFD”, да можно, но при этом мы не сможем утилизировать резервный интерфейс. Данные настройки всего лишь могут способствовать уменьшению времени запуска процедуры калькуляции SPF и тем самым уменьшить простой, но не поможет утилизировать все интерфейсы.
А если посмотреть ещё глубже, каждый интерфейс между маршрутизаторами является бизнес активом, который стоит денег. Обслуживание, интерфейсы ну и в конце концов Человеко-часы которые затрачены на настройку и подержанные такого стыка. Возможно вы арендуете некоторые интерфейсы. Если деньги потрачены, то нет смысла делать так, чтобы интерфейс простаивал, его необходимо загрузить, но обычной маршрутизацией этого сделать не получиться, так как пропускная способность резервного интерфейса 100Mbps. Если мы направим весь трафик в данный интерфейс, то он будет заполнен на 100% и ещё куда-то надо будет деть 900Mbps.
Напоминание. Всегда когда рассчитываете нагрузку на сеть и failover, вы должны использовать подход худшего сценария. Т.е “всё упало”, всё загружённое на максимум.
MPLS
В первую очередь метки, диапазон возможных меток от 0 до 1048575, но притом надо учитывать, что первые 15 меток зарезервированы для специальных условий. Об этом позже.
Нам соответственно необходимо использовать от 16 до 1048575, кстати это два в двадцатой степени, а так как счёт идёт от нуля, то минус один.
Хорошим тоном считается выделить каждому маршрутизатору свой диапазон меток, чтобы вы понимали с какого маршрутизатора прилетела метка.
Я предлагаю выделить каждому маршрутизатору по 5000 меток, такого количества будет достаточно для наших целей. Если оставить как есть значения по умолчанию, то может получиться таким образом, что маршрутизаторов будут использовать одинаковые метки, что становиться неудобно при troubleshooting.
Не будем как-то привязывать к типам маршрутизаторов, а просто по порядку распишем номера меток на нашей схеме, последовательно по 5000 меток.
Для установки диапазона меток из которого будет выбирать маршрутизатор метки можно указать следующей командой.
/mpls set dynamic-label-range=5000-9999
LDP
Label Distribution Protocol — как я уже писал выше, простой как танк. Его задача рассказать всем какие у маршрутизатора есть сети и какие метки использовать для сетей, а также принять от других маршрутизаторов аналогичную информации и составить таблицу forward label.
По умолчанию LDP берёт таблицу маршрутизации и рассказывает всем соседям о всей своей таблице маршрутизации. Это не лучший кейс, лучше всего рассказать только о Loopback адресах.
Но для начало нам необходимо установить уникальный ID маршрутизатора.
Делается это командой
/mpls ldp set lsr-id=172.31.255.100
Естественно значение желательно чтобы было ожидаемым и мы для этих целей будем использовать адрес loopback интерфейса.
Далее необходимо установить адрес транспорта, т.е. С какого адреса будет происходить “вещание” поиск соседей и обмен с ними информацией.
Так же как и с lsr-id устанавливаем адрес loopback интерфейса.
/mpls ldp set transport-address=172.31.255.100
Следующим шагом нам необходимо, указать какие сети мы будем опубликовывать c помощью LDP протокола. Наша задача рассказать всем соседям о наших адресах, в том числе connected и loopback. Нам поможет, то что мы правильно спланировали адресацию, и можем описать все адреса одним префиксом 172.31.0.0/16. ОН немного большой, но возможно он нам в дальнейшем еще пригодится.
Первая командой мы указываем, что какой-то префикс из таблицы маршрутизации мы разрешаем анонсировать advertise=yes, следующей командой указываем, что всё остальное запрещаем. Тем самым мы исключаем появления ошибки в конфигурации.
Следующим шагом настроить фильтр “на входе” какие префиксы мы можем ожидать.
Мы будем принимать только те маршруты которые попадают под префиксы наших служебных IP адресов маршрутизаторов.
LDP интерфейсы
Последний момент который необходимо сделать, это непосредственно запустить процесс LDP на интерфейсах. Указываем интерфейсы которыми связаны между собой маршрутизаторы.
Обращаю ваше внимания ещё раз, указывать надо только те интерфейсы которыми между собой связанны маршрутизаторы.
Включение LDP
После всех манипуляций нам необходимо просто включить LDP и в нашей сети трафик между loopback интерфейсами будет маршрутизироваться на основании меток, т.е. У нас заработает MPLS.
/mpls ldp set enabled=yes
Проверка
Проверить можно простой трассировкой с CE-1 до CE-2 естественно проверяйте именно до адреса loopback.
Команды в статье меняют сетевую конфигурацию. Перед работой сохраните экспорт, подготовьте способ восстановления доступа и применяйте изменения сначала в тестовой среде.
OSPF cost на MikroTik определяет предпочтение пути внутри area. В третьей части резервный линк с меньшей пропускной способностью получает большую стоимость, чтобы не участвовать в обычном ECMP.
Метрика должна отражать проектное решение, а не только номинальную скорость. Проверьте одинаковое понимание cost на обоих концах и ожидаемое поведение при отказе основного пути.
Как вы, наверное, помните интерфейс между маршрутизаторами P-2 и P-5 имеет статус резервного и его пропускная способность 100Mbps все остальные интерфейсы, связывающие маршрутизаторы между собой, равны по качеству и скорости, и пропускная способность составляет 1Gbps.
OSPF Cost
Если вы посмотрите на таблицу маршрутизации, к примеру на маршрутизаторе P-5, то вы увидите маршрут ECMP, который построился из-за одинаковой цены маршрутов до маршрутизатора P-3. Специально не привожу адреса маршрутизаторов, у вас должно быть всё правильно сделано.
В таком случае если с маршрутизатора P-5 отправится трафик на маршрутизатор P-3, то он будет делиться между маршрутизаторами P-2 и P-6. Нас естественно такой момент не устраивает, так как интерфейс до маршрутизатора P-2 является менее продуктивным, так как его скорость меньше.
[admin@P-5] > /ip route print
Flags: X - disabled, A - active, D - dynamic,
C - connect, S - static, r - rip, b - bgp, o - ospf, m - mme,
B - blackhole, U - unreachable, P - prohibit
# DST-ADDRESS PREF-SRC GATEWAY DISTANCE
0 ADC 172.31.252.12/30 172.31.252.13 ether1 0
1 ADC 172.31.252.16/30 172.31.252.18 ether2 0
2 ADC 172.31.252.24/30 172.31.252.26 ether3 0
3 ADo 172.31.253.1/32 172.31.252.17 110
4 ADo 172.31.253.2/32 172.31.252.14 110
5 ADo 172.31.254.1/32 172.31.252.17 110
6 ADo 172.31.254.2/32 172.31.252.14 110
7 ADo 172.31.255.1/32 172.31.252.17 110
172.31.252.25
8 ADo 172.31.255.2/32 172.31.252.25 110
9 ADo 172.31.255.3/32 172.31.252.14 110
172.31.252.25
10 ADo 172.31.255.4/32 172.31.252.17 110
11 ADC 172.31.255.5/32 172.31.255.5 Br-Lo 0
12 ADo 172.31.255.6/32 172.31.252.14 110
[admin@P-5] >
Также есть маршрут ECMP и до P-1 и такую картину вы будете наблюдать на всех маршрутизаторах, противолежащий маршрутизатор доступен сразу через два соседних маршрутизатора.
Где вы можете видеть ECMP
Так происходит, так как цена у маршрутов одинаковая. У каждого маршрутизатора есть “начальная цена” маршрута, начальная цена задаётся в instance
Есть предустановленные значения, и как в нашем случае при редистрибьюции connected маршрутов начальная цена ровна 20metric-connected=20, после того как маршрутизатор отправил информацию о своих сетях всем своим соседям, каждый маршрутизатор при получении маршрута через интерфейс прибавил к данному значению цену своего интерфейса, а по умолчанию цена ровна десяти 10.
Изменить цену интерфейса можно с помощью команды
[admin@P-5] > /routing ospf interface print
Flags: X - disabled, I - inactive, D - dynamic, P - passive
# INTERFACE COST PRIORITY NETWORK-TYPE AUTHENTICATION AUTHENTICATION-KEY
0 P all 10 1 default none
1 ether1 10 1 broadcast none
2 ether2 10 1 broadcast none
3 ether3 10 1 broadcast none
[admin@P-5] > /routing ospf interface set cost=100 numbers=2
Обратите внимание, что цена устанавливается к номерам, поэтому сначала выполните команду print и после этого применяйте значение. Также cost можно установить при добавлении интерфейсов в OSPF.
Также необходимо отметить, что цена интерфейса однонаправленная, т.е вам необходимо будет установить цену интерфейса на двух маршрутизаторах. И не забывайте, что абсолютно весь трафик должен миновать данный интерфейс, вы должны установить такую цену, чтобы даже прямой интерфейс между маршрутизаторами был самый дорогой.
Если посмотреть на схему и самый длинный маршрут от P-2 до P-5, то это 4 прыжка, так как у нас цена по умолчанию интерфейсов 10, то при самом худшем сценарии маршрут будет иметь цену на маршрутизаторе 60, который сложится из цены интерфейсов 40 и начальной цены (метрики 20). Поэтому вы должны установить такое значение, чтобы данная цена перекрывала худший сценарий, ну а если пойти ещё дальше, то давайте посчитаем, какая цена будет от маршрутизатора CE-1 до P-1 если останется только кольцо.
Посмотрите на схему выше, максимально возможный путь, который всё равно должен быть лучшим по качеству, цена маршрута будет равна 100.
Соответственно мы должны установить такую цену на интерфейсе между P-2 и P-1, что бы итоговая цена была больше чем 100.
Посчитайте для начала самостоятельно.
Да, конечно если мы установим цену равную 41, то итоговая цена на маршрутизаторе P-1 будет 101, что выше самого длинного пути, соответственно такой путь будет выбираться только в “крайних случаях”. Я рекомендую устанавливать значение кратным 10, в первую очередь из-за того, что проще считать, а во вторую очередь то, что если у вас когда-нибудь появиться ещё один резервный интерфейс и он будет лучше, чем наш текущий резервный интерфейс, то вы сможете “впихнуть” цену таким образом, чтобы он стал “Лучшим среди худших” интерфейсов.
Стоит упомянуть, что такой подход будет работать ТОЛЬКО если при редистрибьюции выставлен тип Type-1, в случае с Type-2 внутренние косты не учитываются, а учитывается только внешняя метрика, которую указал маршрутизатор при редистрибьюции (начальная цена). Если на маршрутизатор приходит два маршрута с одинаковым cost и если у данных маршрутов разные типы, то маршрутизатор всегда отдаёт приоритет type-1, в таком случае ECMP строится не будет.
Вы всегда можете посмотреть какая ценна у маршрута.
[admin@CE-1] /ip route> print detail
Flags: X - disabled, A - active, D - dynamic,
C - connect, S - static, r - rip, b - bgp, o - ospf, m - mme,
B - blackhole, U - unreachable, P - prohibit
0 ADC dst-address=172.31.252.44/30 pref-src=172.31.252.46 gateway=ether1
gateway-status=ether1 reachable distance=0 scope=10
1 ADC dst-address=172.31.253.1/32 pref-src=172.31.253.1 gateway=Br-Lo
gateway-status=Br-Lo reachable distance=0 scope=10
2 ADo dst-address=172.31.253.2/32 pref-src=172.31.253.1 gateway=172.31.252.45
gateway-status=172.31.252.45 reachable via ether1 distance=110 scope=20 target-scope=10
ospf-metric=80 ospf-type=external-type-1
3 ADo dst-address=172.31.254.1/32 pref-src=172.31.253.1 gateway=172.31.252.45
gateway-status=172.31.252.45 reachable via ether1 distance=110 scope=20 target-scope=10
ospf-metric=30 ospf-type=external-type-1
4 ADo dst-address=172.31.254.2/32 pref-src=172.31.253.1 gateway=172.31.252.45
gateway-status=172.31.252.45 reachable via ether1 distance=110 scope=20 target-scope=10
ospf-metric=70 ospf-type=external-type-1
5 ADo dst-address=172.31.255.1/32 pref-src=172.31.253.1 gateway=172.31.252.45
gateway-status=172.31.252.45 reachable via ether1 distance=110 scope=20 target-scope=10
Traceroute
Попробуйте выполнить трассировку от CE-1 до CE-2
[admin@CE-1] > /tool traceroute 172.31.253.2
# ADDRESS LOSS SENT LAST AVG BEST WORST STD-DEV STATUS
1 172.31.252.45 0% 3 5ms 10 4.6 20.5 7.4
2 100% 3 timeout
3 100% 3 timeout
4 100% 2 timeout
5 100% 2 timeout
6 100% 2 timeout
Конечно трассировка работать не будет, так как на маршрутизаторах нет маршрутов до connected сети 172.31.252.44/30, мы их отфильтровали в прошлом задании. Когда заканчивается TTL маршрутизатор, на котором закончился TTL, должен ответить ICMP о том, что ttl expired. Но так как маршрута до сети отправления нет, ответ мы не получаем.
Всегда держите в голове
При наличии нескольких интерфейсов, когда вы отправляете пакет с маршрутизатора при неуказанном адресе источника адрес отправителя выбирается из значения pref-source того маршрута, через который отправлен пакет.
[admin@CE-1] > /ip route print
Flags: X - disabled, A - active, D - dynamic,
C - connect, S - static, r - rip, b - bgp, o - ospf, m - mme,
B - blackhole, U - unreachable, P - prohibit
# DST-ADDRESS PREF-SRC GATEWAY DISTANCE
0 ADC 172.31.252.44/30 172.31.252.46 ether1 0
1 ADC 172.31.253.1/32 172.31.253.1 Br-Lo 0
2 ADo 172.31.253.2/32 172.31.252.45 110
3 ADo 172.31.254.1/32 172.31.252.45 110
4 ADo 172.31.254.2/32 172.31.252.45 110
5 ADo 172.31.255.1/32 172.31.252.45 110
6 ADo 172.31.255.2/32 172.31.252.45 110
7 ADo 172.31.255.3/32 172.31.252.45 110
8 ADo 172.31.255.4/32 172.31.252.45 110
9 ADo 172.31.255.5/32 172.31.252.45 110
10 ADo 172.31.255.6/32 172.31.252.45 110
Выше таблица маршрутизации с CE-1
Когда маршрутизатор отправляет пакет на адрес CE-02 он выберет маршрут под номером 2, дальше он посмотрит какой указан шлюз в данном маршруте, если НЕ интерфейс, то далее будет искать лучший маршрут уже для адреса шлюза 172.31.252.45, а это будет маршрут под номером 0, именно этот интерфейс будет использован для отправки пакета.
Соответственно если в маршруте 2 не указан pref-source (PREF-SRC), то будет выбран адрес источника уже непосредственно connected маршрута, а в таких маршрутах адрес соответствует установленному адресу на интерфейсе. (Без IP маршрутизатор не останется)
Если мы установим на маршрутах добавленных в таблицу маршрутизации адрес loopback как значение pref-source, то при трассировке мы будем видеть IP адреса не интерфейсов, а адреса Loopback, что будет удобнее.
НО ВНИМАНИЕ, данный подход можно применять ТОЛЬКО если между маршрутизаторами нет прямой двойной связи, в таком случае вы из трассировки не сможете понять по какому именно интерфейсу вам возвращает трафик маршрутизатор.
В нашем случае, а нас по одному соединению между маршрутизаторами поэтому мы можем внедрить данную реализацию.
И так сделаем трассировку для проверки и укажем адрес источника адрес loopback.
Сейчас мы видим, что нам все маршрутизаторы отвечают с IP адреса интерфейса которым смотрят в нашу сторону.
Теперь установим значение pref-source на всех маршрутизаторах на входящих маршрутах в фильтрах.
Чтобы не переделывать каждый маршрут мы можем использовать find чтобы разом установить на все маршруты.
/routing filter set set-pref-src=172.31.253.1 [find chain=ospf-in action=accept]
Естественно для каждого маршрутизатора свой адрес loopback.
Результатом будет установленное значение pref-source на всех маршрутах полученных по OSPF.
[admin@CE-1] /routing filter> /ip route pr interval=2
Flags: X - disabled, A - active, D - dynamic,
C - connect, S - static, r - rip, b - bgp, o - ospf, m - mme,
B - blackhole, U - unreachable, P - prohibit
# DST-ADDRESS PREF-SRC GATEWAY DISTANCE
0 ADC 172.31.252.44/30 172.31.252.46 ether1 0
1 ADC 172.31.253.1/32 172.31.253.1 Br-Lo 0
2 ADo 172.31.253.2/32 172.31.253.1 172.31.252.45 110
3 ADo 172.31.254.1/32 172.31.253.1 172.31.252.45 110
4 ADo 172.31.254.2/32 172.31.253.1 172.31.252.45 110
5 ADo 172.31.255.1/32 172.31.253.1 172.31.252.45 110
6 ADo 172.31.255.2/32 172.31.253.1 172.31.252.45 110
7 ADo 172.31.255.3/32 172.31.253.1 172.31.252.45 110
8 ADo 172.31.255.4/32 172.31.253.1 172.31.252.45 110
9 ADo 172.31.255.5/32 172.31.253.1 172.31.252.45 110
10 ADo 172.31.255.6/32 172.31.253.1 172.31.252.45 110
Теперь если мы сделаем трассировку с маршрутизатора в ответах мы будет видеть адреса loopback интерфейсов и не IP адресов интерфейсов между маршрутизаторами.
Настроить цену интерфейсам на резервном интерфейсе, так чтобы данный интерфейс участвовал в маршрутизации, только если других вариантов нет. Установите значение cost 50.
Укажите во входящих фильтрах OSPF устанавливать значение pref-source как адрес loopback.
Как проверить результат
Сравните OSPF routes и next hop до изменения cost.
Измените стоимость резервного линка и подтвердите исчезновение лишнего ECMP.
Отключите основной путь и проверьте активацию резервного.
Команды в статье меняют сетевую конфигурацию. Перед работой сохраните экспорт, подготовьте способ восстановления доступа и применяйте изменения сначала в тестовой среде.
OSPF MikroTik во второй части связывает узлы лабораторной сети и распространяет loopback-адреса. Отдельное внимание уделено backbone area и фильтрации анонсов.
Основная конфигурация относится к RouterOS v6. В RouterOS v7 структура instance, area и interface-template изменилась; сверяйте команды с документацией вашей версии.
Фильтры OSPF
Очень частая ошибка при конфигурации OSPF это не использовать фильтры маршрутов, если один из маршрутизаторов будет настроен не правильно он может “Выплюнуть” в сеть лишние маршруты которые приведут к развалу всей сети, особенно это заметно при построении туннелей, а так же когда используется связка BGP и OSPF в особенности когда есть Full View, одна галочка, и на всех маршрутизаторах закончилась память. А так как OSPF передаёт только изменения, память прибиться очищать либо отключением протокола OSPF либо перезагрузкой.
Прежде чем настраивать OSPF нам необходимо настроить фильтры, для того чтобы в дальнейшем не допустить ошибку и не нарваться на неё.
В OSPF у нас есть возможность указать какие маршруты мы можем принять и добавить в таблицу маршрутизации (не путать с таблицей LSDB) а какие нет, ну и также можем указать какие маршруты из таблицы маршрутизации отдавать в сеть OSPF. При этом мы не можем, точнее у нас не получиться запретить на отдачу внутренние маршруты по которым строятся связь OSPF. Так как такие маршруты являются неотъемлемой частью LSDB таблицы, а она должна быть на всех маршрутизаторах одинакова в одной area.
В первой части, мы продумали адресаций для каждого типа оборудования, а теперь наступил момент воспользоваться тем, что у нас явно все типы адресов находятся в одной сети.
chain=ospf-in — цепочка фильтров которая по умолчанию назначена на дефолтный instance OSPF в RouterOS. Говорит о том, что мы будем проверять на соответствие некому правилу, и если не запрещено то такой маршрут будем добавлять в таблицу маршрутизации.
prefix=172.31.255.0/24 — префикс это не маршрут, префикс это адресное пространство из которого мы будем выискивать маршруты с определённой длинной.
prefix-length=32 — а вот тут уже непосредственно длинна маршрута.
Другими словами мы будем разрешать action=accept все маршруты у которых длина соответствует prefix-length а также сам маршрут лежит в более большой сети prefix. Наши Loopback интерфейсы как раз на маршрутизаторах имеют адреса из данной сети и маску /32.
Также нам необходимо разрешить Loopback адрес для PE и CE устройств.
И конечно в конце, чтобы не прилетели лишние маршруты мы должны добавить /routing filter add chain=ospf-in action=discard
Я предпочитаю также использовать цепочку ospf-out, что бы при ошибке не улетело нечего лишнего, поэтому давайте также продублируем все что было в ospf-in в цепочке ospf-out.
Фильтры так же как и правила firewall обрабатывают по порядку, поэтому сначала разрешаем, а в конце цепочки всё запрещаем.
OSPF instance
Instance это процесс ospf в большинстве случаев он нам нужен только один. Зачастую второй Instance нужен если вы предлагаете своим клиентам услугу l3vpn, но нам до неё ещё как до луны или если вы делаете соединение ospf сетей с другой сетью, и чтобы в вашу LSDB таблицу не было доставлено лишних маршрутов используют разные Instance. На данном этапе нам достаточно одного дефолтного instance.
Особенность Instance вы должны указать некое уникальное значение Router-id, это не IP адрес, но записывается так же как и IP принцип и длину 4 октета по 8 бит. Если не указывать, то маршрутизатор самостоятельно выберет из наименьшего активного IP адреса, нам некоем случаем нельзя полагаться на волю судьбы. Для данного решения у нас есть адрес Loopback который отлично подходит под значение Router-ID.
Назначается Router-id следующим образом
/routing ospf instance set default router-id=172.31.255.#
Значения Loopback адресов возьмите с адреса интерфейса Br-lo либо с нашей схемы.
Интерфейсы
Для работы OSPF необходимо указать на каких интерфейсах будет работать процесс OSPF слушать и отправлять.
В RouterOS есть одна особенность как только вы укажите подсеть в разделе networks на интерфейсах на которых объявлены IP адреса из данной подсети сразу запуститься процесс OSPF. Категорически необходимо исключить такое поведение изменить “не добавление” нельзя, но можно создать шаблон по умолчанию, для всех интерфейсов которые будут добавлен в процесс автоматически. Как вы наверное уже догадались я категорически не приветствуют всего того, что может быть изменено динамически и привести к проблемам в работе сети.
Шаблон для всех интерфейсов назначается с помощью alias интерфейса all
Все интерфейсы которые будут добавлены динамически будут обладать свойствами passive=yes
passive=yes — обозначает что на данном интерфейсе не будет запущен процесс ospf, не будут отсылаться пакет ospf и будут проигнорированы водящие пакеты ospf.
Т.е тем самым мы все динамические интерфейсы которые могут быть добавлены из-за вашей ошибки в дальнейшем (а они будут) помечаем как пассивные для протокола ospf.
Далее нам необходимо добавить интерфейсы в процесс ospf
И обязательно указать тип сети в нашем случае это Broadcast так как мы используем сеть отличную от /32.
Обращаю ваше внимание, что вы должны добавить только те интерфейсы за которыми находятся соседние ВАШИ маршрутизаторы. Не надо добавлять Loopback интерфейсы. Если интерфейс используется для соединения с другим маршрутизатором, то добавляем, особенно обратите внимание на CE маршрутизаторах, на них используется только один интерфейс.
Networks
Настал момент непосредственно запуска процесса ospf. Вам необходимо на всех маршрутизаторах добавить сети (обращаю внимание именно СЕТИ, а не IP адреса). Сети в которых находятся другие маршрутизаторы в вашей сети использующие протокол OSPF. Указывать надо именно те сети которые непосредственно присоединены к текущему маршрутизатору.
Обращаю внимания, что нет необходимости добавлять в networks сети любые другие отличные от тех которые используются для связи между маршрутизаторами.
Например, на P-1 будет три сети, а на CE только одна.
Так же вы можете просто посмотреть на схему из первой части, и сети будут прописаны между маршрутизаторами.
Часто в инструкциях вы можете найти информацию примерно такого рода “добавьте в networks те сети которые вы хотите опубликовать в OSPF “, да есть такой кейс, но его лучше всего применять только в STUB area. У нас не используется STUB, а также вы не можете указать каким типом Type-1 или Type-2 будет распространяться данный маршрут, так как он будет intra-area т.е внутренний маршрут.
Обращаю ещё раз внимание именно СЕТЬ с маской и только сеть между маршрутизаторами.
Редистрибьюция
Ну и наконец кульминация всего, это непосредственно распространение маршрутной информации с помощью редистрибьюции. Наша задача рассказать всем маршрутизаторам о там, что на маршрутизаторах есть адрес Loopback, а так как маршрут, который формируется на основании наличия IP адреса является connected именно с таким типом маршруты мы будем опубликовывать в сети OSPF.
/routing ospf instance set default redistribute-connected=as-type-1
А так как на всех маршрутизаторах у нас настроены фильтры мы не боимся (переживаем и перепроверяем настройку фильтров), что мы распространим лишнюю информацию. Даже в случае ошибки если один маршрутизатор распространит лишнюю маршрутную информацию, то мы не будем принимать нечего отличного от того, что явно разрешено.
Задачи
На всех маршрутизаторах:
Настроить цепочку фильтров ospf-in
Разрешить адреса loopback P маршрутизаторов
Разрешить адреса loopback PE маршрутизаторов
Разрешить адреса loopback CE маршрутизаторов
Запретить все остальные маршруты
Настроить цепочку фильтров ospf-out
Разрешить адреса Loopback (в зависимости от типа маршрутизатора P, PE или CE) маршрутизаторов
Запретить все остальные маршруты
Подсказка все фильтры в цепочке ospf-in у вас будут одинаковые, а вот ospf-out будут отличаться.
Указать на всех маршрутизаторах router-id для instance default, указать Router-id аналогичный, как и Loopback адрес.
Добавить дефолтный шаблон интерфейсов с пассивным поведением
Добавить все интерфейсы на которых будет запущен процесс ospf
Добавить connected сети, по которым строится процесс OSPF.
Запустите процесс редистрибьюции connected маршрутов.
Итог
Если вы все правильно сделали, то на всех маршрутизаторах вы будете наблюдать примерно такую картину.
/ip route print
Flags: X - disabled, A - active, D - dynamic,
C - connect, S - static, r - rip, b - bgp, o - ospf, m - mme,
B - blackhole, U - unreachable, P - prohibit
# DST-ADDRESS PREF-SRC GATEWAY DISTANCE
0 ADC 172.31.252.36/30 172.31.252.38 ether2 0
1 ADC 172.31.252.40/30 172.31.252.42 ether1 0
2 ADC 172.31.252.44/30 172.31.252.45 ether3 0
3 ADo 172.31.253.1/32 172.31.252.46 110
4 ADo 172.31.253.2/32 172.31.252.41 110
172.31.252.37
5 ADC 172.31.254.1/32 172.31.254.1 Br-Lo 0
6 ADo 172.31.254.2/32 172.31.252.41 110
172.31.252.37
7 ADo 172.31.255.1/32 172.31.252.41 110
8 ADo 172.31.255.2/32 172.31.252.41 110
9 ADo 172.31.255.3/32 172.31.252.41 110
10 ADo 172.31.255.4/32 172.31.252.37 110
11 ADo 172.31.255.5/32 172.31.252.37 110
12 ADo 172.31.255.6/32 172.31.252.37 110
Как видите мы видим маршруты с флагом o — OSPF до всех loopback адресов всех маршрутизаторов.
Если вы используете средство виртуализации (я использую GNS3) и вам удобнее использовать Winbox вы можете создать локальное подключение и использовать ROMON для подключения к маршрутизаторам.
Как проверить результат
Проверьте состояние neighbor на каждом линке.
Сверьте маршруты до всех loopback-адресов.
Убедитесь, что фильтры не пропускают лишние connected и default routes.
Команды в статье меняют сетевую конфигурацию. Перед работой сохраните экспорт, подготовьте способ восстановления доступа и применяйте изменения сначала в тестовой среде.
Лаборатория MPLS MikroTik начинается с топологии и адресного плана. В первой части определены роли P, PE и CE, межмаршрутизаторные сети и loopback-адреса.
Серия создавалась для RouterOS v6. Команды следующих частей не следует переносить в RouterOS v7 без сверки меню routing и MPLS; используйте отдельную тестовую среду.
Итак, наша топология имеет принципиальную схему “кольцо”, сразу отметим, что соединение между маршрутизаторами P-2 и P-5 является резервным с пропускной способностью 100 Mbps, все остальные соединения ровны по качеству и скорости и пропускная способность соединений составляет 1 Gbps.
В дальнейшем это будет MPLS backbone
Первым делом нам необходимо раздать на маршрутизаторы адреса соединений, будем использовать /30, а также адреса loopback интерфейсов.
Чтобы в дальнейшем мы могли с легкостью использовать фильтры в firewall, а также фильтры маршрутов, хорошей практикой использовать сети, которые вписываются в один префикс.
Давайте опишем сети, которые мы будем использовать на всех сетевых устройствах
172.31.255.0/24 — Префикс из которого будут назначаться адреса Loopback маршрутизаторов P.
172.31.254.0/24 — Префикс из которого будет назначаться адреса для Loopback маршрутизаторов PE.
172.31.253.0/24 — Префикс из которого будет назначаться адреса для Loopback маршрутизаторов CPE.
172.31.252.0/24 — Префикс из которого будут выделены сети с длинной /30 непосредственно для соединения маршрутизаторов. Т.е та самая транспортная сеть между маршрутизаторами.
Последний октет адреса Loopback совпадает с порядковым номером маршрутизатора.
Такой подход к адресации позволяется легко и не принуждённо закрыть с помощью правил firewall и фильтрами маршрутов всю служебную сеть по префиксу 172.31.0.0/16. Если вы считаете это слишком расточительным, то я соглашусь, только не делайте адресацию в притык, оставляйте небольшой запас, иначе вам придётся добавлять ещё один префикс, лучше на начале этапе планирования адресация заложить возможность роста. В данный момент у нас допустимо по 256 маршрутизаторов так как мы используем адреса /32, но в лучших традициях нулевой адрес использовать не будем, чтобы когда уставшим взглядом в таблице маршрутизации мы не перепутали сеть .0/24 с сетью .0/32
Так же добавим два PE маршрутизатора, и по одному CE и распишем адреса.
Также чтобы было проще когда мы будем назначать адресацию, можно придерживаться такой схемы по значимости P значимее PE, PE значимее CE, такой подход даст нам возможность назначить IP адреса из сети /30 по единому стандарту.
Если мы назначаем адреса из сети 0/30 на маршрутизаторы P-1 и P-2, то первый адрес будет назначен на тот маршрутизатор, чей порядковый номер меньше по отношению к другому маршрутизатору в этой сети. Если назначаем адреса на маршрутизаторы P-N и PE-N, то какие бы не были номера, мы помним что P маршрутизатор “главнее” более значим, поэтому первый адрес назначаем именно на P маршрутизатор.
В принципе как вы будете выделять адреса, не принципиально, главное чтобы по порядку, иначе у вас останутся неиспользованные пространства из сети.
Теперь стало намного проще жить, мы всегда по имени маршрутизатора знаем какой IP адреса назначается на маршрутизатор из сети /30 и адрес loopback.
Настройка маршрутизаторов MikroTik
Обговорим заранее некоторые детали.
На маршрутизаторах под управлением RouterOS нет интерфейса с типом Loopback, для его замены используется пустой Bridge.
Напомню особенностью Loopback интерфейса является то, что его состояние всегда UP в независимости от состояния физических интерфейсов маршрутизатора.
Так же именование Bridge который выступает в роли Loopback лучше применять под таким именем Br-Lo или Br-Loopback, некоторые товарищи называют интерфейс без префикса Br-, в принципе это будет работать, но я придерживаюсь того, что рано или поздно могут добавить функционал в RouterOS в виде Loopback интерфейсов, и тогда при обновлении мы можем получить проблему в виде двух одинаковых интерфейсов.
Задание
Сбросьте конфигурацию маршрутизатора в Ноль, конфигурацию без настроек. /system reset-configuration no-defaults=yes
Задать имя маршрутизатору
Создать bridge с именем Br-Lo
Назначить на интерфейс Br-Lo IP адрес согласно схеме с маской /32
Назначить на интерфейсы IP адреса для транспорта, согласно нашему алгоритму, описанному ранее по тексту.
Включите Romon на всех маршрутизаторах
Если вы используете CHR, удалите DHCP клиента.
Обязательно используем ветку обновления long-term и ставим всегда последнюю версию из данной ветки.
Как проверить результат
Сверьте адресный план со схемой для каждого интерфейса.
Проверьте уникальность loopback и отсутствие пересечений подсетей.
Сохраните базовый export каждого узла перед следующей частью.
Команды в статье меняют сетевую конфигурацию. Перед работой сохраните экспорт, подготовьте способ восстановления доступа и применяйте изменения сначала в тестовой среде.
