Cisco Практика BGP MPLS и прочее.

MPLS Part 8. Практика.

MPLS L3 VPN Part 5.

MPLS L3 VPN PE-CE routing with OSPF Part 1.

2023.09.19. Kurapov Alexey.

MPLS Part 8

MPLS L3 VPN Part 5

MPLS L3 VPN PE-CE routing with OSPF Part 1.

Топология сети не изменилась:

Ранее научились отдавать connected сети, теперь перейдем к динамической маршрутизации – CE-PE routing.

PE – Provider Router, этот роутер терминирует на себе vrf.

CE – граничный роутер клиента, смотрит в сторону провайдера.

Настроим в качестве PE роутеры R1 и R2, чтобы посмотреть Multihoming. На R1 и R2 настроим vrf RED и на R8 в сторону R10 будет эта же vrf. И сделаем другие RD и RT, для удобства.

Настройки R1 и R2 идентичны:

Настройка на R1 vrf RED и BGP:

Поместим интерфейс R1 в сторону R3 в vrf RED:

Аналогично настроим R2:

Настроим R8 аналогично, но в router bgp и в address-family vpnv4 будут два neighbor-а – R1 и R2:

И на R3 удалим vrf RED:

На R3 проверим связность со шлюзами R1 и R2:

Успех.

Настроим OSPF между R1 и R3 и между R8 и R10:

На R3 проверим:

OSPF включен на интерфейсах R3 в сторону R1, R9 и в сторону R2, а также на интерфейсе Lo0.

OSPF соседи на R3:

Только один – R9, выключим на R9 линк в сторону R1 и R3, чтобы не мешал:

Соседство OSPF на R9 c R3 как видим упало.

Также упало OSPF соседство с R9 на R3:

Также отключим MPLS на R3:

Сейчас:

Отключаем MPLS:

Результат:

Запустим протокол маршрутизации OSPF на R1, на интерфейсе в сторону R3. Сейчас интерфейс между R1 и R3 на R1 находится внутри vrf:

И на R1 необходимо создать OSPF процесс внутри данной vrf RED. Как это делали ранее для BGP? Посмотрим на R8:

Как видим мы проваливались внутрь address-family ipv4 vrf RED и с помощью команды network помещали префикс внутрь vrf, после этого это становился vpnv4 префикс.

Для OSPF механизм похожий:

С помощью команды router ospf 100 vrf RED – создали OSPF процесс для vrf RED, далее как обычно задали router-id для OSPD процесса и поместили подсеть в данный OSPF процесс.

В итоге на R1 имеем следующие OSPF процессы:

Есть два OSPF процесса, с Process ID (PID) = 1 и 100.

Интерфейс Fa0/0.139 на R1 участвует в OSPF процессе с PID = 100:

И на нем поднялось соседство с R3:

На R3 создадим int Lo1 и убедимся, что на R1 эта подсеть будет добавлена внутрь OSPF процесса с PID = 100, т.к. интерфейс в сторону R3 на R1 находится в vrf RED:

До этого таблица маршрутизации на R1 для vrf RED:

Создаем на R3 int Lo1 не помещая его в vrf RED, vrf RED есть только на R1 и R2. R3 не требуется знать о vrf на R1 и R2, т.к. vrf – локальные сущности, а с точки зрения R3 это обычный ipv4 пиринг:

Создаем int Lo1 на R3 и помещаем внутрь обычного OSPF процесса, без vrf:

Проверяем на R1 таблицу маршрутизации для vrf RED:

Появился маршрут OSPF на подсеть 33.33.33.33/32 через R3.

Передадим маршрут от R1 в сторону R8.

Как R1 может передать маршрут на подсеть 33.33.33.33/32, полученный от R3?

Нужно выполнить на R1 редистрибуцию маршрутов из OSPF в BGP в рамках address-family vpnv4, и обратную редистрибуцию из BGP в OPSF на R8, для передачи в сторону R10.

В реальных сетях для редистрибуции используются route-map, при редистрибуции, из OSPF в BGP навешиваем tag и только этот tag отлавливаем при обратной редистрибуции из BGP в OSPF.

Не будем использовать route-map, т.к. сетей не много (позже сделать в лабе с route-map.)

Текущая конфигурация BGP на R1:

Текущая конфигурация OPSF на R1:

Конфигурация vrf RED:

И что R1 получает в рамках процесса OPSF c PID = 100, помещенного в vrf RED:

Эти подсети и хотим поместить в BGP, в рамках vrf RED, т.е. сделать их vpnv4 префиксами.

Что сейчас содержится на R3 в таблице BGP vrf RED:

Выполним на R1 редистрибуцию из процесса OPSF c PID = 100, в BGP в рамках address-family ipv4 vrf RED, т.е. префиксы станут vpnv4:

Проверка:

Видим, что все префиксы из OSPF процесса с PID = 100 в рамках vrf RED на R1 попали в BGP таблицу, в т.ч. и 33.33.33.33/32, подробнее про него:

Появился атрибут OSPF DOMAIN ID:0x0005:0x000000640200, а также OSPF RT:0.0.0.0:2:0 OSPF ROUTER ID:100.100.100.100:0. Это атрибуты расширения взаимодействия между OSPF и BGP.

Что получает R8 по BGP в рамках AF ipv4 vrf RED – какие vpnv4 префиксы:

Сейчас на R8 только один OSPF процесс с PID = 1:

И этот OSPF процесс находится в GRT и ничего не знает о префиксах полученных по BGP в рамках vrf RED:

Вот что знает R8 по OSPF в GRT:

