Articles

Автор: Ярослав Бондаренко

Категория: Articles

Опубликовано: 20 августа 2021

Создано: 20 августа 2021

Обновлено: 23 августа 2021

Просмотров: 3692

Disclaimer: только для гиков; устаревшая технология; статья в режиме “just for fun”.

Разобравшись со смузи и подворотами, можем приступить к сути статьи – BGP synchronization в связке с OSPF. Стоит сразу отметить, что технология BGP sync действительно не является актуальной уже лет дцать и многие современные платформы даже не поддерживают её. В своё время я наткнулся на довольно занятное описание одной особенности BGP sync при использовании с OSPF в качестве IGP и хотел бы поделиться полученным опытом.

Впрочем, займёмся лабой; чем меньше топология, тем проще её анализировать:

На данный момент настроена лишь базовая адресация:

R1(config)#int f0/0
R1(config-if)#ip address 192.168.12.1 255.255.255.0
R1(config-if)#no shutdown

R2(config)#int f0/0
R2(config-if)#ip address 192.168.12.2 255.255.255.0
R2(config-if)#no shutdown
R2(config)#int f0/1
R2(config-if)#ip address 192.168.23.2 255.255.255.0
R2(config-if)#no shutdown

R3(config)#int f0/1
R3(config-if)#ip address 192.168.23.3 255.255.255.0
R3(config-if)#no shutdown

Включим BGP вместе с synchronization на R1 и R3:

R1(config)#router bgp 1
R1(config-router)#synchronization 
R1(config-router)#neighbor 192.168.23.3 remote 1

R3(config)#router bgp 1
R3(config-router)#synchronization 
R3(config-router)#neighbor 192.168.12.1 remote 1

Самое время добавить щепотку тестовых маршрутов. Создадим loopback 0 на R1 с адресом 1.1.1.1/32 и добавим его в BGP:

R1(config)#interface Loopback 0
R1(config-if)#ip address 1.1.1.1 255.255.255.255
R1(config)#router bgp 1 
R1(config-router)#network 1.1.1.1 mask 255.255.255.255

Теперь можно включить в схеме OSPF, чтобы обеспечить связность между BGP маршрутизаторами:

R1(config)#int f0/0
R1(config-if)#ip ospf 1 area 0

R2(config)#router ospf 1
R2(config-router)#network 0.0.0.0 255.255.255.255 area 0

R3(config)#int f0/1
R3(config-if)#ip ospf 1 area 0

На данный момент маршрут должен быть в BGP RIB на R3, однако он не может быть установлен в global RIB вследствие BGP sync:

R3#sho ip bgp 1.1.1.1/32
BGP routing table entry for 1.1.1.1/32, version 0
Paths: (1 available, no best path)
 Not advertised to any peer
 Refresh Epoch 1
 Local
 192.168.12.1 (metric 2) from 192.168.12.1 (192.168.12.1)
 Origin IGP, metric 0, localpref 100, valid, internal, not synchronized

R3#sho ip bgp
<output omitted>

 Network Next Hop Metric LocPrf Weight Path
 * i 1.1.1.1/32 192.168.12.1 0 100 0 i

Синхронизация в своё время была призвана защитить сеть от возникновения дыр маршрутизации, когда маршрут известен на оконечных BGP маршрутизаторах, но не на транзитных устройствах. Исправим возникшую “проблему”, добавив 1.1.1.1/32 в сеть OSPF c помощью переноса этого маршрута из BGP:

R1(config)#router ospf 1
R1(config-router)#redistribute bgp 1 subnets

На данный момент iBGP маршрут известен и по BGP, и по OSPF, поэтому он должен пройти проверку BGP sync, однако по какой-то причине 1.1.1.1/32 до сих пор находится в состоянии not synchronized:

R3#sho ip bgp
<output omitted>

Network Next Hop Metric LocPrf Weight Path
* i 1.1.1.1/32 192.168.12.1 0 100 0 i

R3# sho ip bgp 1.1.1.1/32
BGP routing table entry for 1.1.1.1/32, version 3
Paths: (1 available, no best path)
 Not advertised to any peer
 Refresh Epoch 1
 Local
 192.168.12.1 (metric 2) from 192.168.12.1 (192.168.12.1)
 Origin IGP, metric 0, localpref 100, valid, internal, not synchronized

Мне не удалось найти сколько-то внятного дебага, который пролил бы свет на причину этого поведения. Впрочем, существует довольно любопытная заметка по отладке BGP:

If BGP synchronization is enabled, there must be a match for the prefix in the IP routing table in order for an internal BGP (iBGP) path to be considered a valid path. <...> If the matching route is learned from an Open Shortest Path First (OSPF) neighbor, its OSPF router ID must match the BGP router ID of the iBGP neighbor.

Вольный перевод

Если функция BGP synchronization включена, должно быть соответствие между маршрутом в базе данных BGP и таблице маршрутизации, чтобы такой маршрут, полученный по iBGP, считался корректным. <...> В случае, если маршрут известен по OSPF, то OSPF RID соседа должен совпадать с RID соседа iBGP.

Мне кажется, что было бы несколько точнее сформулировать вышеизложенную мысль следующим образом: BGP RID должен совпадать с OSPF RID внутри соответствующего LSA5, в нашем случае – 1.1.1.1/32. Разница между двумя формулировками заключается в том, что iBGP сосед не обязан быть OSPF соседом. Также стоит отметить, что в силу применения BGP sync на стыке транзитной и внешней сетей эта функция учитывает только LSA5, внутренние OSPF маршруты при этом она игнорирует (я оставлю проверку этого факта на совести внимательного читателя).

Сможете, вооружившись этим знанием, определить RID для OSPF и BGP? Если вы полагаете, что это 1.1.1.1/32 для OSPF и 192.168.12.1 для BGP – вы угадали:

R3#sho ip bgp neighbors | i ID 
 BGP version 4, remote router ID 192.168.12.1
R3#sho ip ospf database external | i Advertising
 Advertising Router: 1.1.1.1

Поскольку мы создали loopback после инициализации процесса BGP, последний использовал наименьший IP адрес на физических интерфейсах в качестве RID; что касается OSPF, то он уже мог выбрать RID среди интерфейсов типа loopback. Проверим, что корень проблемы - это несовпадение RID:

R1(config)#router bgp 1
R1(config-router)#bgp router-id 1.1.1.1

R3#sho ip bgp
<output omitted>
Network Next Hop Metric LocPrf Weight Path
 r>i 1.1.1.1/32 192.168.12.1 0 100 0 I

R3#sho ip bgp nei | i ID
 BGP version 4, remote router ID 1.1.1.1
R3#sho ip ospf database external | i Advertising
 Advertising Router: 1.1.1.1

Как мы видим, теперь маршрут является корректным с точки зрения BGP, и его можно передавать дальше.

BGP synchronization, хоть и кошмарил раньше кандидатов на CCIE, теперь ушёл на покой, так что эта тема сейчас находится под грифом “just for fun” в библиотеке сетевых знаний.

Подробности

Автор: Ярослав Бондаренко

Родительская категория: Articles

Категория: Articles

Опубликовано: 27 ноября 2020

Создано: 27 ноября 2020

Обновлено: 15 апреля 2021

Просмотров: 6518

OSFP, будучи link-state протоколом, исключает петли в топологии за счёт построения дерева кратчайшего пути в рамках одной зоны с помощью алгоритма Дейкстры. Однако поведение OSPF между зонами напоминает скорее поведение distance-vector протоколов, которые обмениваются всего лишь префиксами и соответствующими метриками без каких-либо данных о фактической топологии; по этой причине некоторые авторы могут называть OSPF гибридным протоколом маршрутизации. Механизм защиты от петель маршрутизации между зонами, однако, довольно прост: все зоны должны обмениваться маршрутной информацией через backbone зону, зону 0, прямой обмен маршрутами между зонами невозможен.

Впрочем, тёмный гений изобрёл инструмент разрушения стройной идеи OSPF – речь о функции OSPF Virtual Link (VL). Даже маленькие инженеры знают, что использовать VL – плохая затея; все согласны с тем, что VL оправдан только в крайних случаях для временного и быстрого исправления критичной ситуации. Однако обнаружить подробное объяснение, чем же именно VL так плох помимо дополнительного уровня сложности, оказалось не так-то просто. Сложность инженерам не помеха, поэтому давайте поищем более весомые аргументы против VL.

