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

MPLS  L3 VPN Part 4.

2023.09.11. Kurapov Alexey.

MPLS Part 7

MPLS L3 VPN Part 4 

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

                   

 

                    Как проверили ранее роутеры R83 и R8 получают BGP Update про vpnv4 префиксы друг друга, но не инсталлируют их в свою BGP таблицу. Почему? Почему они отбрасывают эти BGP Update?

                    Включим debug и перезапросим BGP Update:

 

                    Включаем Debug на R3:

 

                    Перезапрашиваем BGP Update для vpnv4 префиксов от R8:

В Wireshark видим эти сообщения. 

                    R3 запрашивает обновления для vpnv4:

 

                    R8 отправляет их:

 

                    Но R3 отбрасывает эти обновления:

                    Причина - extended community not supported. Почему?

 

                    R8 поместил ipv4 префиксы из разных vrf в свою BGP таблицу, для их идентификации от добавил RD, таким образом префиксы стали vpnv4 префиксами. R8 знает, может идентифицировать из какой vrf пришел префикс по значению RD.

                    На R3 также есть две vrf, их может быть меньше или больше, например, одна vrf или три, но как R3 может понять какие vpnv4 префиксы куда, в какую или какие vrf помещать? RD это в данном случае не поможет, RD это идентификатор vrf и vpnv4 префиксов в пределах одного роутера.

                    Для того, чтобы приемная сторона знала в какую vrf поместить vpnv4 префикс используется дополнительный BGP атрибут – Route-Target – это BGP Extended Community. Т.о. исходящий роутер при помещении префикса в BGP таблицу должен добавить к нему BGP атрибут – Export Route-Target, который представляет собой Extended Community, а приемная сторона на основе полученного Route-Target принимает решение в какую vrf импортировать данный префикс, т.е. на приемном роутере должен быть задан атрибут Import Route-Target.

                    Настроим Export и Import Route-Target на R3 и R8 следующим образом:

на R3:

для vrf RED Route-Target Export = 8:1, Route-Target Import = 3:1,

для vrf BLUE Route-Target Export = 8:2, Route-Target Import = 3:2,

на R8:

для vrf RED Route-Target Export = 3:1, Route-Target Import = 8:1,

для vrf BLUE Route-Target Export = 3:2, Route-Target Import = 8:2,

 

                    Выполним настройку роутеров R3 и R8:

 

                    Проверка:

Роутеры получают друг от друга по два vpnv4 префикса.

 

                    Какие это префиксы, например, на R3:

 

                    Подробно по VRF: 

Подробно про сами получаемые и отдаваемые префиксы:

                    Например, для префикса 108.108.108.108/32 в vrf RED:

 видим BGP атрибут Extended Community, заданный на R8, это Route-Target = 3:1.

 

Также видим наш RD для данного префикса, он взят из настройки для vrf RED на нашем роутере R3:

 

Но также изначально заимпортированный путь - видим RD указанный на R8 для vrf RED – from 8:1:

 

                    Полный вывод для RD 8:1 и 3:1 на R3:

 

                    Далее vpnv4 префиксы помещаются в таблицу маршрутизации для соответствующей vrf:

 

Важно! Сам Next-Hop находится не в vrf, а внутри дефолтной таблицы маршрутизации (GRP) – default:

 

  

                    Важно! Нужно разделять Data Plane и Control Plane.

                    Выше проверили работу Control Plane.

                    Проверим работу Data Plane.

                    Проверим доступность префикса 108.108.108.108/32  с R3 помощью команды ping.

                    Сначала проверим доступность самого R8 с R3:

                    Успех. В Wireshark видим пакеты icmp с одной меткой MPLS = 25:

 

                    Теперь проверим доступность префикса 108.108.108.108/32  с R3 помощью команды ping:

                    Также успех.

                    Но в Wireshark видим две MPLS метки и причем для разных vrf меняется вторая метка, ближняя к ip вложению:

                    Для ping в vrf RED указанная метка = 41:

Для ping в vrf BLUE указанная метка = 42:

 

                    Как в итоге R8 понимает, какой пакет в какую vrf направить?

                    Проверим CEF на R3:

                    Присутствует общий первый столбец с MPLS метками – 36, 23, 37. Это MPLS LDP метки, указывают путь до R8. Далее видим второй столбец с MPLS метками, причем значение различно для разных vrf, но сохраняется на всем пути вне зависимости от next-hopa, это VPN метка, данная метка характеризует vrf.

                    Откуда берутся VPN метки? Смотрим таблицу BGP для конкретных vrf на R8 – т.е. для vpnv4 префиксов:

                    Видим полученные ранее на R3 VPN метки, т.е. данные метки сгенерированы протоколом BGP на R8 для каждого vpnv4 префикса (префикса ipv4 помещенного в конкретную vrf) в направлении in и переданы в BGP update в сторону R3. Важно! R8 будет генерировать разные VPN метки для разных vrf. Т.о. R8 передает в BGP update не только RD, RT export, но и VPN метки.

                    Посмотрим еще раз BGP Update от R8 в сторону R3: 

 

                    Для vpnv4 префикса 108.108.108.108.32, c RT = 3:1, R8 сгенерировал  VPN метку = 41и именно данную метку мы видим на R3 для vpnv4 префикса с RT = 3:1 и который импортируем в vrf RED, указывая RT import = 3:1 Аналогичная ситуация и для vpnv4 префикса 108.108.108.108/32 с RT на R8 = 3:2 и импортируемого на R3 в vrf BLUE – VPN метка сгенерированная на R8 = 42 и ее R3 указывает в качестве VPN метки.

 

                    Проверим traceroute с R3:

                    Также две MPLS метки.

 

                    Первая метка – Label 1 – это метка, сгенерированная протоколом LDP – транспортная метка, меняется на каждом роутере,

                    Вторая метка – Label 2 – сгенерирована протоколом BGP, BGP или VPN метка, получаем в BGP Update от R8, это сервисная метка.

                    Запустим ping и traceroute c R3 на префикс 108.108.108.108/32 в рамках, например, vrf RED, т.к перезагрузили все роутеры, то VPN ( они же BGP они же сервисные) метки будут другими:

 

В Wireshark:

                    В ICMP Request две MPLS метки:

- метка = 40 ближняя к заголовку 802.1Q – транспортная или LDP метка,

- метка = 45, это BGP или сервисная метка, остается (как видим в выводе команды traceroute) неизменной от роутера к роутеру – Hop-by-Hop.

                    Важно!!! Флаг S у сервисной метки = 1:

                    Флаг S – Bottom of Label Stack – у крайней (в нашем случае VPN, она же BGP, она же сервисная) метка = 1, это крайняя метка в MPLS стеке, далее идет вложение – Payload. VPN метку генерирует в данном случае R8 независимо и передает вместе с BGP Update в сторону R3.

 

                    Мы организовали сервис L3 поверх MPLS сети, он называется MPLS L3 VPN. Рассмотрели базовый сценарий, когда интерфейсы directly connected, далее рассмотрим, клиента внутри какой либо vrf и будем с ним пириться с использованием различных протоколов маршрутизации, например, IGP – OSPF или EGP – BGP.