Сегодня настрою и посмотрю как работает MPLS на стыках между разными AS, с использованием разных опций (A, B, C) на этой топологии:
Задача не просто провести настройку всех устройств по очереди, а именно шаг за шагом проследить за распространением маршрутной информацией, и за дата плейном, поэтому иногда я буду возвращаться к предыдущим этапам и добавлять недостающие блоки конфигурации.
В данной топологии имеем 4 AS: 65550, 65770, 65990 и 65220, выполняющих роль различных Интернет провайдеров, и четыре роутера (R17-R20) Клиента компании "Sky", которой нужна услуга L3 VPN между всеми филиалами.
AS Клиента на всех четырёх стыках 12345, маршрутизация на стыке CE-PE у нас будет eBGP.
Для простоты настройки топология внутри AS операторов идентичная.
В качестве IGP поднят OSPF процесс 1, все роутеры внутри AS в зоне 0.
Внутрь OSPF проанонсированы интерфейсы Lo0, соответствующие порядковому номеру роутера (для R8 Lo0 = 8.8.8.8/32)
Для связности роутеров между собой используется сеть из диапазона 10.0.0.0/8, где порядковые номера роутеров использованы во втором и третьем октетах начиная с меньшего. (например между R6 и R8 подсеть 10.6.8.0/24)
Для передачи апдейтов поднят iBGP vpnv4 uniacst между всеми роутерами с роут рефелектором для каждой AS.
На текущий момент имеем IP связность внутри AS, настроен базовый MPLS, пинг c метками:
Настройка inter-AS option A.
Выполним настройку на первом inter-AS стыке с помощью opt. A.
С точки зрения Клиента SKY у нас eBGP пиринг на участке CE-PE.
Анонсим Lo0 CE(R17) внутрь eBGP.
На РЕ(R1) создаём vrf SKY.
Линк в сторону CE(R17) помещаем внутрь этого vrf.
Поднимаем пиринг в рамках AF ipv4 vrf SKY
На РЕ(R1) получаем апдейт и смотрим куда мы его анонсим:
В выводе команды мы видим что апдейт до 17.17.17.17/32 мы анонсим в апдейт-группу 2 в которой находится наш RR(R4).
В апдейте мы видим RT:65550:12345 который мы отдаём на экспорт, и метку, которую нужно использовать в качестве сервисной, для достижения FEC 17.17.17.17/32.
Смотрим этот анонс на RR(R4)
Данные не изменные, передаются на ASBR(R3).
На ASBR(R3) у нас нет vrf, поэтому мы пока не можем ничего принять:
Создаём vrf SKY.
Помещаем линк в сторону ASBR(R7) внутрь vrf SKY.
Поднимаем eBGP пиринг в рамках AF ipv4 vrf SKY
Апдейт получен, помещён в RIB vrf SKY, и адвертайзится в сторону eBGP соседа.
Проделываем аналогичные дейсвтия внутри AS 65770:
Создаём vrf SKY на ASBR (R7) и PE(R5)
Помещаем линк на ASBR (R7) в сторону ASBR(R3) и на и PE(R5) в сторону CE(R18) внутрь vrf SKY.
Поднимаем eBGP пиринг в рамках AF ipv4 vrf SKY на ASBR (R7) и PE(R5).
На CE(R18) так же анонсим Lo0 (18.18.18.18/32) в BGP.
И проверяем результат.
На PE(R5) видим маршруты от CE(R17) и от CE(R18)
На PE(R1) так же видим маршруты от CE(R17) и от CE(R18)
Но на самих CE этих маршрутов нет, из-за BGP loop prevention.
Посмотрим как мы анонсим маршрут в от PE(R5):
Поэтому на CE(R18) данный анонс не принимается.
Пропишем команду на РЕ(R5) внутри AF ipv4 vrf SKY:
neighbor 10.5.18.18 as-override
После этого на CE(R18) в апдейтах уже не видит свою AS.
Сделаем тоже самое на всех PE(R1,R5,R9,R13).
Проверяем на CE(R17) наличие маршрутной информации и доступность хостов между Lo0:
Как видно маршруты пришли, трассировка показывает что на 4 хопе, между ASBR(R3) и ASBR(R7) у нас нет никаких меток, это особенность opt.A, трафик передаётся без метки, как если бы к нам был подключен сам Клиент, а не другая AS.
Особенности option A (back to back vrf):
Пиринг vpnv4 между PE+RR+ASBR внутри vrf
ebgp AF ipv4 vrf XXX на PE.
Настройка inter-AS option B.
Особенностью данного метого является поднятие eBGP vpnv4 сессии между ASBR'ами, которые будут передавать vpnv4 апдейты внутрь своей AS.
Настроим eBGP vpnv4 пиринг на ASBR(R7) и ASBR(R11)
Как видим по сообщению из лога у над поднялся пиринг, и автоматически включился mpls bgp forwarding на стыке между ASBR'ами:
Но маршрута на ASBR(R11) нет.
Это связано с дефолтным поведением BGP -фильтровать расширенные комюнити, если нет настроенных RT на импорт:
Отключим это поведение на обоих ASBR
После чего получаем два апдейта от eBGP соседа:
Анонсим данный маршрут нашему RR(R12), добавляем метку 22 на IN, 22 на OUT мы получили от eBGP соседа.
Смотрим что у RR(R12):
Маршрут пришёл, но некст-хоп не доступен (т.к. мы не заводили в BGP линковую сеть для eBGP), поэтому он никуда не адвертайзится.
Это одна из-особенностей opt. B, ASBR должен ставить next-hop-self в сторону RR(R12) внутри AF vpnv4 unicast . Сделаем это на ASBR(R11)
Теперь маршрут имеет валидный next-hop, он анонсится в сторону РЕ(R9) с RT:65770:12345, идём ловить его на PE(R9)
На PE(R9) маршрутов не получаем, заглянем в debug:
Маршруты отбрасываются. Мы тут ничего не ждём на импорт, но так как R9 у нас PE маршрутизатор, то:
Создаём vrf SKY.
Помещаем линк в сторону CE(R19) внутрь vrf SKY.
Поднимаем eBGP пиринг в рамках AF ipv4 vrf SKY
Маршруты есть на CE(R19), но нет пинга, до CE(R18) в другой AS,
Идём разбираться, на PE(R9) мы анонсим апдейт от CE(R19) Lo0 19.19.19.19/32 c RT 65990:12345, и вероятнее всего проблема в том что мы его никуда не импортировали.
Сразу посмотрим на RR(R8) AS 65770 (вспоминаем топологию):
На RR(R8) видим анонс, видим что отправляем его на PE(R5), отправляем с RT 65990:12345.
Такой RT на PE(R5) мы не принимаем.
Добавляем RT на импорт, и проверяем наличие связности c CE(R19).
Связность есть, обратить внимание нужно на 4 хоп, это у нас Inter-AS стык с опцией B, здесь трафик с сервисной меткой 22, которую выдал ASBR(R7)
Так теперь нам нужно передать этот апдейт в сторону нашего CE(R17) через opt. A.
Вспоминаем топологию:
Так как ASBR(R7) является ещё и PE(R7) для опции А, то нужно просто импортировать маршрут из AS 65990 с RT 65990:12345 внутрь vrf SKY:
Теперь на CE(R17) есть апдейт до Lo0 CE(R19) и есть IP связность:
Особенности option B
Тоже самое что для option A, плюс:
Пиринг между ASBR eBGP vpnv4 unicast
no bgp default community filter на ASBR
next-hop-self между ASBR и RR в iBGP AF vpnv4 unicast
Настройка inter-AS option C.
Концептуально, для Option C, нам нужно обмениваться маршрутной информацией между RR двух AS.
Что бы это реализовать нам нужно распространить между ASBR(R15 и R11) информацию о лупбеках наших RR(R16 и R12) с помощью eBGP labeled unicast (LU).
Что бы они могли построить eBGP vpnv4 сессию.
Приступим к настройке, поднимаем на стыке AS eBGP LU.
На ASBR(R15) прописываем:
Так же поднимаем iBGP LU между ASBR(R15) и RR(R16).
На RR(R16) анонсируем Lo0 16.16.16.16/32 в iBGP. И проверяем апдейт на ASBR(R15)
На RR(R12) мы не можем инсталировать этот маршрут так как eBGP стык не анонсится, и внутри ipv4 на ASBR (R11) не прописано next-hop-self.
Делаем тоже самое на ASBR(R15) и у нас появилась связность между RR(R16 и R12).
Настраиваем eBGP vpnv4 сессию между двумя RR(R16 и R12), учитывая количество eBGP хопов до соседа:
Сессия поднялась и на RR(R16) мы видим 3 апдейта от RR(R12):
Данные апдейты анонсятся на РЕ(R13), создадим там vrf SKY, сделаем RT на импорт 65990:12345 поднимем eBGP сессию с Клиентом, всё как всегда.
Но PE(R13) не хочет инсталировать данный маршрут, т.к. для него RR(R12) не доступен.
Добавим в iBGP AF ipv4 LU так же все PE(R13,R9) и их Lo0, и ASBR(R15, R11) в качестве RR-client'ов.
Апдейты прилетели, есть связность между CE(R19) и CE(R20):
Но как можно заметить по трассировке, в дата плейне присутствуют RR'a.
Это связано с дефолтным поведение eBGP сессии, в виде замены некст-хопа на свой. Изменим это поведение командой next-hop-unchenged на R12 и R16
Другое дело, меньше на 2 хопа, и сервисная метка не меняется до конца пути, т.к. анонсит её сразу PE(R13).
Остался последний штрих, принять маршруты от оставшихся AS для AS65220. Смотрим что нам анонсит RR(R16)
Как мы видим префиксы от обоих оставшихся AS 65550 и 65770 нам анонсит ASBR(R11) с RT 65770:12345. Добавим этот RT на PE(R13):
Маршруты есть и на CE(R20). Сейчас давайте разберёмся с какими RT прилетает наш анонс на RR остальных AS:
В AS 65990 на RR(R8):
Добавим RT 65220:12345 на PE(R5).
На CE(R18) есть связность с CE(R20)
В AS 65550 на RR(R4):
Тут её нет, потому что мы не импортировали её на ASBR/PE(R7), для передачи апдейта по опции A. Сделаем это.
Снова смотрим на RR(R4)
Тут анонс прилетает от ASBR(R3) с RT 65550:12345. На PE(R1) этот RT настроен на импорт. Смотрим на CE(R17)
Все CE(R18, R19, R20) доступны.
Запустим трассировки:
Ещё было интересно как будут обстоять дела с RT на импорт/экспорт при таком взаимодействии, картина следующая:
Во всех случаях, кроме опции A, импортируются RT со всех AS.
Подведём итог
Option C
eBGP LU между ASBR / Neighbor x.x.x.x send-label
Поднимаем iBGP LU между RR, ASBR и PE
Анонсируем Lo0 RR, ASBR и PE в iBGP AF ipv4
Поднимаем еBGP vpnv4 сессию между RR, учитывая:
Neighbor x.x.x.x ebgp-multihop
Neighbor x.x.x.x next-hop-unchanged
Спасибо за внимание.