Нет ничего лучше чашки кофе с утра, рабочей лабы и широкополосного доступа к google.com. Для эмуляции топологии в GNS3 были использованы образы Cisco 7200:

На каждом маршрутизаторе в соответствующей зоне настроен виртуальный интерфейс (loopback0) для назначения OSPF RID и других инфраструктурных задач; loopback на ABR находятся в зоне 0. Схема адресации: 192.168.xy.x|y/24 для соединения Rx и Ry (например, 192.168.12.1 на интерфейсе f0/1 R1). Помимо штатной настройки OSPF, между R1 и R3 создан VL.

Если у читателя много свободного времени, можно убедиться в доступности всех префиксов из любой точки сети; я же сконцентрируюсь на связности R1 и R5:

R1#ping 5.5.5.5 so lo 0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 5.5.5.5, timeout is 2 seconds:
Packet sent with a source address of 1.1.1.1 
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 20/30/40 ms
R1#traceroute 5.5.5.5 so lo 0 numeric
Type escape sequence to abort.
Tracing the route to 5.5.5.5
VRF info: (vrf in name/id, vrf out name/id)
 1 192.168.14.4 16 msec 24 msec 20 msec
 2 192.168.45.5 48 msec 16 msec 24 msec

Трафик следует по кратчайшему маршруту, как и задумывалось. Перейдем к гвоздю сегодняшней программы:

 R1(config)#router os 1
R1(config-router)#no capability transit

Transit area capability – это способность OSPFv2 выбрать более оптимальный маршрут для трафика, следующего по VL. Идея довольно проста: необходимо взять префикс, доступный через VL, и сравнить его с имеющимися LSA3; если найдено полное совпадение и маршрут через LSA3 оптимальнее, то следует использовать оптимальный маршрут. OSPFv1 не обладал такой функцией, и весь трафик следовал по тому же пути, что и VL. Если читатель хочет глубже погрузиться в данную тему, могу порекомендовать статью Петра Лапухова. А мы продолжаем:

R1#traceroute 5.5.5.5 so lo 0 n
Type escape sequence to abort.
Tracing the route to 5.5.5.5
VRF info: (vrf in name/id, vrf out name/id)
 1 192.168.12.2 44 msec 16 msec 20 msec
 2 192.168.23.3 20 msec 40 msec 40 msec
 3 192.168.35.5 76 msec 44 msec 44 msec

Изменения есть, но они некритичны: теперь R1 выбирает путь вдоль VL в полном соответствии с поведением OSPFv1 без transit capability. Где же обещанная петля? Добавим нашей топологии некоторой пикантности:

R2	R3
R2(config)#int f1/0 R2(config-if)#ip os cost 100	R3(config)#int f1/0 R3(config-if)#ip os cost 100

Ухудшили плохой маршрут, и что с того?

R1#traceroute 5.5.5.5 so lo 0 n
Type escape sequence to abort.
Tracing the route to 5.5.5.5
VRF info: (vrf in name/id, vrf out name/id)
 1 192.168.12.2 20 msec 16 msec 16 msec
 2 192.168.12.1 24 msec 16 msec 16 msec
 3 192.168.12.2 36 msec 32 msec 44 msec
 4 192.168.12.1 28 msec 36 msec 40 msec
 5 192.168.12.2 44 msec 48 msec 64 msec
 6 192.168.12.1 60 msec 60 msec 60 msec
 7 192.168.12.2 80 msec 80 msec 80 msec
 8 192.168.12.1 84 msec 76 msec 76 msec

Дамы и господа, это – петля. Теперь взглянем на проделанную работу:

• VL между R1-R3;
• Transit capability отключена;
• Метрика R2-R3 увеличена.

Последний пункт стоит отметить особо: в результате изменения метрики R1 является next-hop для 5.5.5.5/32 с точки зрения R2:

R2#sho ip ro 5.5.5.5 255.255.255.255 longer-prefixes 
 5.0.0.0/32 is subnetted, 1 subnets
O IA 5.5.5.5 [110/4] via 192.168.12.1, 00:06:21, FastEthernet0/1

Выбор маршрута с точки зрения R2 выглядит довольно естественно; выбор R1 же может показаться странным на первый взгляд:

R1#sho ip ro 5.5.5.5 255.255.255.255 longer-prefixes 
 5.0.0.0/32 is subnetted, 1 subnets
O 5.5.5.5 [110/103] via 192.168.12.2, 00:08:07, FastEthernet0/1

Однако такое поведение вполне соответствует правилам выбора маршрута в OSPFv1:

• 5.5.5.5/32 доступен через VL в зоне 0;
• трафик следует по тому же пути, что и VL.

R2 ничего не знает ни про VL, ни про transit area; он всего ли маршрутизирует пакеты согласно таблице маршрутизации, построенной на основе LSA3.

На данном этапе может показаться, что причина всех бед – transit capability, а не VL. Впрочем, разрешается этот вопрос довольно просто: подобная проблема была обнаружена в OSPFv1 и решена в OSPFv2 посредством transit area. Читатель может заметить, что описанное поведение родственно по природе микропетлям, возникающим в ходе перестроения дерева, и с ним трудно не согласиться. Впрочем, разница есть и существенная: микропетли представляют собой переходное состояние. тогда как петли из-за VL в OSPFv1 носили постоянный характер.

Немного английского оригинала из OSPFv2 RFC про отличия от OSPFv1:

“When summarizing information into a virtual link's transit area, version 2 of the OSPF specification prohibits the collapsing of multiple backbone IP networks/subnets into a single summary link.”

Проблема, завуалированная авторами RFC в этой фразе, очень похожа по характеру на рассматриваемую в статье. Если бы маршруты зоны 0 можно было бы суммаризовать на ABR, то полученный префикс в LSA3 не смог бы быть использован маршрутизатором с VL. Передача трафика была бы нарушена вследствие разного представления о топологии маршрутизаторами зоны:

1. Маршрутизатор с VL выбрал бы маршрут из зоны 0; из-за отсутствия точно совпадающего LSA3 был бы выбран путь вдоль VL;
2. Остальные же маршрутизаторы использовали бы суммарный маршрут из LSA3.

В нашем случае, если бы R3 суммаризовал маршрут до 5.5.5.0/24, то R2 выбрал бы более точный маршрут 5.5.5.0/25 через R4, что привело бы к петле маршрутизации. Решение? Нужно обеспечить всем маршрутизаторам зоны равный доступ к маршрутной информации из зоны 0, запретив изменение последней, т.е. суммаризацию. Стоит отметить, что это не относится к маршрутам из других зон, поскольку эти суммарные маршруты будут одинаковы как в зоне 0, так и других зонах; только ABR зоны-источника могут суммаризовать информацию о топологии из LSA1/2 в простой LSA3. Более того, запрещена только суммаризация префиксов из зоны 0, фильтрация же не ограничена. Последняя не изменяет сам префикс; в результате у маршрутизаторов зоны будет меньше пар LSA1-LSA3 для выбора более оптимального маршрута, что не может привести к описанной в статье проблеме.

Вывод: некоторые малоизвестные настройки по умолчанию лучше не трогать.

P.S. Существует не менее интересный способ выстрелить себе в ногу.

Автор: Ярослав Бондаренко

Категория: Articles

Опубликовано: 15 апреля 2021

Создано: 15 апреля 2021

Обновлено: 22 апреля 2021

Просмотров: 4358

DMVPN является известным решением для построения топологий hub&spoke. В ряде случаев может понадобиться поддержка изолированной передачи трафика различных клиентов. Конечно, можно построить DMVPN туннель в каждом VRF; однако в реальной жизни такой подход не является достаточно масштабируемым. В такой ситуации на ум приходит MPLS, который зарекомендовал себя в корпоративных и провайдерских сетях.

GRE поддерживает инкапсуляцию различных PDU, в том числе и MPLS, поэтому, на первый взгляд, не должно возникнуть проблем на уровне передачи трафика. С управляющими протоколами, однако, ситуация обстоит несколько сложнее. LDP и RSVP должны установить соседство перед тем, как обменяться какими-либо данными. Масштабируемость этих протоколов обусловлена использованием мультикаста для обнаружения соседей и обмена с ними необходимыми параметрами протокола. Ручная настройка LDP/RSVP соседства в DMVPN сведёт на нет масштабируемость, поэтому такой сценарий статья не рассматривает. Использование же мультикаста ограничивает функциональность решения, поскольку spoke могут обмениваться такими сообщениями только с hub, что исключает наличие spoke-to-spoke связности с использованием MPLS.

