2023 10 30 Практика.

MPLS Inter-AS L3 VPN Option A

 

Топология сети :

               Но первоначально все роутеры это Cisco IOS 3725:

               Option A с ними полностью работает, для Option B/C как увидим далее пришлось заменить маршрутизаторы.

 

               Внутри каждого ISP запущен IGP протокол OSPF для обеспечения связности своих роутеров через int Lo0:

 

 

               Таблица маршрутов OSPF:

 

               И запущены процессы BGP - iBGP в каждом ISP между своими PE роутерами, при этом R8 и R7 выполняют роль BGP RR в рамках своей AS, int Lo1 используем для проверки работы iBGP в пределах ISP:

 

               Какие префиксы получает R8 от своих RR клиентов:

 

 

               Аналогично настроен ISP 2.

 

               Нужно соединить сайты А и В клиента Customer 1 , для этого используем сквозной MPLS L3VPN туннель через двух ISP, имеющих свои независимые BGP AS.

              

Option A

               ISP помещают интерфейсы в сторону клиента и друг друга в одну и ту же VRF в рамках одного ISP, т.е. кроме PE1 и PE2, появляются дополнительно PEa и PEb.И в рамках каждого ISP поднимается BGP сессия, но уже в рамках AF VPNV4.Между ISP Такая же настройка как между Customer и ISP. Т.о. ISP считают друг друга такими же заказчиками, как и Customer-a 1.

Настройка:

1.      Настройка стыка Customer Site A <> ISP1:

Настройка CEa R11:

 

               Настройка PEa R1:

 

               Создали VRF CUSTOMER_A, задали значения RD и RT, для RT export и import задали разные значения, т.к. они не обязаны совпадать, главное использовать нужное значение на втором PE1 – ASBRa – R9.

 

               Проверка:

               Т.к. строим на R1 BGP сессию с R11 в рамках, то смотрим получаемые vpnv4 префиксы – получаем один vpnv4 префикс, подробнее о нем:

 

               Видим заданный RD 11:1359 и RT  export 11:1359.

 

2.      Настройка BGP vpnv4 сессии в рамках ISP 1 между PE1 и PEa (ASBRa) для передачи vpnv4 префиксов:

PE1 R1:

Было:

 

               Поднимем BGP сессию с RR R8 в рамках AF VPNV4

 

               Включим передачу community – для передачи RT:

 

               Удалим BGP сессию в рамках AF ipv4:

 

               Аналогично настроим R8 - RR и R9 – PEa (ASBRa):

 

               R8 текущая конфигурация BGP:

 

               Удаляем BGP сессии в рамках AF ipv4 и настраиваем в AF vpnv4:

 

               Новая конфигурация:

 

               Добавим передачу обоих видов community – standard и extended:

 

               Проверка – на R8 поднялась vpnv4 BGP сессия с R1 и приходит один vpnv4 префикс:

 

 

               Что это за префикс:

 

               Это префикс от R11, с RD 1359:111 и RT RT:11:1359 – именно эти значения установили на R1.

 

               Настройка R9

               Старая конфигурация:

 

 

               Переделаем конфиг BGP на R9:

   

 

 

               Проверка:

               Поднялась BGP vpnv4 BGP сессия с RR R8, но получаем ноль префиксов.

 

               Возможно не приходит префикс от R8, перезапросим BGP Update от R8:

 

               В Wireshark видим, что BGP Update, приходит:

 

 

               RT:

 

 

               RD:

 

               Но R9 не куда этот префикс импортировать, создадим на R9 vrf CUSTOMER_A и зададим RT import, равной RT export на R1, т.е. 11:1359:

 

 

               Перезапросим Update от R8:

 

               Пришел один префикс:

 

               Подробнее про него:

 

               И теперь R9 знает куда этот префикс импортировать, поэтому не отбрасывает его, а импортирует в vrf CUSTOMER_A:

 

               Т.о обеспечили передачу vpnv4 префикса между PE роутерами ISP1:

 

               Аналогично настроим ISP2.

 

               Теперь рассмотрим стык между двумя ISP.

На линке R9-R10 нужен обмен маршрутной информацией, можем использовать различные IGP и EGP протоколы, например, OSPF, EIGRP, BGP. Используем BGP – eBGP, т.к. у каждого ISP своя AS.

Текущие настройки R9 и R10:

 

 

               Настроим eBGP ipv4 сессию в рамках vrf между ISP и поместим интерфейсы в сторону соседнего ISP в эту vrf:

 

              

               Проверка:

               R10 получает от R9 один префикс 11.11.11.11/32 = это подсеть Customer-а c сайта A. Т.е. все успешно, ISP2 знает о подсети клиента за IPS1.

 

               И как видим ISP2 не видит RD и RT ISP1, а назначает префиксы клиента с сайта А свои RD и RT.

 

               Аналогично в сети ISP1 на R9:

ISP1 получил один префикс от ISP2.

 

               Подробнее какой префикс:

 

               Какие RD и RT:

               RD и RT те, что указали на ISP1, RD и RT ISP2 нам не важны, и кроме того они не передаются при обычной eBGP ipv4 сессии в рамках vrf, проверим это в Wireshark:

 

 

 

 

 

               В BGP Update нет ни RD, ни RT.

               Клиент на сайте А получает префикс с сайта B:

 

               Сейчас Data Plane не работает, настроим LDP на роутерах ISP 1 и 2:

 

 

 

 

               Настройка LDP на всех роутерах провайдеров:

 

               Запустим трассу с сайта А до сайта B:

 

               Успешно, как видим на стыке провайдеров идет чистый ipv4 пакет без меток MPLS/

 

               Первый этап – стык CE – PE,

Второй этап – постоянная до R9 метка – 24 – VPN метка,

Третий этап – 10.9.10.10 – нет метки, место где пирятся ASBR ISP1 и ISP2, летит обычный ipv4 пакет,

Четвертый этап – другая постоянная VPN метка – 23, другой ISP.

 

Проверки:

 

R1 – sh bgp vpnv4 unicast all 12.12.12.12:

Получили этот update от R9 c RT 99:1359, выходная MPLS (сервисная / BGP) метка 24, next-hop 9.9.9.9 – R9

 

R1: - sh mpls forw 9.9.9.9:

Чтобы добраться до префикса 9.9.9.9/32 должны использовать выходную метку (LDP / транспортную)  outgoing label 21 – видели эту метку в трасе на R1 – R1: trace 12.12.12.12 sou Lo1 num.

 

               Далее смотрим на R8 как достичь R9:

должны использовать выходную метку (LDP / транспортную)  outgoing label 20 – видели эту метку в трасе на R1

               Аналогично на R5:

 

Далее пакет достигает R9, R9 проверяет: R9: sh ip route vrf CUSTOMER_A:

Префикс 12.12.12.12/32 доступен через 10.9.10.10 – R10.

А эта сетка является directly connected

R9: sh ip route vrf CUSTOMER_A 10.9.10.10:

И R9 отправляет туда обычный ipv4 пакет, этот пакет доходит до R10. R10 проверяет

R10: sh bgp vpnv4 unicast all 12.12.12.12:

Получен от R2 – 2.2.2.2 и с этим префиксом 12.12.12.12 проассоциирована VPN метка 23, есть в трассе на R4, R6, R2. После R10 смотрит MPLS FIB – как достичь next-hop-а 2.2.2.2 – R2:

R10: sh mpls forw 2.2.2.2:

 :– видит outgoing LDP метку 19 – есть в трассе

 

Далее смотрим на R4 как достичь R2:

:– видит outgoing LDP метку 22 – есть в трассе

 

Ну, а далее R7 и R6 снимают метку транспортную метку:

 

 

               Перезапустим часть роутеров и проверим трассы от R11 до R12 и от R12 до R11:

 

 

VPN метки изменились, стали 24 и 23 от R1 до R2 и 25 и 23 от R2 до R1. Т.о. убедились, что генерация меток происходит исключительно только для пути в одну сторону, LSP – Label Switch Path – набор меток end-to-end, является односторонним – трафик в одну и другую сторону ходит с разными метками.

 

Итог:

Между R9 и R10 обычная BGP ipv4 сессия внутри vrf – т.е. между ISP обычная BGP сессия внутри нужной нам таблицы маршрутизации. Передаем трафик, как обычный ipv4, по сути это обычный роутинг между PE и CE устройствами.

            Т.о. Option A ничем не отличается от настройки обычного L3 VPN, нужно провести настройки на двух сторонах – на ISP1 и ISP2, каждый ISP считает себя PE, а соседа – CE.

 

Преимущества Option A: Понятность, легкость настройки, прозрачность. Каждый ISP может проводить траблшутинг независимо, пирятся только в рамках vrf.

 

Недостатки Option A – если заказчиков много, то между ASBR ISP1 и ISP2 понадобится:

1.       много интерфейсов/саб-интерфейсов – согласование между ISP номеров VLAN ID,

2.       много vrf – появляются таблицы маршрутизации в этих vrf,

3.       много BGP сессий – большой конфиг.

Т.о. Option A имеет плохую масштабируемость.

 

            Кроме того: R9: sh ip route vrf CUSTOMER_A:

 

Т.е. ASBR знают о всех префиксах заказчиков, а цель MPLS была – держать полную table route только на граничных PE устройствах, где пиримся с заказчиками, а на транзитных по отношению к заказчикам устройствах, в т.ч. на ASBP ISP1 и ISP2 не должно быть полной таблицы маршрутизации.

 

Как убрать полную table route для vrf c транзитных ASBR устройств?

 

Для этого используем Option B.