Поднимем на R8 OSPF процесс, например, с PID = 200, в рамках vrf RED:

Указываем Router-ID и помещаем подсеть между R8 и R10 в этот OSPF процесс, а также выполнили redistribute из BGP в OSPF процесс с PID = 200.

Сейчас ничего нет в OSPF процессе в vrf RED:

Поместим интерфейс на R8 между R8 и R10 в vrf RED:

И поднимем OSPF между R8 и R10:

На R8 уже настроили, проверим на R10:

Отключили MPLS LDP.

Между R8 и R10 уже поднят OSPF:

Выполним на R8 редистрибуцию из OPSF в BGP:

И на R1 уже настроили редистрибуцию из OSPF в BGP:

Настроим обратную редистрибуцию из BGP в OSPF:

Проверка на R10:

Появились маршруты OSPF типа E2 – внешние маршруты Type 2, они генерируются R8 при редистрибуции из BGP в OSPF, из-за редистрибуции появились LSA Type 5, генерируемые R8:

ADV Router – 88.88.88.88 – LSA генерирует R8.

В Wireshark видим LSA Type 5:

R8 сообщает R10 о наличии этих LSA Type-5:

R10 запрашивает эти LSA у R8:

R8 отправляет в сторону R10 запрошенные LSA Type-5:

Рассмотрим подробнее одну LSA Type-5:

Появился tag - External Route Tag: 3489725929. R8 тегирует генерируемые им LSA Type-5 специальным тегом, который соответствует номеру ASN BGP на нем – 65001.

Для чего нужен External Route Tag? Маршрут от R8 попадает на другие роутеры заказчика по OSPF и дальше попадает на другой роутер провайдера, не R8, далее этот PE2 мог бы поместить маршрут из OSPF в BGP и отправить в сторону R3. R3 мог бы выбрать лучший путь через PE2-сеть заказчика-R10-R8-R3.

Но видя маршрут с External Route Tag PE2 не будет выполнять редистрибуцию данного маршрута обратно из OSPF в BGP. Настройка External Route Tag не требуется, это автоматический процесс, это один из механизмов OSPF Loop Prevention, вернее BGP L3 VPN with OPSF CE-PE Loop Prevention.

Проверим на R3 таблицу маршрутизации OSPF:

Также успешно получаем префиксы от R10, тип маршрутов O E2 – OSPF external type 2.

Роутеры R3 и R10 это CE заказчика, роутеры R1 и R8 – PE провайдера, R4 и R7 – P – роутеры MPLS облака провайдера.

Как сделать, чтобы роутеры заказчика видели префиксы друг друга не как внешние OSPF маршруты O E2 или E1, а как внутренние? Ведь R3 и R10 это может быть один кампус (офис) клиента, разнесенный по разным площадкам. И так как между CE роутерами клиента находится MPLS сеть провайдера появляется LSA Type 5. Как этого избежать?

Изменим на R8 номер OSPF процесса в vrf RED с 200 на 100:

Текущая конфигурация vrf RED на R8:

Изменим номер OSPF процесса в vrf c 200 на 100 и в конфигурации bgp выполним редистрибуцию из OSPF процесса с новым PID = 100:

Проверим как теперь роутеры заказчика видят маршруты друг друга:

R3:

R10:

БД OPSF LSA на R3:

Осталась одна LSA Type-5 про префикс 108.108.108.108 – про int Lo2 на R8 – не имеет отношения в OSPF и к префиксам клиента. Видим, что все маршруты на свои подсети роутеры заказчика видят как OSPF inter area - O IA. Теперь они генерируются как LSA Type-3 - Summary Net Link States.

Что произошло?

Было:

1. R1 получал маршруты от R3 по OPSF c PID = 100 и отдавал их путем редистрибуции в BGP в BGP Update в сторону R8.

2. R8 получал префиксы от R1 по BGP и выполнял обратную редистрибуцию префиксов из BGP таблицы в OSPF процесс, но уже с Proccess ID = 200, при этом R8 использовал LSA Type 5 для передачи маршрутов в сторону R10, т.к. это внешние маршруты, получены из другого протокола, путем редистрибуции.

Стало:

1. Теперь когда на R8 процесс OSPF также, как и на R1 имеет ID = 100, маршрут на R8 попадает из BGP в OSPF посредством не LSA Type 5, а с помощью LSA Type 3. Здесь влияет одинаковый номер OSPF процесса на PE роутерах – R1 и R8.

Проверка на R1:

Маршрут попал внутрь BGP таблицы с OSPF DOMAIN ID:0x0005:0x000000640200, первая часть до второго 0х фиксированная, не обращаем внимание, далее – 64 в 16-й системе счисления, это 100 в 10-й – здесь зашит номер OSPF процесса на R1.

Далее R1 отдает этот префикс в BGP Update в сторону R8.

Проверка на R8:

Видим тот же, OSPF DOMAIN ID:0x0005:0x000000640200, что и на R1 – R8 успешно получил BGP Update от R1.

Route-Target у данного префикса RT:65001:99, что должен делать R8 с префиксами, имеющими данный RT:

Получая BGP Update c Route-Target = :65001:99, R8 должен префиксы указанные в данном Update поместить в vrf RED, а затем редистрибутировать в OSPF процесс с Proccess ID = 100, в рамках той же vrf RED.

Правило!!! Если OSPF DOMAIN ID локальный и в BGP Update равны, то следовательно маршрут OSPF не покидал одного заказчика и его необходимо редистрибутировать в OSPF как LSA Type 3, а не Type 5, т.е. как будто маршрут просто прошел между зонами, не попадая в сети провайдера.