Впрочем, существует третье решение, которое является достаточно масштабируемым, а также способно обеспечить MPLS-связность spoke-узлов между собой – это BGP labeled unicast (BGP LU). Существует несколько способов превратить spoke-маршрутизатор в PE (например, первый вариант – отправить пакет с VPN меткой напрямую другому spoke, аналог второй фазы DMVPN; второй вариант – hub принимает непосредственное участие в передаче пакета внутри VRF, выполняя перенаправление пакета, как в третьей фазе DMVPN); однако в определённых случаях может возникнуть необходимость разместить PE за spoke.

Как обычно, соберём лабу и итеративно построим рабочее решение. Ниже приведена используемая топология в рамках рассмотрения 2547oDMVPN:

Роли маршрутизаторов:

• R1, R5, R7 (and R6 later) – MPLS PE;
• R3 – провайдер для DMVPN;
• R2 – DMVPN hub;
• R4, R6 – DMVPN spokes.

Протоколы маршрутизации:

• R1-R2, R4-R5, R6-R7 – OSPF на площадке организации;
• R3 – OSPF провайдера, обеспечивающий связность между маршрутизаторами DMVPN;
• R1, R5, R7 (R6) – MP-BGP VPNv4 AF;
• R2, R4, R6 – MP-BGP IPv4 AF;

Loopback0 отвечает за идентификацию маршрутизатора в сети, например, за назначение OSPF RID. Loopback1 является интерфейсом, с которого маршрутизаторы устанавливают BGP LU сессии; причины такой настройки рассмотрены далее в статье. Loopback2 эмулирует клиентские сети внутри VRF.

Начнём с базовой конфигурации PE:

R1(config)#vrf definition A
R1(config-vrf)#rd 1:1
R1(config-vrf)#address-family ipv4
R1(config-vrf-af)#route-target export 1:1
R1(config-vrf-af)#route-target import 1:1
R1(config-if)#interface Loopback0
R1(config-if)#ip address 1.1.1.1 255.255.255.255
R1(config)#interface Loopback2
R1(config-if)#vrf forwarding A
R1(config-if)#ip address 1.1.1.1 255.255.255.255
R1(config)#interface FastEthernet0/0
R1(config-if)#ip address 192.168.12.1 255.255.255.0
R1(config-if)#mpls ldp router-id Loopback0
R1(config)#router ospf 1
R1(config-router)#mpls ldp autoconfig
R1(config-router)#router-id 1.1.1.1
R1(config-router)#network 0.0.0.0 255.255.255.255 area 0
R1(config)#router bgp 1
R1(config-router)#template peer-policy L3VPN
R1(config-router-ptmp)#send-community both
R1(config-router-ptmp)#exit-peer-policy
R1(config-router)#template peer-session SESSION
R1(config-router-stmp)#remote-as 1
R1(config-router-stmp)#update-source Loopback0
R1(config-router-stmp)#exit-peer-session
R1(config-router)#bgp router-id 1.1.1.1
R1(config-router)#no bgp default ipv4-unicast
R1(config-router)#neighbor 5.5.5.5 inherit peer-session SESSION
R1(config-router)#neighbor 7.7.7.7 inherit peer-session SESSION
R1(config-router)#address-family vpnv4
R1(config-router-af)#neighbor 5.5.5.5 activate
R1(config-router-af)#neighbor 5.5.5.5 send-community extended
R1(config-router-af)#neighbor 5.5.5.5 inherit peer-policy L3VPN
R1(config-router-af)#neighbor 7.7.7.7 activate
R1(config-router-af)#neighbor 7.7.7.7 send-community extended
R1(config-router-af)#neighbor 7.7.7.7 inherit peer-policy L3VPN
R1(config-router-af)#exit-address-family
R1(config-router)#address-family ipv4 vrf A
R1(config-router-af)#redistribute connected
R1(config-router-af)#exit-address-family

R5(config)#vrf definition A
R5(config-vrf)# rd 1:1
R5(config-vrf)# address-family ipv4
R5(config-vrf-af)# route-target export 1:1
R5(config-vrf-af)# route-target import 1:1
R5(config-vrf-af)# exit-address-family 
R5(config-vrf)#interface Loopback0
R5(config-if)# ip address 5.5.5.5 255.255.255.255
R5(config-if)#interface Loopback2
R5(config-if)# vrf forwarding A
R5(config-if)# ip address 5.5.5.5 255.255.255.255
R5(config-if)#interface FastEthernet0/0
R5(config-if)# ip address 192.168.45.5 255.255.255.0
R5(config-if)#mpls ldp router-id Loopback0
R5(config)#router ospf 1
R5(config-router)# mpls ldp autoconfig
R5(config-router)# router-id 5.5.5.5
R5(config-router)# network 0.0.0.0 255.255.255.255 area 0
R5(config-router)#router bgp 1
R5(config-router)# template peer-policy L3VPN
R5(config-router-ptmp)# send-community both
R5(config-router-ptmp)# exit-peer-policy
R5(config-router)# template peer-session SESSION
R5(config-router-stmp)# remote-as 1
R5(config-router-stmp)# update-source Loopback0
R5(config-router-stmp)# exit-peer-session
R5(config-router)# bgp router-id 5.5.5.5
R5(config-router)# no bgp default ipv4-unicast
R5(config-router)# neighbor 1.1.1.1 inherit peer-session SESSION
R5(config-router)# neighbor 7.7.7.7 inherit peer-session SESSION
R5(config-router)# address-family vpnv4
R5(config-router-af)# neighbor 1.1.1.1 activate
R5(config-router-af)# neighbor 1.1.1.1 send-community extended
R5(config-router-af)# neighbor 1.1.1.1 inherit peer-policy L3VPN
R5(config-router-af)# neighbor 7.7.7.7 activate
R5(config-router-af)# neighbor 7.7.7.7 send-community extended
R5(config-router-af)# neighbor 7.7.7.7 inherit peer-policy L3VPN
R5(config-router-af)# exit-address-family
R5(config-router)# address-family ipv4 vrf A
R5(config-router-af)# redistribute connected
R5(config-router-af)# exit-address-family

R7(config)#vrf definition A
R7(config-vrf)# rd 1:1
R7(config-vrf)# address-family ipv4
R7(config-vrf-af)# route-target export 1:1
R7(config-vrf-af)# route-target import 1:1
R7(config-vrf-af)# exit-address-family
R7(config-vrf)#interface Loopback0
R7(config-if)# ip address 7.7.7.7 255.255.255.255
R7(config-if)#interface Loopback2
R7(config-if)# vrf forwarding A
R7(config-if)# ip address 7.7.7.7 255.255.255.255
R7(config-if)#interface FastEthernet0/0
R7(config-if)# ip address 192.168.67.7 255.255.255.0
R7(config-if)#mpls ldp router-id Loopback0
R7(config)#router ospf 1
R7(config-router)# mpls ldp autoconfig
R7(config-router)# router-id 7.7.7.7
R7(config-router)# network 0.0.0.0 255.255.255.255 area 0
R7(config-router)#router bgp 1
R7(config-router)# template peer-policy L3VPN
R7(config-router-ptmp)# send-community both
R7(config-router-ptmp)# exit-peer-policy
R7(config-router)# template peer-session SESSION
R7(config-router-stmp)# remote-as 1
R7(config-router-stmp)# update-source Loopback0
R7(config-router-stmp)# exit-peer-session
R7(config-router)# bgp router-id 7.7.7.7
R7(config-router)# bgp log-neighbor-changes
R7(config-router)# no bgp default ipv4-unicast
R7(config-router)# neighbor 1.1.1.1 inherit peer-session SESSION
R7(config-router)# neighbor 5.5.5.5 inherit peer-session SESSION
R7(config-router)# address-family ipv4
R7(config-router-af)# exit-address-family
R7(config-router)# address-family vpnv4
R7(config-router-af)# neighbor 1.1.1.1 activate
R7(config-router-af)# neighbor 1.1.1.1 send-community extended
R7(config-router-af)# neighbor 1.1.1.1 inherit peer-policy L3VPN
R7(config-router-af)# neighbor 5.5.5.5 activate
R7(config-router-af)# neighbor 5.5.5.5 send-community extended
R7(config-router-af)# neighbor 5.5.5.5 inherit peer-policy L3VPN
R7(config-router-af)# exit-address-family
R7(config-router)# address-family ipv4 vrf A
R7(config-router-af)# redistribute connected R7(config-router-af)# exit-address-family

