Настройка MPLS базовый уровень (в рамках одной AS).
Проработаем вопрос подключения двух разнесенных площадок двух клиентов с помощью IP/MPLS L3VPN.
В качестве лабораторной работы используем следующий стенд в EVE-NG:
Опорная сеть представлена в виде 9 маршрутизаторов (R5-R12), и шести маршрутизаторов относящихся к двум клиентам "синему" и "красному", с 5 точками подключения к опорной сети.
Для начала поднимем лупбэки с /32 маской для простой идентификации роутеров в сети. IP для лупбэка выбираем в соответствии с порядковым номером роутера. И помещаем интерфейс внутрь OSPF:
interface Loopback0
ip address 7.7.7.7 255.255.255.255
ip ospf 1 area 0
Настроим все интерфейсы в сторону соседей внутри опорной сети на участие в процессе маршрутизации ospf 1.
Укажем что это p-2-p взаимодействие.
interface GigabitEthernet1
ip address 10.5.7.7 255.255.255.0
ip ospf network point-to-point
ip ospf 1 area 0
Запустим OSPF внутри нашей опорной сети, одновременно запустив протокол распространения меток LDP в режиме автоматической конфигурации на интерфейсах участвующих в OSPF процессе:
router ospf 1
router-id 7.7.7.7
mpls ldp autoconfig
mpls ldp autoconfig - эта команда включает обмен ldp hello на всех интерфейсах где запущен OSPF.
Автоконфигурация позволяет снизить риск ошибки, когда есть работающий линк, но транспортной MPLS метки для него нет.
В случае, если путь пакета будет лежать через такой стык, то маршрутизатору придётся снимать все метки и отправлять пакет в сторону назначения по правилам маршрутизации, а не коммутации по меткам. В связи с чем пакет с сервисной MPLS меткой будет утерян, и не удастся обнаружить к какому сервису он относился.
Проверим какие интерфейсы у нас относятся к OSPF с помощью команды:
R7#sh ip ospf interface brief
Исходя из вывода команды у нас должно быть 6 интерфейсов где происходит обмен LDP hello, проверим это с помощью команды:
sh mpls ldp discovery, которая показывает на каких интерфейсах происходит обмен сообщениями. И в каком они статусе (xmit/recv)
Небольшой тюнинг для LDP.
Что бы не плодить кучу меток для всех имеющихся FEC, сделаем так что бы обмен метками был только до /32 адресов лупбэков.
Для это проверим как на текущий момент осуществляется анонс меток с помощью команды
R7#sh run all | i advertise
mpls ldp advertise-labels
Эта команда говорит что метки отдаются по дефолту для каждого FEC (дефолт для IOS). Что бы изменить это поведение нужно задать перечень всех лупбэк адресов и адвертайзить метки только до них.
Управление распространением меток выполняется с помощью команды:
mpls ldp advertise-labels for IP_ACCESS_LIST
Создаём стандартный ACL, и добавляем в него все адреса лупбэков роутеров опорной сети.
ip access-list standard LDP_LOOP_ONLY
permit 5.5.5.5
permit 6.6.6.6
permit 7.7.7.7
permit 8.8.8.8
permit 9.9.9.9
permit 10.10.10.10
permit 11.11.11.11
permit 12.12.12.12
permit 13.13.13.13
Применяем команду на всех роутерах внутри домена.
mpls ldp advertise-labels for LDP_LOOP_ONLY
Кусок вывода команды
sh mpls ldp binding:
Обратить внимание стоит на то, что мы получили метки для всех адресов /32. Для подсетей с более широкой маской имеем только локальную метку, которую так же никуда не анонсируем.
Авторизация LDP соседей:
Для безопасности внутри опорной сети настроим авторизацию по паролю для всех LDP соседей. Для начала назначим глобально требование пароля для всех LDP соседей.
mpls ldp password required
А затем зададим его в режиме глобальной конфигурации через option 1, для всех соседей указанных в стандартном ACL с названием PEER_AUTH.
mpls ldp password option 1 for PEER_AUTH password
Теперь наши соседи защищены от не авторизованного подключения к mpls домену.
Переходим к созданию первого MPLS сервиса для "Синего" Клиента.
Обмен маршрутной информацией на участке СЕ-РЕ - статика.
Со стороны Клиента дефолт
ip route 0.0.0.0 0.0.0.0 IP_PE
Со стороны PE статика до Lo0 CE(R14).
ip route ip_loopack_0 IP_CE
Конфигурация со стороны PE(R12)
1. Создаём vrf:
vrf definition VRF_BLUE
rd 12.12.12.12:100
address-family ipv4 u
route-target both 100:100
2. Помещаем интерфейсы внутрь vrf:
int g 2
vrf forwarding VRF_BLUE
ip add 10.12.15.12/24
3. Настраиваем BGP между PE и RR:
router bgp 100
no bgp default ipv4-unicast
neighbor 9.9.9.9 remote-as 100
neighbor 9.9.9.9 update-source lo0
address-family vpnv4 unicast
neighbor 9.9.9.9 activate
5.Анонсируем маршруты в BGP которые имеем внутри vrf в AF ipv4 unicast для vrf VRF_BLUE
router bgp 100
address-family ipv4 unicast vrf VRF_BLUE
network 15.15.15.15 mask 255.255.255.255 (Lo0 R15)
network 10.12.15.0 mask 255.255.255.0 (p2p R12-R15)
6. Настраиваем RR для нашей опорной сети
router bgp 100
bgp log-neighbor-changes
no bgp default ipv4-unicast
neighbor 5.5.5.5 remote-as 100
neighbor 5.5.5.5 update-source Loopback0
neighbor 6.6.6.6 remote-as 100
neighbor 6.6.6.6 update-source Loopback0
neighbor 12.12.12.12 remote-as 100
neighbor 12.12.12.12 update-source Loopback0
address-family vpnv4
neighbor 5.5.5.5 activate
neighbor 5.5.5.5 send-community extended
neighbor 5.5.5.5 route-reflector-client
neighbor 6.6.6.6 activate
neighbor 6.6.6.6 send-community extended
neighbor 6.6.6.6 route-reflector-client
neighbor 12.12.12.12 activate
neighbor 12.12.12.12 send-community extended
neighbor 12.12.12.12 route-reflector-client
exit-address-family
7. Настраиваем второй РЕ маршрутизатор.
vrf definition VRF_BLUE
rd 6.6.6.6:100
address-family ipv4 u
route-target both 100:100
int gi 2
vrf forwarding VRF_BLUE
ip add 10.4.6.6/24
router bgp 100
no bgp default ipv4-unicast
neighbor 9.9.9.9 remote-as 100
neighbor 9.9.9.9 update-source lo0
address-family vpnv4 unicast
neighbor 9.9.9.9 activate
address-family ipv4 unicast vrf VRF_BLUE
network 4.4.4.4 mask 255.255.255.255 (Lo0 R4)
network 10.4.6.0 mask 255.255.255.0 (p2p R4-R6)
Между СЕ-РЕ динамическая маршрутизация.OSPF
1. На СЕ(R4) поднимаем оспф, анонсируем лупбэк и р2р сеть
router ospf 1
router-id 4.4.4.4
network 4.4.4.4 0.0.0.0 area 0
network 10.4.6.0 0.0.0.255 area 0
2. На РЕ(R6) поднимаем OSPF процесс внутри VRF_BLUE, и анонсируем туда линковую подсеть для поднятия соседства.
router ospf 6 vrf VRF_BLUE
router-id 100.6.6.6
network 10.4.6.0 0.0.0.255 area 0
3. На РЕ(R6) делаем редистрибьюцию из OSPF в BGP внутри AF ipv4 vrf VRF_BLUE
address-family ipv4 vrf VRF_BLUE
redistribute ospf 6
exit-address-family
4. После этого маршрут от СЕ(R4) попадает к нам на второй РЕ(R12) с помощью BGP апдейта
Что бы анонсировать этот апдейт в оспф делаем редистрибьюцию из bgp в ospf на R12.
router ospf 100 vrf VRF_BLUE
redistribute bgp 100 subnets
После этого на СЕ(R15) появляются анонсы OSPF маршрутов от СЕ(R4)
Но при редистрибьюции РЕ(R12) определил данную подсеть как подсеть из другой автономной системы из-за разного domain-id. И отправил её клиенту как OSPF external type 2.
Учитывая что Клиент хочет от нас увидеть прозрачный L3 сервис, то нужно эту ситуацию устранять.
Причины ниже:
Из-за того что у нас разные OSPF процессы на двух РЕ, мы имеем различные OSPF DOMAIN ID, которые передаются в BGP анонсе в Extended Comminity.
Вылечить это можно задав одинаковый OSPF process с двух сторон, либо задав вручную domain id для одного из OSPF процессов.
R12(config)#router ospf 100
R12(config-router)#domain-id type ?
0005 Type 0x0005
0105 Type 0x0105
0205 Type 0x0205
8005 Type 0x8005
R12(config-router)#domain-id type 0005 value 000000060200
После синхронизации domain-id на СЕ(R15) имеем маршрут помеченный как inter-area.
5. Выполняем редистрибуцию в обратную сторону, в направлении к CE(R4) аналогично п.3-4.
6. Проверяем наличие маршрута в СЕ(R4) и IP связность с Lo0 CE(R15)
Проверки успешные.
При трассировке видим наличие меток на 2,3,4 хопах, при этом на 4 хопе метка остаётся одна, давайте разберёмся с этим.
На PE(R6) смотрим в маршрутную информацию, для поиска сервисной метки (второй в стеке).
1. Первый хоп, с ним всё понятно, пинг на участке CE-PE.
2.Второй хоп, имеем две метки, сервисная 36
и транспортная 32, т.к. идём через R8
3. Траспортная метка меняется на туже самую. Сервисная остаётся без изменений.
4. Транспортная метка снимается, т.к. стоит POP Label. Сервисная следует дальше.
5. Сервисная метка так же снята, пинг внутри vrf VRF_BLUE:
SHAM-link
Для того что бы разобраться с этой функцией добавим между двумя роуетерами "Синего" Клиента линк, эмулирующий резервный L2 канал от другого оператора.
Поднимаем линк и видим что трафик и вся маршрутная информация начала ходить через новый линк. Это не правильно, не зря же мы платим оператору за услугу L3 VPN.
И даже если мы выкрутим стоимость на диркетли конектед линках это не даст желаемого результата, потому что директли линк имеет LSA 1 type и он всегда будет выигрывать у LSA 3 type получаемого через опорную сеть.
Если посмотреть со стороны РЕ(R12) то у него тоже взаимодействие с R4 будет осуществляться через внутренний линк, а не через опорную сеть.
Исправить это может SHAM-link
Для этого создаём интерфейс Lo100 на РЕ(R12) внутри vrf VRF_BLUE, и анонсируем данный префикс в BGP.
Делаем аналогичные настройки со стороны второго РЕ(R6) и проверяем наличие анонса внтури VRF.
Далее в настройках OSPF процесса находящегося внутри VRF выполняем команду по поднятю SHAM-link внутри area 0. Вручную выставляем IP адрес источника и назначения (lo100).
Делаем аналогичные настройки с другой стороны и видим сообщение о поднятии OSPF_SL0
Со стороны РЕ(R6)
После выполнения этой команды на СЕ(R4) смотрим таблицу маршрутизации и видим что теперь СЕ(R15) доступен через опорную сеть, и благодаря sham-link'у изменился тип маршрута, теперь это так же LSA 1 type.
Трассировка через опорную сеть.
Организация стыка CE-PE на базе протокола BGP
Для отработки сценариев имплементации BGP будем подключать клиента "Красного" цвета к опорной сети.
Создаём VRF_RED,
Запускаем eBGP в рамках VRF на РЕ(R12)- и в GRT запускаем BGP на CE(R14)
РЕ(R12)
vrf definition VRF_RED
rd 12.12.12.12:200
address-family ipv4
route-target export 100:200
route-target import 100:200
exit-address-family
router bgp 100
address-family ipv4 vrf VRF_RED
neighbor 10.12.14.14 remote-as 65100
neighbor 10.12.14.14 activate
exit-address-family
interface GigabitEthernet2
vrf forwarding VRF_RED
ip address 10.12.14.12 255.255.255.0
CE(R14)
router bgp 65100
network 14.14.14.14 mask 255.255.255.255
neighbor 10.12.14.12 remote-as 100
interface GigabitEthernet2
ip address 10.12.14.14 255.255.255.0
После того как поднялось соседство видим один анонсируемый маршрут на РE(R12):
Сервисная метка для этого префикса 39.
Переходим к настройке BGP на этом учатске:
Со стороны клиента RED у нас поднят OSPF, там делаем фулмеш iBGP взаимодействие. И поднимаем eBGP с PE(R5) и PE(R6)
Вывод команды со стороны CE(R3)
После настройки фулмеш iBGP топологии, анонсим Lo0 на R1.
На PE(R12) видим эти маршруты:
Однако этих маршрутов нет на СЕ(R14). Запустим дебаг и перезапросим анонсы от PE(R12)
По выводу видим что апдейт до 1.1.1.1/32 отброшен, так как AS-PATH содержит нашу собственную AS.
Есть два способа устранения этой проблемы:
BGP as-override это технология замены AS в AS-path на номер AS провайдера если он видит что отдаёт маршрут в ту же самую AS откуда он её получил, в случае если эта AS первая в пути.
allowas-in позволяет не делать AS-path lookup при принятии анонсов.
Настройка на стороне СЕ.
Сделаем BGP as-override на PE(R12)
После этого на CE(R14) пришёл анонс для 1.1.1.1
Можно так же выплнить команду allowas-in, результат такой же, сейчас СЕ игнорирует наличие своей AS в AS-path от конкретного соседа.
На этом данный курс завершен, переходим к продвинутому курсу -->