Следующий шаг – подключить DMVPN маршрутизаторы к локальным сегментам сети:

R2(config)#interface Loopback0
R2(config-if)# ip address 2.2.2.2 255.255.255.255
R2(config-if)#interface FastEthernet0/0
R2(config-if)# ip address 192.168.12.2 255.255.255.0
R2(config-if)#mpls ldp router-id Loopback0
R2(config)#router ospf 1
R2(config-router)# mpls ldp autoconfig
R2(config-router)# router-id 2.2.2.2
R2(config-router)# redistribute bgp 1 subnets
R2(config-router)# passive-interface default
R2(config-router)# no passive-interface FastEthernet0/0
R2(config-router)# no passive-interface Loopback0
R2(config-router)# network 0.0.0.0 255.255.255.255 area 0

R4(config)#interface Loopback0
R4(config-if)# ip address 4.4.4.4 255.255.255.255
R4(config-if)#interface FastEthernet0/0
R4(config-if)# ip address 192.168.45.4 255.255.255.0
R4(config-if)#mpls ldp router-id Loopback0
R4(config)#router ospf 1
R4(config-router)# mpls ldp autoconfig
R4(config-router)# router-id 4.4.4.4
R4(config-router)# redistribute bgp 1 subnets
R4(config-router)# passive-interface default
R4(config-router)# no passive-interface FastEthernet0/0
R4(config-router)# no passive-interface Loopback0
R4(config-router)# network 0.0.0.0 255.255.255.255 area 0

R6(config)#interface Loopback0
R6(config-if)# ip address 6.6.6.6 255.255.255.255
R6(config-if)#interface FastEthernet0/0
R6(config-if)# ip address 192.168.67.6 255.255.255.0
R6(config-if)#mpls ldp router-id Loopback0
R6(config)#router ospf 1
R6(config-router)# mpls ldp autoconfig
R6(config-router)# redistribute bgp 1 subnets
R6(config-router)# passive-interface default
R6(config-router)# no passive-interface FastEthernet0/0
R6(config-router)# no passive-interface Loopback0
R6(config-router)# network 0.0.0.0 255.255.255.255 area 0

Наконец последний этап подготовки к рассмотрению BGP LU – настройка DMVPN. В статье использован подход front-door VRF, чтобы уменьшить объём посторонней информации в глобальной таблице маршрутизации:

R3(config)#interface Loopback0
R3(config-if)# ip address 3.3.3.3 255.255.255.255
R3(config-if)#interface FastEthernet0/1
R3(config-if)# ip address 192.168.34.3 255.255.255.0
R3(config-if)#interface FastEthernet1/0
R3(config-if)# ip address 192.168.23.3 255.255.255.0
R3(config-if)#interface FastEthernet1/1
R3(config-if)# ip address 192.168.36.3 255.255.255.0
R3(config-if)#router ospf 1
R3(config-router)# router-id 3.3.3.3
R3(config-router)# network 0.0.0.0 255.255.255.255 area 0

R2(config)#vrf definition FVRF
R2(config-vrf)# rd 1:1
R2(config-vrf)# address-family ipv4
R2(config-vrf-af)# exit-address-family
R2(config-vrf)#interface Tunnel0
R2(config-if)# ip address 192.168.0.2 255.255.255.0
R2(config-if)# no ip redirects
R2(config-if)# ip nhrp map multicast dynamic
R2(config-if)# ip nhrp network-id 1
R2(config-if)# ip nhrp redirect
R2(config-if)# tunnel source FastEthernet1/0
R2(config-if)# tunnel mode gre multipoint
R2(config-if)# tunnel vrf FVRF
R2(config-if)#interface FastEthernet1/0
R2(config-if)# vrf forwarding FVRF
R2(config-if)# ip address 192.168.23.2 255.255.255.0
R2(config-if)#router ospf 2 vrf FVRF
R2(config-router)# router-id 192.168.23.2
R2(config-router)# network 0.0.0.0 255.255.255.255 area 0

R4(config)#vrf definition FVRF
R4(config-vrf)# rd 1:1
R4(config-vrf)# address-family ipv4
R4(config-vrf-af)# exit-address-family
R4(config-vrf)#interface Tunnel0
R4(config-if)# ip address 192.168.0.4 255.255.255.0
R4(config-if)# no ip redirects
R4(config-if)# ip nhrp network-id 1
R4(config-if)# ip nhrp nhs 192.168.0.2 nbma 192.168.23.2 multicast
R4(config-if)# ip nhrp shortcut
R4(config-if)# tunnel source FastEthernet0/1
R4(config-if)# tunnel mode gre multipoint
R4(config-if)# tunnel vrf FVRF
R4(config-if)#interface FastEthernet0/1
R4(config-if)# vrf forwarding FVRF
R4(config-if)# ip address 192.168.34.4 255.255.255.0
R4(config-if)#router ospf 2 vrf FVRF
R4(config-router)# router-id 192.168.34.4
R4(config-router)# network 0.0.0.0 255.255.255.255 area 0

R6(config)#vrf definition FVRF
R6(config-vrf)# rd 1:1
R6(config-vrf)# address-family ipv4
R6(config-vrf-af)# exit-address-family
R6(config-vrf)#interface Tunnel0
R6(config-if)# ip address 192.168.0.6 255.255.255.0
R6(config-if)# no ip redirects
R6(config-if)# ip nhrp network-id 1
R6(config-if)# ip nhrp nhs 192.168.0.2 nbma 192.168.23.2 multicast
R6(config-if)# ip nhrp shortcut
R6(config-if)# tunnel source FastEthernet1/1
R6(config-if)# tunnel mode gre multipoint
R6(config-if)# tunnel vrf FVRF
R6(config-if)#interface FastEthernet1/1
R6(config-if)# vrf forwarding FVRF
R6(config-if)# ip address 192.168.36.6 255.255.255.0
R6(config-if)#router ospf 2 vrf FVRF
R6(config-router)# network 0.0.0.0 255.255.255.255 area 0

Время заняться делом. Необходимым условием для L3VPN является наличие рабочего LSP между PE. Поскольку ни LDP, ни RSVP в рамках DMVPN для этой задачи не подходят, используем MP-BGP для передачи следующей информации:

• адреса loopback;
• соответствующие им MPLS метки.

Звучит довольно просто. Что насчёт поддержки MPLS на интерфейсах?

R2#sho mpls interfaces 
Interface IP Tunnel BGP Static Operational
FastEthernet0/0 Yes (ldp) No No No Yes 

На Tunnel0 MPLS пока не работает. Нам нужно разрешить только поддержку MPLS пакетов, не включая LDP, поэтому команда “mpls ip” не подходит. Впрочем, существует ещё одна менее известная команда, отвечающая нашей задаче:

R2(config)#interface Tunnel0
R2(config-if)#mpls bgp forwarding
R2#sho mpls interfaces 
Interface IP Tunnel BGP Static Operational
FastEthernet0/0 Yes (ldp) No No No Yes 
Tunnel0 No No Yes No Yes 

После выполнения этой команды на всех spoke можно приступать к настройке BGP. В этой статье мы используем iBGP между hub и spoke; hub выполняет роль route-reflector и принимает входящие BGP-соединения:

R2(config)#router bgp 1
R2(config-router)# bgp router-id 2.2.2.2
R2(config-router)# bgp listen range 192.168.0.0/24 peer-group DMVPN
R2(config-router)# no bgp default ipv4-unicast
R2(config-router)# neighbor DMVPN peer-group
R2(config-router)# neighbor DMVPN remote-as 1
R2(config-router)# neighbor DMVPN update-source Tunnel0
R2(config-router)# address-family ipv4
R2(config-router-af)# network 1.1.1.1 mask 255.255.255.255
R2(config-router-af)# neighbor DMVPN activate
R2(config-router-af)# neighbor DMVPN route-reflector-client
R2(config-router-af)# neighbor DMVPN send-label

R4(config)#router bgp 1
R4(config-router)# bgp router-id 4.4.4.4
R4(config-router)# no bgp default ipv4-unicast
R4(config-router)# neighbor 192.168.0.2 remote-as 1
R4(config-router)# neighbor 192.168.0.2 update-source Tunnel0
R4(config-router)# address-family ipv4
R4(config-router-af)# network 5.5.5.5 mask 255.255.255.255
R4(config-router-af)# neighbor 192.168.0.2 activate
R4(config-router-af)# neighbor 192.168.0.2 send-label

R6(config)#router bgp 1
R6(config-router)# bgp router-id 6.6.6.6
R6(config-router)# no bgp default ipv4-unicast
R6(config-router)# neighbor 192.168.0.2 remote-as 1
R6(config-router)# neighbor 192.168.0.2 update-source Tunnel0
R6(config-router)# address-family ipv4
R6(config-router-af)# network 7.7.7.7 mask 255.255.255.255
R6(config-router-af)# neighbor 192.168.0.2 activate
R6(config-router-af)# neighbor 192.168.0.2 send-label

Проверим, есть ли IP-связность между PE:

R5#ping 1.1.1.1 so lo 0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds:
Packet sent with a source address of 5.5.5.5 !!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 48/57/64 ms

Достаточно ли этого для связности внутри VRF?

R5#ping vrf A 1.1.1.1 so lo 0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds:
Packet sent with a source address of 5.5.5.5 
.....
Success rate is 0 percent (0/5)

К сожалению, решение несколько сложнее, чем могло бы показаться на первый взгляд. Причина отсутствия связности – нерабочий LSP между PE:

R5#ping mpls ipv4 1.1.1.1/32 source 5.5.5.5
Sending 5, 100-byte MPLS Echos to 1.1.1.1/32, timeout is 2 seconds, send interval is 0 msec:
Codes: '!' - success, 'Q' - request not sent, '.' - timeout,
 'L' - labeled output interface, 'B' - unlabeled output interface, 
 'D' - DS Map mismatch, 'F' - no FEC mapping, 'f' - FEC mismatch,
 'M' - malformed request, 'm' - unsupported tlvs, 'N' - no label entry, 
 'P' - no rx intf label prot, 'p' - premature termination of LSP, 
 'R' - transit router, 'I' - unknown upstream index, 'X' - unknown return code, 'x' - return code 0
Type escape sequence to abort.
BBBBB Success rate is 0 percent (0/5)

Если быть точным, место отказа – R4:

R4#sho mpls forwarding-table 1.1.1.1 32
Local Outgoing Prefix Bytes Label Outgoing Next Hop 
Label Label or Tunnel Id Switched interface 
19 No Label 1.1.1.1/32 1125 Tu0 192.168.0.2

Впрочем, является ли R4 местом возникновения проблемы? Разве R2 не должен был послать R4 префикс вместе с меткой?

R4#sho ip bgp labels 
 Network Next Hop In label/Out label
 1.1.1.1/32 192.168.12.1 nolabel/nolabel
 2.2.2.2/32 192.168.0.2 nolabel/imp-null 

Важное наблюдение: 1.1.1.1/32 не имеет сопутствующей MPLS метки, однако 2.2.2.2/32 ведёт себя так, как и было задумано. Также стоит обратить внимание на next-hop для 1.1.1.1/32 – это адрес R1, а не R2. R2 импортировал маршрут в BGP, сохранив оригинальный next-hop из таблицы маршрутизации. Поскольку сессия между R2 и R4 – iBGP, значение next-hop для 1.1.1.1/32 не меняется. Для 2.2.2.2/32 значение next-hop – адрес R2. Это тонкое отличие, однако, является ключевым: BGP назначает префиксу MPLS метку только в том случае, когда BGP маршрутизатор является next-hop’ом для этого префикса, т.е. входит в LSP.

В нашем случае нужно назначать метку только префиксам, импортированным локально, и не менять информацию от spoke:

R2(config)#router bgp 1
R2(config-router)#address-family ipv4
R2(config-router-af)#neighbor PEER next-hop-self ? all Enable next-hop-self for both eBGP and iBGP received paths 
R2(config-router-af)#neighbor PEER next-hop-self

Эта команда – довольно хитрая. По умолчанию она заставляет R2 изменять next-hop для маршрутов, которые импортированы локально или получены через eBGP; если нужно изменить next-hop для всех префиксов, включая те, которые получены по iBGP, нужно добавить ключевое слово “all”. Появилась ли связность?

R5#ping mpls ipv4 1.1.1.1/32 source 5.5.5.5

<output omitted>

Type escape sequence to abort.
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 56/65/72 ms
R5#
R5#ping vrf A 1.1.1.1 so lo 0 Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds:
Packet sent with a source address of 5.5.5.5 
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 52/80/108 ms
R5#
R5#ping mpls ipv4 7.7.7.7/32 source 5.5.5.5

<output omitted>

Type escape sequence to abort.
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 56/60/64 ms
R5#
R5#ping vrf A 7.7.7.7 so lo 2 Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 7.7.7.7, timeout is 2 seconds:
Packet sent with a source address of 5.5.5.5 
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 48/79/104 ms
R5#
R5#traceroute 7.7.7.7 so lo 0 Type escape sequence to abort.
Tracing the route to 7.7.7.7
VRF info: (vrf in name/id, vrf out name/id)
1 192.168.45.4 [MPLS: Label 22 Exp 0] 88 msec 80 msec 80 msec
2 192.168.0.6 [MPLS: Label 16 Exp 0] 52 msec 64 msec 52 msec
3 192.168.67.7 40 msec 64 msec 64 msec

Мы добились работы L3VPN поверх DMVPN. Впрочем, внимательный читатель, который повторял описанные шаги в собственной лабе, мог заметить следующее предупреждение, возникающее при настройке BGP LU:

R4(config-router-af)#neighbor 192.168.0.2 send-label %BGP:
For distributing MPLS labels to IBGP peers, the update source should be set to a loopback interface

Несмотря на то, что сообщение намекает на потенциальные проблемы, в нашей топологии они остались незамеченными. Рассмотрим следующую схему:

В рамках этого примера R1 устанавливает BGP сессию со своего интерфейса f0/0 до loopback интерфейса на R3, повторяя схему DMVPN. Control plane в данном случае будет работать без ошибок, тогда как связность на data plane – LSP – будет нарушена. Причина – PHP, penultimate hop popping. Интерфейс f0/0 лежит в directly connected сети для R2, который анонсирует её с меткой implicit-null. Рассмотрим, что происходит с пакетом, который R3 отправит на R1:

• R3 добавляет VPN метку (например, 16) к пакету;
• R3 добавляет транспортную метку (implicit-null) к полученному MPLS кадру;
• R3 отправляет полученный кадр в сторону R2, при этом VPN метка находится на вершине стека.
  

Далее возможны два исхода: R2 не знает, что делать с кадром (VPN метка отсутствует в LFIB), и отбрасывает его, или же R2 шлёт кадр в неверном направлении (случайное совпадение VPN метки в кадре и транспортной метки в LFIB). В любом случае шансы R1 на получение кадра ничтожно малы. Стоит отметить, что использование explicit-null не решит проблему, поскольку для передачи кадра всё так же будет использована нижележащая VPN метка.

Впрочем, какое это имеет отношение к нашей изначальной топологии? Описанная проблема относится к некорректно настроенным PE-маршрутизаторам. Однако эта проблема становится актуальной и в нашей топологии, если spoke превратить в PE, поскольку BGP использует Tunnel0 для установления сессии. Можно попробовать перенастроить BGP на использование loopback, хотя это ни к чему хорошему не приведёт: LSP будет разорван, т.к. некому анонсировать метки для самих loopback – обычно это задача LSP/RSVP. Впрочем, решение довольно простое: можно использовать loopback только для VPNv4 AF сессий и анонсировать соответствующие метки с помощью BGP LU:

R6(config)#vrf definition A
R6(config-vrf)# rd 2:2
R6(config-vrf)# address-family ipv4
R6(config-vrf-af)# route-target export 1:1
R6(config-vrf-af)# route-target import 1:1
R6(config-vrf-af)# exit-address-family
R6(config-vrf)#interface Loopback1
R6(config-if)# ip address 100.0.0.6 255.255.255.255
R6(config-if)#interface Loopback2
R6(config-if)# vrf forwarding A
R6(config-if)# ip address 6.6.6.6 255.255.255.255
R6(config-if)#router bgp 1
R6(config-router)# template peer-policy L3VPN
R6(config-router-ptmp)# send-community both
R6(config-router-ptmp)# exit-peer-policy
R6(config-router)# template peer-session SESSION
R6(config-router-stmp)# remote-as 1
R6(config-router-stmp)# update-source Loopback1
R6(config-router-stmp)# exit-peer-session
R6(config-router)# neighbor 1.1.1.1 inherit peer-session SESSION
R6(config-router)# neighbor 5.5.5.5 inherit peer-session SESSION
R6(config-router)# neighbor 7.7.7.7 inherit peer-session SESSION
R6(config-router)# address-family ipv4
R6(config-router-af)# network 100.0.0.6 mask 255.255.255.255
R6(config-router-af)# exit-address-family
R6(config-router)# address-family vpnv4
R6(config-router-af)# neighbor 1.1.1.1 activate
R6(config-router-af)# neighbor 1.1.1.1 send-community extended
R6(config-router-af)# neighbor 1.1.1.1 inherit peer-policy L3VPN
R6(config-router-af)# neighbor 5.5.5.5 activate
R6(config-router-af)# neighbor 5.5.5.5 send-community extended
R6(config-router-af)# neighbor 5.5.5.5 inherit peer-policy L3VPN
R6(config-router-af)# neighbor 7.7.7.7 activate
R6(config-router-af)# neighbor 7.7.7.7 send-community extended
R6(config-router-af)# neighbor 7.7.7.7 inherit peer-policy L3VPN
R6(config-router-af)# exit-address-family
R6(config-router)# address-family ipv4 vrf A
R6(config-router-af)# redistribute connected R6(config-router-af)# exit-address-family

Теперь R6 участвует в L3VPN, и можно проверить наличие связности внутри VRF:

R6#tclsh 
R6(tcl)#foreach x {1.1.1.1 5.5.5.5 7.7.7.7} {ping vrf A $x so lo 2} Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds:
Packet sent with a source address of 6.6.6.6 !!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 28/59/84 ms Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 5.5.5.5, timeout is 2 seconds:
Packet sent with a source address of 6.6.6.6 !!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/32/44 ms Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 7.7.7.7, timeout is 2 seconds:
Packet sent with a source address of 6.6.6.6 
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/9/16 ms

Наконец-то L3VPN поверх DMVPN работает так, как мы ожидали. Мне кажется, сложности описанной конструкции заключаются в следующем:

1. обладание тайным знанием о существовании BGP LU;
2. назначение MPLS метки только в том случае, если маршрутизатор является next-hop’ом для префикса;
3. понимание, в каких случаях PHP способен сломать LSP.
   

В этой статье мы обсудили настройку MPLS L3VPN поверх DMVPN (2547oDMVPN) с использованием iBGP LU для распространения MPLS меток в рамках опорной сети. Отличие от документированных способов – это возможность разместить PE-маршрутизатор за hub/spokes без нарушения spoke-to-spoke связности поверх DMVPN. Что касается настройки с помощью eBGP, я бы хотел оставить её как домашнее задание для любознательных читателей.

Подробности

Автор: Super User

Категория: Articles

Опубликовано: 12 ноября 2020

Создано: 12 ноября 2020

Обновлено: 15 апреля 2021

Просмотров: 6843

Сигнализация PIM

Введение

Топология

Underlay

Unicast overlay

Multicast overlay

Data plane

Заключение

Введение

У крупных корпоративных клиентов периодически появляется желание передавать групповой трафик (multicast) не только внутри своих сетей в крупных офисах и дата-центрах, но также и между ними. Операторам связи приходится решать поставленные перед ними задачи по обеспечению доставки таких пакетов между точками присутствия клиентов.

Среди наиболее распространённых способов передачи группового трафика в MPLS-сетях можно отметить несколько: Rosen и mLDP, RSVP и head-end replication, например, в EVPN; в данной статье мы сосредоточимся на одном из них – Rosen (по фамилии одного из авторов RFC).

При передаче multicast-трафика в Rosen режиме между двумя PE маршрутизаторами (Provider Edge) устанавливается специальный GRE-туннель, по которому и передаются групповые пакеты. Стоит отметить, что underlay сеть может быть как с настоящей поддержкой multicast, так и с его эмуляцией (например, в сетях DMVPN, то есть при использовании 2547oDMVPN).

Сигнализация при этом может быть на основе различных протоколов: PIM, mLDP, BGP. Разберёмся, что происходит в сети, когда для сигнализации используется протокол PIM SM (Profile 0 Default MDT - GRE - PIM C-mcast Signaling).

Топология

Чтобы упростить себе задачу, рассмотрим underlay сеть безо всяких дополнительных туннельных протоколов, например, DMVPN.

В MPLS-сеть провайдера входят следующие устройства: PE1, P1, P2 и PE2. Назначение маршрутизатора понятно из его названия. В качестве платформы для эмуляции операторского оборудования был выбран виртуальный маршрутизатор Cisco CSR1000v, на который установлена последняя версия программного обеспечения (IOS-XE линейки 17.3). Клиентское оборудование представлено маршрутизаторами Cisco серии 7200 (IOS версии 15.2). Единственное, что стоит упомянуть отдельно – устройства Sender и Receiver. В данной статье в качестве отправителя и получателя группового трафика мы использовали маршрутизаторы, естественно, что в реальной сети для этих целей будут применяться настоящие рабочие станции, серверы, медиа-плееры.

Underlay

Под underlay сетью в данном случае мы будем понимать инфраструктуру провайдера. В сети оператора мы использовали следующие протоколы: OSPF и LDP.

PE1#sho run | s r o
router ospf 1
 network 0.0.0.0 255.255.255.255 area 0
 mpls ldp autoconfig
PE1#sho mpls ldp neighbor
 Peer LDP Ident: 1.1.1.1:0; Local LDP Ident 3.3.3.3:0
 TCP connection: 1.1.1.1.646 - 3.3.3.3.35398
 State: Oper; Msgs sent/rcvd: 70/72; Downstream
 Up time: 00:53:14
 LDP discovery sources:
 GigabitEthernet2, Src IP addr: 172.16.0.2
 Addresses bound to peer LDP Ident:
 172.16.1.1 172.16.0.2 1.1.1.1
PE1#sho mpl fo
Local Outgoing Prefix Bytes Label Outgoing Next Hop
Label Label or Tunnel Id Switched interface
16 Pop Label 1.1.1.1/32 0 Gi2 172.16.0.2
17 16 2.2.2.2/32 0 Gi2 172.16.0.2
18 Pop Label 172.16.1.0/24 0 Gi2 172.16.0.2
19 17 172.16.2.0/24 0 Gi2 172.16.0.2
20 19 4.4.4.4/32 0 Gi2 172.16.0.2

Также в underlay сети присутствует поддержка multicast-трафика. Для сигнализации используется PIM sparse-mode. На ряде линеек устройств компании Cisco маршрутизация multicast-трафика по умолчанию отключена, поэтому кроме включения протокола PIM на всех нужных интерфейсах необходимо также включить маршрутизацию multicast-пакетов. В качестве Rendezvous Point (RP) был выбран маршрутизатор PE1, информация о котором по сети распространяется с помощью стандартного протокола автоматического выбора RP - BootStrap Router (BSR).

PE1(config)#ip multicast-routing distributed
PE1(config)#^Z
PE1#sho ip pim interface
Address Interface Ver/ Nbr Query DR DR
 Mode Count Intvl Prior
3.3.3.3 Loopback0 v2/S 0 30 1 3.3.3.3
172.16.0.1 GigabitEthernet2 v2/S 1 30 1 172.16.0.2
PE1#sho run | i candi
ip pim bsr-candidate Loopback0 0
ip pim rp-candidate Loopback0

Убедимся, что на маршрутизаторе PE2 присутствует вся необходимая информация для работы с multicast в сети провайдера: обнаружены PIM-соседи, получена информация об адресе RP.

PE2#sho ip pim nei
PIM Neighbor Table
Mode: B - Bidir Capable, DR - Designated Router, N - Default DR Priority,
 P - Proxy Capable, S - State Refresh Capable, G - GenID Capable,
 L - DR Load-balancing Capable
Neighbor Interface Uptime/Expires Ver DR
Address Prio/Mode
172.16.2.1 GigabitEthernet2 00:06:04/00:01:36 v2 1 / S P G
PE2#sho ip pim rp map
PIM Group-to-RP Mappings
Group(s) 224.0.0.0/4
 RP 3.3.3.3 (?), v2
 Info source: 3.3.3.3 (?), via bootstrap, priority 0, holdtime 150
 Uptime: 00:45:18, expires: 00:01:36

Мы решили снять дамп на линке P1-P2 и найти в нём сообщение, с помощью которого маршрутизатор PE1 анонсирует себя в качестве кандидата на роли BSR и RP.

Unicast overlay

Для обработки пользовательского трафика был создан VRF A. За передачу маршрутной информации между PE1 и PE2 отвечает протокол MP-BGP. Обмен маршрутами с пользовательскими маршрутизаторами CE1 и CE2 производится с помощью протокола OSPF.

PE1#sho run | s r b
router bgp 1
 bgp log-neighbor-changes
 no bgp default ipv4-unicast
 neighbor 4.4.4.4 remote-as 1
 neighbor 4.4.4.4 update-source Loopback0
 !
 address-family ipv4
 exit-address-family
 !
 address-family vpnv4
 neighbor 4.4.4.4 activate
 neighbor 4.4.4.4 send-community extended
 exit-address-family
 !
 address-family ipv4 vrf A
 redistribute ospf 2 match internal external 2
 exit-address-family
PE1#sho run | s r ospf 2
router ospf 2 vrf A
 capability vrf-lite
 redistribute bgp 1
 network 0.0.0.0 255.255.255.255 area 0

Распространение сервисных MPLS-меток производится с помощью протокола MP-BGP (address-family vpnv4).

PE1#sho bgp vpnv4 unicast vrf A labels
 Network Next Hop In label/Out label
Route Distinguisher: 1:1 (A)
 5.5.5.5/32 192.168.0.2 22/nolabel
 6.6.6.6/32 4.4.4.4 nolabel/22
 10.0.0.0/24 192.168.0.2 23/nolabel
 10.0.1.0/24 4.4.4.4 nolabel/23
 192.168.0.0 0.0.0.0 21/nolabel(A)
 192.168.1.0 4.4.4.4 nolabel/21

Несложно убедиться в том, что пользовательские маршрутизаторы обладают всеми необходимыми префиксами.

CE1#sho ip ro
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
 D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
 N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
 E1 - OSPF external type 1, E2 - OSPF external type 2
 i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
 ia - IS-IS inter area, * - candidate default, U - per-user static route
 o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
 + - replicated route, % - next hop override
Gateway of last resort is not set
 5.0.0.0/32 is subnetted, 1 subnets
C 5.5.5.5 is directly connected, Loopback0
 6.0.0.0/32 is subnetted, 1 subnets
O E2 6.6.6.6 [110/1] via 192.168.0.1, 00:43:33, GigabitEthernet0/0
 10.0.0.0/8 is variably subnetted, 3 subnets, 2 masks
C 10.0.0.0/24 is directly connected, GigabitEthernet1/0
L 10.0.0.1/32 is directly connected, GigabitEthernet1/0
O E2 10.0.1.0/24 [110/1] via 192.168.0.1, 00:43:33, GigabitEthernet0/0
 192.168.0.0/24 is variably subnetted, 2 subnets, 2 masks
C 192.168.0.0/24 is directly connected, GigabitEthernet0/0
L 192.168.0.2/32 is directly connected, GigabitEthernet0/0
O E2 192.168.1.0/24 [110/1] via 192.168.0.1, 00:43:33, GigabitEthernet0/0

Так как устройства Sender и Receiver имитируют хосты, то никакой динамической маршрутизации на них не используется.

Receiver#sho ip ro
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
 D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
 N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
 E1 - OSPF external type 1, E2 - OSPF external type 2
 i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
 ia - IS-IS inter area, * - candidate default, U - per-user static route
 o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
 + - replicated route, % - next hop override
Gateway of last resort is 10.0.1.1 to network 0.0.0.0
S* 0.0.0.0/0 [1/0] via 10.0.1.1
 10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C 10.0.1.0/24 is directly connected, GigabitEthernet1/0
L 10.0.1.2/32 is directly connected, GigabitEthernet1/0

Узлы Sender и Receiver успешно обмениваются данными.

Receiver#ping 10.0.0.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.0.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 20/32/44 ms

Мы перехватили одно из указанных ICMP-сообщений на линке P1-P2.

Обратите внимание на наличие обеих MPLS-меток у пакета: сервисной и транспортной.

Multicast overlay

Функции Rendezvous Point для VRF A мы решили возложить на клиентское оборудование, то есть маршрутизатор CE1 будет объявлять себя как C-RP и C-BSR.

CE1#sho run | i candi
ip pim bsr-candidate Loopback0 0
ip pim rp-candidate Loopback0
CE1#sho ip pim rp map
PIM Group-to-RP Mappings
This system is a candidate RP (v2)
This system is the Bootstrap Router (v2)
Group(s) 224.0.0.0/4
 RP 5.5.5.5 (?), v2
 Info source: 5.5.5.5 (?), via bootstrap, priority 0, holdtime 150
 Uptime: 00:55:21, expires: 00:02:06

В сети провайдера нужно обязательно включить поддержку multicast-маршрутизации не только глобально, но ещё и для VRF A.

PE1(config)#ip multicast-routing vrf A distributed

Но и это ещё не всё. Каждый vrf должен быть настроен на использование уникальных multicast-групп для передачи пользовательского трафика с помощью команд mdt default и mdt data. Последняя команда опциональна.

PE1#sho run vrf | s def
vrf definition a
 rd 1:1
 route-target export 1:1
 route-target import 1:1
 !
 address-family ipv4
 mdt default 239.1.1.1
 mdt data 239.1.2.0 0.0.0.255 threshold 1
 mdt data threshold 1
 exit-address-family

По умолчанию весь трафик передаётся с помощью группы, указанной в команде mdt default, однако если скорость передачи трафика превышает некоторый предел, заданный с помощью опции threshold, то данный поток пользовательского трафика переводится в одну из data-групп.

После того, как мы осуществили привязку default-группы к VRF, все PE-маршрутизаторы автоматически подписываются на эту группу и пытаются обнаружить PIM-соседей в overlay-сети.

Это очень интересный и показательный пакет, который мы перехватили в сети провайдера. Он отправляется маршрутизатором PE2 в сторону устройства, выполняющего функции RP в underlay-сети. Это unicast-пакет, поэтому к нему стандартным образом добавляется транспортная MPLS-метка. Внутри этого IPv4-пакета расположено сообщение Register протокола PIM. То есть маршрутизатор PE2 пытается переслать некоторый multicast-пакет в сторону RP пока ещё нет никакой подписки со стороны RP. Всё как и в случае обычной групповой рассылки. Но что это за IP-пакет, который PE2 хочет доставить до PE1? А это ни много ни мало рассылка для группы 239.1.1.1, которая у нас была объявлена как mdt default для VRF A. Производим декапсуляцию дальше: GRE заголовок и потом снова IPv4. Это уже попытка роутера PE2 внутри VRF A обнаружить PIM-соседей (судя по адресу получателя 224.0.0.13) при помощи сообщения PIM Hello.

В результате мы видим, что все PIM-маршрутизаторы внутри VRF A обнаружены, и соседство с ними установлено.

PE2#sho ip pim vrf a neighbor
PIM Neighbor Table
Mode: B - Bidir Capable, DR - Designated Router, N - Default DR Priority,
 P - Proxy Capable, S - State Refresh Capable, G - GenID Capable,
 L - DR Load-balancing Capable
Neighbor Interface Uptime/Expires Ver DR
Address Prio/Mode
3.3.3.3 Tunnel1 00:06:31/00:01:38 v2 1 / S P G
192.168.1.2 GigabitEthernet1 00:03:28/00:01:43 v2 1 / DR S P G

На какие же группы и каких отправителей теперь подписан маршрутизатор PE2? То есть маршрутизатор PE2 заинтересован в получении трафика группы 239.1.1.1, настроенной как mdt default.

PE2#sho ip mroute
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
 L - Local, P - Pruned, R - RP-bit set, F - Register flag,
 T - SPT-bit set, J - Join SPT, M - MSDP created entry, E - Extranet,
 X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,
 U - URD, I - Received Source Specific Host Report,
 Z - Multicast Tunnel, z - MDT-data group sender,
 Y - Joined MDT-data group, y - Sending to MDT-data group,
 G - Received BGP C-Mroute, g - Sent BGP C-Mroute,
 N - Received BGP Shared-Tree Prune, n - BGP C-Mroute suppressed,
 Q - Received BGP S-A Route, q - Sent BGP S-A Route,
 V - RD & Vector, v - Vector, p - PIM Joins on route,
 x - VxLAN group, c - PFP-SA cache created entry,
 * - determined by Assert, # - iif-starg configured on rpf intf,
 e - encap-helper tunnel flag
Outgoing interface flags: H - Hardware switched, A - Assert winner, p - PIM Join
 Timers: Uptime/Expires
 Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 239.1.1.1), 01:09:41/stopped, RP 3.3.3.3, flags: SJCFZ
 Incoming interface: GigabitEthernet2, RPF nbr 172.16.2.1
 Outgoing interface list:
 MVRF a, Forward/Sparse, 01:09:41/00:02:18
(3.3.3.3, 239.1.1.1), 01:09:41/00:01:13, flags: JTZ
 Incoming interface: GigabitEthernet2, RPF nbr 172.16.2.1
 Outgoing interface list:
 MVRF a, Forward/Sparse, 01:09:41/00:02:18
(4.4.4.4, 239.1.1.1), 01:09:41/00:03:13, flags: FT
 Incoming interface: Loopback0, RPF nbr 0.0.0.0
 Outgoing interface list:
 GigabitEthernet2, Forward/Sparse, 01:09:41/00:02:38
(*, 224.0.1.40), 01:26:41/00:02:22, RP 0.0.0.0, flags: DCL
 Incoming interface: Null, RPF nbr 0.0.0.0
 Outgoing interface list:
 Loopback0, Forward/Sparse, 01:26:39/00:02:22

На данный момент сеть готова к передаче пользовательского multicast-трафика.

С помощью протокола IGMP подпишемся на группу 239.7.7.7 с устройства Receiver.

Receiver#conf t
Enter configuration commands, one per line. End with CNTL/Z.
Receiver(config)#int gi1/0
Receiver(config-if)#ip igmp jo 239.7.7.7

На изображении ниже видно соответствующее сообщение протокола IGMP (Membership Report), которое отправлено с маршрутизатора Receiver. Конечные узлы ничего не знают о том, как реализована поддержка multicast в сети оператора, и используют стандартные IGMP сообщения Membership Report.

Убедимся в успешности подписки конечного узла на маршрутизаторе CE2.

CE2#sho ip igmp groups
IGMP Connected Group Membership
Group Address Interface Uptime Expires Last Reporter Group Accounted
239.7.7.7 GigabitEthernet1/0 00:03:49 00:02:37 10.0.1.2
224.0.1.40 GigabitEthernet0/0 01:43:29 00:02:55 192.168.1.1
224.0.1.40 Loopback0 01:43:36 00:02:27 6.6.6.6

Убедимся, что все пользовательские подписки были продублированы маршрутизатором CE2 в сторону оборудования провайдера по протоколу PIM.

PE2#sho ip mroute vrf a
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
 L - Local, P - Pruned, R - RP-bit set, F - Register flag,
 T - SPT-bit set, J - Join SPT, M - MSDP created entry, E - Extranet,
 X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,
 U - URD, I - Received Source Specific Host Report,
 Z - Multicast Tunnel, z - MDT-data group sender,
 Y - Joined MDT-data group, y - Sending to MDT-data group,
 G - Received BGP C-Mroute, g - Sent BGP C-Mroute,
 N - Received BGP Shared-Tree Prune, n - BGP C-Mroute suppressed,
 Q - Received BGP S-A Route, q - Sent BGP S-A Route,
 V - RD & Vector, v - Vector, p - PIM Joins on route,
 x - VxLAN group, c - PFP-SA cache created entry,
 * - determined by Assert, # - iif-starg configured on rpf intf,
 e - encap-helper tunnel flag
Outgoing interface flags: H - Hardware switched, A - Assert winner, p - PIM Join
 Timers: Uptime/Expires
 Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 239.7.7.7), 00:05:12/00:03:12, RP 5.5.5.5, flags: S
 Incoming interface: Tunnel1, RPF nbr 3.3.3.3
 Outgoing interface list:
 GigabitEthernet1, Forward/Sparse, 00:05:12/00:03:12
(*, 224.0.1.40), 01:45:32/00:02:31, RP 0.0.0.0, flags: DPL
 Incoming interface: Null, RPF nbr 0.0.0.0
 Outgoing interface list: Null

Несмотря на то, что канал CE2-PE2 – линк в сторону провайдера, никакие операторские технологии здесь не используются, только стандартный PIM.

Убедимся, что маршрутизатор CE1, выполняющий функции Rendezvous Point для клиентской сети, также получил информацию о группах, на которые выполнена подписка.

CE1#sho ip mroute
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
 L - Local, P - Pruned, R - RP-bit set, F - Register flag,
 T - SPT-bit set, J - Join SPT, M - MSDP created entry, E - Extranet,
 X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,
 U - URD, I - Received Source Specific Host Report,
 Z - Multicast Tunnel, z - MDT-data group sender,
 Y - Joined MDT-data group, y - Sending to MDT-data group,
 V - RD & Vector, v - Vector
Outgoing interface flags: H - Hardware switched, A - Assert winner
 Timers: Uptime/Expires
 Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 239.7.7.7), 00:10:46/00:02:32, RP 5.5.5.5, flags: S
 Incoming interface: Null, RPF nbr 0.0.0.0
 Outgoing interface list:
 GigabitEthernet0/0, Forward/Sparse, 00:02:21/00:02:32
(*, 224.0.1.40), 01:50:51/00:02:48, RP 0.0.0.0, flags: DCL
 Incoming interface: Null, RPF nbr 0.0.0.0
 Outgoing interface list:
 GigabitEthernet0/0, Forward/Sparse, 01:50:49/00:02:48

Вновь заглянем в дамп на канале между P1 и P2, где найдём сообщение, с помощью которого и производится подписка.

Итак, перед нами стандартное PIM-сообщение Join/Prune, отправляемое маршрутизатором PE2 в IP-пакете с адресом отправителя 4.4.4.4 и групповым адресом получателя 224.0.0.13. Однако это сообщение в overlay-сети, поэтому оно инкапсулируется внутрь GRE, после чего инкапсулируется внутрь пакета IPv4, передаваемого по underlay сети. Адрес получателя во внешнем IP-пакете равен 239.1.1.1, что соответствует группе mdt default для VRF A. Именно по этому адресу получателя опорная сеть отличает групповые потоки разных VRF.

Внутри самого PIM-сообщения мы также видим два IP-адреса: 3.3.3.3 и 5.5.5.5. Адрес 3.3.3.3 идентифицирует маршрутизатор PE1 – PIM-соседа для PE2. Адрес 5.5.5.5 указывает на «конечную точку», то есть адрес RP. Подписка на группы по протоколу PIM происходит последовательно по направлению от получателя в сторону Rendezvous Point (при отсутствии узла, отправляющего трафик для этой группы): CE2 подписывается на PE2, PE2 подписывается на PE1, PE1 – на CE1. Это означает, например, что на линке CE2-PE2 в качестве Upstream-neighbor будет указан адрес 4.4.4.4, при этом адрес RP (5.5.5.5) меняться не будет.

Data plane

Единственное, что осталось сделать, - убедиться в успешности передачи группового трафика между Sender и Receiver.

Sender#ping 239.7.7.7 repeat 5
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 239.7.7.7, timeout is 2 seconds:
Reply to request 0 from 10.0.1.2, 164 ms
Reply to request 1 from 10.0.1.2, 52 ms
Reply to request 2 from 10.0.1.2, 44 ms
Reply to request 3 from 10.0.1.2, 56 ms
Reply to request 4 from 10.0.1.2, 48 ms

Внутри сети оператора ICMP сообщения Echo Request, отправляемые на групповой адрес, выглядят так, как представлены ниже.

Сообщения ICMP Echo Reply отправляются в виде unicast, поэтому для этих пакетов применяются все стандартные правила передачи данных внутри VRF.

Если скорость потока multicast превышает заданную величину, то на underlay сети происходит переключение с группы mdt default на одну из групп mdt data. В этот момент по underlay-сети передаётся сообщение PIM Join –подписка на mdt data группу от устройства PE2 в сторону PE1.

Заключение

Групповое вещание может успешно передаваться по сети MPLS-оператора внутри VRF. Сигнализация может выполняться при помощи разных протоколов: в данном материале мы ограничились рассмотрением сигнализации PIM, однако в ближайшее время мы планируем описать сигнализацию с помощью протокола BGP.

Решение на базе Rosen GRE является весьма популярным, не в последнюю очередь благодаря практически повсеместной поддержке со стороны сетевого оборудования.

Конфигурация всех маршрутизаторов приведена в архиве.