Inter-AS mVPNs: MDT SAFI, BGP Connector & RPF Proxy Vector / forpes.ru

Главная
Inter-AS mVPNs: MDT SAFI, BGP Connector & RPF Proxy Vector

Inter-AS mVPNs: MDT SAFI, BGP Connector & RPF Proxy Vector

10.10.2022 14:36

braonle 0 358 Источник

Аннотация

Реализация Inter-AS Multicast VPN сопряжена с рядом проблем, если ядро сети не задействует протокол BGP. Эта статья описывает решение задачи на базе Cisco IOS, которое использует расширения протоколов MP-BGP и PIM. Автор предполагает понимание читателем базовой реализации Cisco mVPN, а также расширений протоколов PIM и MP-BGP.

Используемые обозначения

mVPN – Multicast VPN
MSDP – Multicast Source Discovery Protocol
PE – Provider Edge
CE – Customer Edge
RPF – Reverse Path Forwarding
MP-BGP – Multi-Protocol BGP
PIM – Protocol Independent Multicast
PIM SM – PIM Sparse Mode
PIM SSM – PIM Source Specific Multicast
LDP – Label Distribution Protocol
MDT – Multicast Distribution Tree
P-PIM – Provider Facing PIM Instance
C-PIM – Customer Facing PIM Instance
NLRI – Network Layer Rechability Information
AF – address family
AS – autonomous system

Обзор Inter-AS mVPN

"Классический" Inter-AS mVPN состоит из следующих ключевых компонентов:

PIM-SM с выделенными RP для каждой AS;
MSDP для обмена информацией об активных источниках multicast;
(Опционально) расширение MP-BGP для multicast, позволяющее передавать multicast маршруты для проверки RPF.

В рамках этого подхода разные PE, участвующие в одном MDT, обнаруживают друг друга следующим образом: они присоединяются к shared tree от локального RP и начинают слушать multicast-пакеты от других PE, которые могут принадлежать как к той же, так и к другой AS. В последнем случае за передачу информации об источниках multicast-трафика между AS отвечает MSDP. Этот метод предполагает, что каждый маршрутизатор локальной AS обладает полной информацией о маршрутах до источников multicast (интерфейсы loopback на PE) в другой AS. Это знание нужно маршрутизаторам для проведения проверки RPF. Такое требование, в свою очередь, приводит к необходимости использовать BGP на всех P-маршрутизаторах или совершать redistribute multicast-маршрутов из MP-BGP в IGP. Последний метод ограничен с точки зрения масштабируемости, тогда как другой подход требует BGP на P-маршрутизаторах, что противоречит идее построения ядра сети без использования BGP.

Альтернативой использованию PIM Sparse Mode может быть PIM SSM, который опирается на информацию об источниках multicast-трафика, полученную out-of-band. Для этого случая Cisco опубликовала черновик RFC, описывающий новый MP-BGP MDT SAFI для передачи информации об MDT и соответствующих адресах PE. Отвлечёмся ненадолго на MP-BGP, чтобы получше понять SAFI.

Обзор MP-BGP

Вспомним формат сообщения BGP UPDATE в его классическом варианте:

[Withdrawn prefixes (опционально)] + [Path Attributes] + [NLRI]

Withdrawn prefixes и NLRI содержат префиксы IPv4, и их структура не подразумевает поддержку иных протоколов. Path attributes (например, AS_PATH, ORIGIN, LOCAL_PREF, NEXT_HOP) привязаны к NLRI; префиксы с разными наборами аттрибутов необходимо передавать разными UPDATE. Также стоит отметить, что NEXT_HOP – это IPv4 адрес.

Чтобы реализовать в BGP поддержку протоколов, отличных от IPv4, были добавлены два новых transitive атрибута. Первый известен как MP_REACH_NLRI, который имеет следующую структуру:

[AFI/SAFI] + [NEXT_HOP] + [NLRI]

NEXT_HOP и NLRI выполнены в формате, который определён протоколом, закодированным в AFI/SAFI (Address Family Identifier и Subsequent Address Family Identifier, соответственно). К примеру, это может быть IPv4 префикс или CLNS. Таким образом, вся информация о не-IPv4 префиксах закодирована в новом BGP Path Attribute. Типовое сообщение BGP Update, которое несёт MP_REACH_NLRI, не содержит в себе "классического" атрибута NEXT_HOP, Withdrawn Prefixes или NLRI, которые можно найти в обычном UPDATE-сообщении. Для расчёта next-hop маршрутизатору следует использовать информацию из атрибута MP_REACH_NLRI. Тем не менее, MP-BGP UPDATE может нести остальные атрибуты BGP, такие как AS_PATH, ORIGIN, MED, LOCAL_PREF и т.д. Однако в этом случае атрибуты относятся к не-IPv4 префиксам из MP_REACH_NLRI.

Формат второго атрибута, MP_UNREACH_NLRI, похож на формат MP_REACH_NLRI; он перечисляет те маршруты MP-BGP, которые подлежат удалению. Другие атрибуты для этого не нужны, поэтому сообщение UPDATE может состоять только из MP_UNREACH_NLRI.

Список поддерживаемых AFI можно найти в RFC 1700 (несмотря на то, что он устарел, в нем можно найти много полезной информации). К примеру, AFI = 1 означает IPv4, AFI = 2 относится к IPv6 и т.д. Subsequent AFI нужны для уточнения назначения префиксов из MP_REACH_NLRI. Например, SAFI = 1 обозначает unicast-маршруты, префиксы из SAFI = 2 предназначены для проверок RPF, а SAFI = 3 позволяет использовать префикс для обеих целей. Другой важный SAFI – SAFI = 128, который означает MPLS labeled VPN маршрут.

Напоминание: процесс BGP вычисляет лучший путь, сравнивая атрибуты для каждого семейства маршрутов (пара AFI/SAFI) независимо. Поскольку конкретный маршрутизатор может и не поддерживать определённые сетевые протоколы, список доступных AFI/SAFI должен быть обьявлен через BGP capabilities (ещё одно расширение BGP). Маршрутная информация для сетевого протокола может быть передана по MP-BGP только в том случае, если оба маршрутизатора анонсируют поддержку этого протокола.

Обзор MDT SAFI

Cisco описала в черновике RFC новый SAFI, который может быть использован с обычным AFI, таким как IPv4 или IPv6. Этот SAFI нужен для передачи адреса MDT-группы, а также адресов loopback соответствующих PE. Формат для AFI = 1 (IPv4) следующий:

MP_NLRI = [RD:PE’s IPv4 Address]:[MDT Group Address]
MP_NEXT_HOP = [BGP Peer IPv4 Address]

Значение RD берётся из VRF, который использует MDT, а "IPv4 address" – адрес loopback соответствующего PE. По правилам Cisco это обычно тот же loopback, который используют для установления VPNv4-сессии, однако его можно и изменить командой bgp next-hop уровня VRF.

Если все PE из локальной AS обменяются такой информацией и передадут её PIM SSM, то процесс P-PIM (Provider PIM, который смотрит в ядро провайдера) сможет построить (S,G) дерево для группы MDT в сторону IPv4 адресов других PE. Это возможно благодаря тому, что адреса всех PE известны через IGP, так как все PE находятся в одной AS. В таком случае не должно возникнуть каких-либо проблем с intra-AS mVPN + PIM-SSM из-за BGP-free ядра сети. Стоит отметить, что предшественником SAFI был специальный extended community в VPNv4 AF. MP-BGP использовал значение RD, равное 2 (невозможно в unicast VRF), для передачи адреса соответствующего PE, тогда как community переносил адрес MDT-группы. Это позволило передавать информацию для автонастройки сети в рамках одной AS, так как extended community был non-transitive. Черновик MDT SAFI пришёл на смену этому временному решению.

Теперь представим ситуацию Inter-AS VPN, где хотя бы одна AS использует BGP-free ядро. Как только соседние автономные системы активируют IPv4 MDT SAFI, ASBR обменяются между собой всей информацией, полученной от PE, а затем распространят её в своей AS. После этого процесс P-PIM попробует построить (S,G)-дерево до IP-адресов PE, находящихся в другой AS. Несмотря на то, что PE могут знать адреса PE из соседних AS (например, в случае Inter-AS VPN Option C), P-маршрутизаторы не обладают такой информацией. В случае же Inter-AS VPN Option B даже у PE-маршрутизаторов не будет достаточно информации для построения (S,G)-дерева.

RPF Proxy Vector

Решение описанной проблемы, RPF Proxy Vector, включает в себя модификацию протокола PIM и проверки RPF за счёт нового PIM TLV. Он содержит IPv4 адрес "proxy"-маршрутизатора, который должен быть использован для проверок RPF и в качестве промежуточной точки назначения для PIM Join. Рассмотрим принцип работы на конкретном примере.

На картинке ниже AS 100 и AS 200 используют Inter-AS VPN Option B для обмена маршрутами VPNv4. PE и ASBR установили BGP-сессии между собой и обмениваются маршрутами VPNv4 и IPv4 MDT SAFI. У каждого внешнего префикса, который нужно передать внутренним PE своей AS, ASBR меняет next-hop из MP_REACH_NLRI на адрес своего loopback. Для маршрутов VPNv4 это позволяет терминировать LSP на ASBR, а для маршрутов MDT SAFI – использовать IPv4 адрес в качестве "proxy" для PIM Join.

Допустим, что R1 и R5 используют 232.1.1.1 в качестве адреса MDT-группы. Когда R1 получает обновление MDT SAFI со значениями MDT 200:1:232.1.1.1, адресом PE 20.0.5.5 и адресом next-hop 10.0.3.3 (loopback R3), он передаёт эту информацию процессу PIM. Последний формирует сообщение PIM Join для группы 232.1.1.1 в сторону IP-адреса 20.0.5.5 (неизвестен в AS 100) и вставляет proxy vector со значением 10.0.3.3. После этого PIM использует маршрут до 10.0.3.3, чтобы найти upstream PIM-соседа и отправить ему Join-сообщение. Каждый P-маршрутизатор обрабатывает PIM Join с proxy vector и использует proxy-адрес для пересылки Join дальше. Как только Join достигает proxy-маршрутизатора (в нашем случае R3), последний удаляет из него proxy vector и пересылает дальше согласно обычным правилам, поскольку теперь цель Join известна в AS.

Помимо использования proxy vector при пересылке PIM Join, каждый маршрутизатор создаёт специальную запись mroute для пары (S,G), где S – это IPv4-адрес PE, а G – адрес группы MDT. С этой записью связан proxy-адрес IPv4. Когда соответствующий multicast-пакет от внешнего PE по MDT достигает маршрутизатора, последний выполняет проверку RPF на основе исходящего интерфейса в сторону proxy-адреса, а не адреса источника пакета. К примеру, в нашем случае R2 создал бы запись для (20.5.5.5, 232.1.1.1) с proxy-адресом 10.0.3.3. Все пакеты от R5 для 232.1.1.1 попадали бы под проверку RPF с использованием интерфейса в сторону 10.0.3.3.

Используя описанный выше алгоритм на основе proxy vector, P-маршрутизаторы могут успешно выполнять проверки RPF для адресов, отсутствующих в таблице маршрутизации. Расплата за это – количество записей, описывающих состояние multicast, которые необходимо хранить в памяти P-маршрутизаторам. Этот объём в худшем случае, когда каждый PE участвует в каждом mVPN, пропорционален количеству PE, умноженному на число mVPN. Возможно даже большее количество записей, когда помимо Default MDT активна ещё и Data MDT.

BGP Connector Attribute

Есть ещё кое-что, что необходимо для функционирования "intra-VPN": нужно уметь присоединяться к PIM-дереву в сторону определённого адреса внутри VPN и проводить проверку RPF внутри VPN. Представим себе Inter-AS VPN Option B, где адреса MP_REACH_NLRI next-hop для префиксов VPNv4 заменены на IPv4-адрес ASBR. Когда локальный PE получает multicast-пакет по MDT-туннелю, он декапсулирует его и ищет адрес источника этого пакета в таблице маршрутизации VRF. Согласно маршрутам, полученным по MP-BGP, next-hop указывает на ASBR (Option B), тогда как пакеты могут приходить со стороны другого inter-AS соединения, на котором развёрнута сессия multicast MP-BGP. Таким образом, не всегда можно положиться только лишь на unicast next-hop для проверок RPF в среде Inter-AS.

К примеру, на картинке ниже, где R3 и R4 используют MP-BGP для обмена VPNv4-маршрутами, а R4 и R6 используют расширение MP-BGP для multicast. R1 установил соединение с обоими ASBR, получая VPNv4 префиксы от R3, а информацию MDT SAFI и IPv4-адреса PE – от R6. PIM включён только на соединении между R6 и R4.

В такой ситуации проверка RPF провалится, так как информация MDT SAFI получена по соединению с MP-BGP, тогда как next-hop для VPNv4 префиксов указывает на R3. Выходит, что нужен отдельный механизм сохранения необходимой для прохождения проверки RPF информации.

Причём тут RPF, и почему он провалится? (примечание переводчика)

RPF для multicast VPN выполняется следующим образом:

Если outgoing interface до source IP принадлежит VRF – провести RPF, как обычно, на основе исходящего интерфейса и unicast RIB.
Если же source IP известен через VPNv4, то outgoing interface – это туннель. Помимо этого, outer source IP должен совпадать с next-hop до inner source IP.

На примере выше next-hop для маршрута VPNv4 – 10.0.3.3, а PIM Join приходит внутри MDT с адреса 20.0.5.5, что вызывает провал проверки RPF. BGP Connector как раз и сохраняет первоначальный адрес PE сугубо для RPF-проверки в рамках customer PIM. Внутри AS такого обычно не происходит, так как префиксы проходят через RR или конфедерацию без изменения next-hop. Собственно, оттуда же требование использовать один и тот же loopback в качестве source IP для BGP-сессий, так как source для MDT выбирается автомагически.

R1#sho ip rpf vrf RED 192.168.5.1 
RPF information for ? (192.168.5.1)
  RPF interface: Tunnel0
  RPF neighbor: ? (20.0.5.5)
  RPF route/mask: 192.168.5.0/24
  RPF type: unicast (bgp 100)
  Doing distance-preferred lookups across tables
  BGP originator: 20.0.5.5
  RPF topology: ipv4 multicast base, originated from ipv4 unicast base

Cisco предложила использовать новый, optional transitive, атрибут – BGP Connector, который PE с настроенным multicast VPN должен экспортировать вместе с VPNv4 маршрутами. Этот атрибут состоит из двух частей:

[AFI/SAFI] + [Connector Information]

Если AFI = IPv4 и SAFI = MDT, то атрибут содержит IPv4-адрес маршрутизатора, изначально создавшего маршрут VPNv4 в рамках VRF, который использует MDT.

Процесс C-PIM (PIM в сторону CE) на PE-маршрутизаторах использует информацию из атрибута BGP Connector при проверке RPF и отправке PIM Join. Стоит отметить, что C-PIM Join не требуют использования proxy vector, так они идут внутри MDT-туннеля.

Можно заметить, что использование BGP Connector делает ненужным отдельный VPNv4 multicast AF, который можно было бы использовать для передачи информации для проверок RPF VPNv4 префиксов. Без VPNv4 multicast AF можно обойтись, поскольку multicast-пакеты проходят через ядро SP внутри MDT-туннелей и BGP Connector достаточно для проверки RPF на границе оператора. Однако multicast BGP всё ещё необходим, когда unicast и multicast трафик идут по разным путям между AS.

Практикум

Две автономные системы, AS 100 и AS 200, используют Inter-AS VPN Option B для обмена VPNv4 маршрутами по соединению между R3-R4. Одновременно с этим происходит обмен multicast-префиксами и MDT SAFI по соединению R6-R4. AS 100 не использует BGP в ядре сети, поэтому R2 не устанавливает каких-либо BGP-сессий и использует только OSPF для обмена префиксами внутри AS. R1 поддерживает сессии до обоих ASBR, R3 и R6, чтобы получать префиксы VPNv4 и MDT SAFI по MP-BGP.

На схеме PIM SM работает только на соединениях оранжевого цвета, поэтому только они могут передавать multicast. Стоит отметить, что MPLS и multicast идут по разным путям между AS. Перечислим основные моменты в настройке R1:

VRF RED использует адрес 232.1.1.1 для группы MDT. P-PIM использует PIM SSM с диапазоном адресов по умолчанию – 232.0.0.0/8.
Команда ip multicast vrf RED rpf proxy rd vector включает использование RPF Proxy Vector протоколом P-PIM для построения MDT, который настроен в VRF RED. Стоит отметить, что команда ip multicast rpf proxy vector относится к сообщениям PIM Join, полученным в глобальном VRF, её обычно можно найти на P-маршрутизаторах.
R1 обменивается по MP-BGP префиксами VPNv4 с R3, а multicast-маршрутами – с R6. В то же время R1 и R6 передают друг другу IPv4 MDT SAFI, чтобы R1 мог узнать об MDT из AS 200.
Connected-маршруты из VRF RED попадают в MP-BGP через redistribute.

hostname R1
!
interface Serial 2/0
 encapsulation frame-relay
 no shutdown
!
ip multicast-routing
ip pim ssm default
!
interface Serial 2/0.12 point-to-point
 ip address 10.0.12.1 255.255.255.0
 frame-relay interface-dlci 102
 mpls ip
 ip pim sparse-mode
!
interface Loopback0
 ip pim sparse-mode
 ip address 10.0.1.1 255.255.255.255
!
router ospf 1
 network 10.0.12.1 0.0.0.0 area 0
 network 10.0.1.1 0.0.0.0 area 0
!
router bgp 100
  neighbor 10.0.3.3 remote-as 100
  neighbor 10.0.3.3 update-source Loopback 0
  neighbor 10.0.6.6 remote-as 100
  neighbor 10.0.6.6 update-source Loopback 0
address-family ipv4 unicast
  no neighbor 10.0.3.3 activate
  no neighbor 10.0.6.6 activate
address-family vpnv4 unicast
  neighbor 10.0.3.3 activate
  neighbor 10.0.3.3 send-community both
address-family ipv4 mdt
  neighbor 10.0.6.6 activate
address-family ipv4 multicast
  neighbor 10.0.6.6 activate
  network 10.0.1.1 mask 255.255.255.255
address-family ipv4 vrf RED
  redistribute connected
!
no ip domain-lookup
!
ip multicast vrf RED rpf proxy rd vector
!
 ip vrf RED
  rd 100:1
  route-target both 200:1
  route-target both 100:1
  mdt default 232.1.1.1
!
ip multicast-routing vrf RED
!
interface FastEthernet 0/0
 ip vrf forwarding RED
 ip address 192.168.1.1 255.255.255.0
 ip pim dense-mode
 no shutdown

Обратите внимание, что интерфейс Loopback0 является источником для туннеля MDT, поэтому на нём должен быть включён PIM, чтобы активировать маршрутизацию multicast.

R2 не выделяется ничем особенным: OSPF в качестве протокола маршрутизации, а также LDP для обмена метками. Стоит отметить, что R2 не использует PIM на интерфейсе в сторону R3, а на интерфейсе в сторону R6 не активен LDP. Выходит, что через R6 пролегает путь только multicast-трафика, тогда как R3 является частью MPLS LSP. R2 использует PIM SSM и RPF proxy vector в глобальном VRF.

hostname R2
!
no ip domain-lookup
!
interface Serial 2/0
 encapsulation frame-relay
 no shut
!
ip multicast-routing
!
interface Serial 2/0.12 point-to-point
 ip address 10.0.12.2 255.255.255.0
 frame-relay interface-dlci 201
 mpls ip
 ip pim sparse-mode
!
ip pim ssm default
!
interface Serial 2/0.23 point-to-point
 ip address 10.0.23.2 255.255.255.0
 frame-relay interface-dlci 203
 mpls ip
!
interface Serial 2/0.26 point-to-point
 ip address 10.0.26.2 255.255.255.0
 frame-relay interface-dlci 206
 ip pim sparse-mode
!
interface Loopback0
 ip address 10.0.2.2 255.255.255.255
!
ip multicast rpf proxy vector
!
router ospf 1
 network 10.0.12.2 0.0.0.0 area 0
 network 10.0.2.2 0.0.0.0 area 0
 network 10.0.23.2 0.0.0.0 area 0
 network 10.0.26.2 0.0.0.0 area 0

R3 – это ASBR в Inter-AS VPN Option B. Он устанавливает сессии BGP с R1 (PE) и R4 (другой ASBR). В рамках этих сессий активен только VPNv4. Обратите внимание, что next-hop для маршрутов VPNv4 должен быть заменён на свой собственный адрес, чтобы транспортный LSP от PE проходил через R3. Никакая информация о multicast или MDT SAFI на R3 не появляется.

hostname R3
!
no ip domain-lookup
!
interface Serial 2/0
 encapsulation frame-relay
 no shut
!
interface Serial 2/0.23 point-to-point
 ip address 10.0.23.3 255.255.255.0
 frame-relay interface-dlci 302
 mpls ip
!
interface Serial 2/0.34 point-to-point
 ip address 172.16.34.3 255.255.255.0
 frame-relay interface-dlci 304
 mpls ip
!
interface Loopback0
 ip address 10.0.3.3 255.255.255.255
!
router ospf 1
 network 10.0.23.3 0.0.0.0 area 0
 network 10.0.3.3 0.0.0.0 area 0
!
router bgp 100
 no bgp default route-target filter
 neighbor 10.0.1.1 remote-as 100
 neighbor 10.0.1.1 update-source Loopback 0
 neighbor 172.16.34.4 remote-as 200
address-family ipv4 unicast
  no neighbor 10.0.1.1 activate
  no neighbor 172.16.34.4 activate
address-family vpnv4 unicast
  neighbor 10.0.1.1 activate
  neighbor 10.0.1.1 next-hop-self
  neighbor 10.0.1.1 send-community both
  neighbor 172.16.34.4 activate
  neighbor 172.16.34.4 send-community both

Второй ASBR из AS 100, R6, является multicast-only ASBR: он передаёт только multicast-префиксы и MDT SAFI между R1 и R4. MPLS неактивен на этом маршрутизаторе, так как единственная его задача – передача multicast-трафика между AS 100 и AS 200. MSDP в такой схеме не нужен, так как для построения multicast-деревьев применён PIM SSM.

hostname R6
!
no ip domain-lookup
!
interface Serial 2/0
 encapsulation frame-relay
no shut
!
ip multicast-routing
ip pim ssm default
ip multicast rpf proxy vector
!
interface Serial 2/0.26 point-to-point
 ip address 10.0.26.6 255.255.255.0
 frame-relay interface-dlci 602
 ip pim sparse-mode
!
interface Serial 2/0.46 point-to-point
 ip address 172.16.46.6 255.255.255.0
 frame-relay interface-dlci 604
 ip pim sparse-mode
!
interface Loopback0
 ip pim sparse-mode
 ip address 10.0.6.6 255.255.255.255
!
router ospf 1
 network 10.0.6.6 0.0.0.0 area 0
 network 10.0.26.6 0.0.0.0 area 0
!
router bgp 100
 neighbor 10.0.1.1 remote-as 100
  neighbor 10.0.1.1 update-source Loopback 0
  neighbor 172.16.46.4 remote-as 200
address-family ipv4 unicast
  no neighbor 10.0.1.1 activate
  no neighbor 172.16.46.4 activate
address-family ipv4 mdt
  neighbor 172.16.46.4 activate
  neighbor 10.0.1.1 activate
  neighbor 10.0.1.1 next-hop-self
address-family ipv4 multicast
  neighbor 172.16.46.4 activate
  neighbor 10.0.1.1 activate
  neighbor 10.0.1.1 next-hop-self

Стоит обратить внимание на несколько важных нюансов. Во-первых, R6 использует PIM SSM с поддержкой RPF Proxy Vector. Во-вторых, R6 выставляет себя в качестве BGP next-hop для обновлений в рамках multicast AF и MDT SAFI. Это необходимо для корректного построения MDT-дерева и добавления RPF vector в сообщения PIM Join.

Следующий маршрутизатор, R4, совмещает в себе роли VPNv4 и multicast ASBR для AS 200. Он выполняет все те же функции, за которые независимо отвечают R3 и R6 в AS 100. VPNv4, MDT SAFI и multicast AF активны в BGP. Одновременно с этим настроена поддержка RPF Proxy Vector и PIM SSM для корректной маршрутизации multicast. Настройка R4 является наиболее громоздкой в этой схеме, поскольку она также предполагает конфигурацию BGP и LDP для передачи MPLS-меток. Очевидно, что будучи ASBR в схеме Inter-AS Option B, R4 должен подменить next-hop на свой адрес для всех AF в обновлениях для R5 – PE в AS 200.

hostname R4
!
no ip domain-lookup
!
interface Serial 2/0
 encapsulation frame-relay
no shut
!
ip pim ssm default
ip multicast rpf proxy vector
ip multicast-routing
!
interface Serial 2/0.34 point-to-point
 ip address 172.16.34.4 255.255.255.0
 frame-relay interface-dlci 403
 mpls ip
!
interface Serial 2/0.45 point-to-point
 ip address 20.0.45.4 255.255.255.0
 frame-relay interface-dlci 405
 mpls ip
 ip pim sparse-mode
!
interface Serial 2/0.46 point-to-point
 ip address 172.16.46.4 255.255.255.0
 frame-relay interface-dlci 406
 ip pim sparse-mode
!
interface Loopback0
 ip address 20.0.4.4 255.255.255.255
!
router ospf 1
 network 20.0.4.4 0.0.0.0 area 0
 network 20.0.45.4 0.0.0.0 area 0
!
router bgp 200
  no bgp default route-target filter
  neighbor 172.16.34.3 remote-as 100
  neighbor 172.16.46.6 remote-as 100
  neighbor 20.0.5.5 remote-as 200
  neighbor 20.0.5.5 update-source Loopback0
address-family ipv4 unicast
  no neighbor 172.16.34.3 activate
  no neighbor 20.0.5.5 activate
  no neighbor 172.16.46.6 activate
address-family vpnv4 unicast
  neighbor 172.16.34.3 activate
  neighbor 172.16.34.3 send-community both
  neighbor 20.0.5.5 activate
  neighbor 20.0.5.5 send-community both
  neighbor 20.0.5.5 next-hop-self
address-family ipv4 mdt
  neighbor 172.16.46.6 activate
  neighbor 20.0.5.5 activate
  neighbor 20.0.5.5 next-hop-self
address-family ipv4 multicast
  neighbor 20.0.5.5 activate
  neighbor 20.0.5.5 next-hop-self
  neighbor 172.16.46.6 activate

Последний неокученный маршрутизатор в схеме – R5. Он является PE в AS 200, настройка которого аналогична конфигурации R1. Он должен поддерживать VPNv4, MDT SAFI и multicast AF, чтобы получить всю необходимую информацию от ASBR. Очевидно, что нужно включить использование RPF Proxy Vector для MDT-дерева VRF RED, а также активировать PIM SSM в глобальном VRF для диапазона адресов по умолчанию. Как можно заметить, в AS 200 нет маршрутизатора, выполняющего роль ядра сети.

hostname R5
!
no ip domain-lookup
!
interface Serial 2/0
 encapsulation frame-relay
no shut
!
ip multicast-routing
!
interface Serial 2/0.45 point-to-point
 ip address 20.0.45.5 255.255.255.0
 frame-relay interface-dlci 504
 mpls ip
 ip pim sparse-mode
!
interface Loopback0
 ip pim sparse-mode
 ip address 20.0.5.5 255.255.255.255
!
router ospf 1
 network 20.0.5.5 0.0.0.0 area 0
 network 20.0.45.5 0.0.0.0 area 0
!
ip vrf RED
 rd 200:1
 route-target both 200:1
 route-target both 100:1
 mdt default 232.1.1.1
!
router bgp 200
  neighbor 20.0.4.4 remote-as 200
  neighbor 20.0.4.4 update-source Loopback0
  address-family ipv4 unicast
  no neighbor 20.0.4.4 activate
address-family vpnv4 unicast
  neighbor 20.0.4.4 activate
  neighbor 20.0.4.4 send-community both
address-family ipv4 mdt
  neighbor 20.0.4.4 activate
address-family ipv4 multicast
   neighbor 20.0.4.4 activate
   network 20.0.5.5 mask 255.255.255.255
address-family ipv4 vrf RED
  redistribute connected
!
ip multicast vrf RED rpf proxy rd vector
ip pim ssm default
!
ip multicast-routing vrf RED
!
interface FastEthernet 0/0
 ip vrf forwarding RED
 ip address 192.168.5.1 255.255.255.0
 ip pim dense-mode
 no shutdown

Проверка работоспособности пути unicast-трафика

Эта часть самая простая. Используем show команды, чтобы увидеть, происходит ли в конечном итоге обмен префиксами между PE, а также есть ли связность между ними:

R1#sh ip route vrf RED

Routing Table: RED
Codes: 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

Gateway of last resort is not set

B    192.168.5.0/24 [200/0] via 10.0.3.3, 00:50:35
C    192.168.1.0/24 is directly connected, FastEthernet0/0

R1#show bgp vpnv4 unicast vrf RED
BGP table version is 5, local router ID is 10.0.1.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
Route Distinguisher: 100:1 (default for vrf RED)
*> 192.168.1.0      0.0.0.0                  0         32768 ?
*>i192.168.5.0 10.0.3.3 0 100 0 200 ?

R1#show bgp vpnv4 unicast vrf RED 192.168.5.0
BGP routing table entry for 100:1:192.168.5.0/24, version 5
Paths: (1 available, best #1, table RED)
  Not advertised to any peer
  200, imported path from 200:1:192.168.5.0/24
    10.0.3.3 (metric 129) from 10.0.3.3 (10.0.3.3)
      Origin incomplete, metric 0, localpref 100, valid, internal, best
      Extended Community: RT:100:1 RT:200:1
      Connector Attribute: count=1
 type 1 len 12 value 200:1:20.0.5.5
 mpls labels in/out nolabel/23

R1#traceroute vrf RED 192.168.5.1
Type escape sequence to abort.
Tracing the route to 192.168.5.1
  1 10.0.12.2 [MPLS: Labels 17/23 Exp 0] 432 msec 36 msec 60 msec
  2 10.0.23.3 [MPLS: Label 23 Exp 0] 68 msec 8 msec 36 msec
  3 172.16.34.4 [MPLS: Label 19 Exp 0] 64 msec 16 msec 48 msec
  4 192.168.5.1 12 msec *  8 msec

Обратите внимание, что для префикса 192.168.5.0/24 значение атрибута next-hop равно 10.0.3.3, а значение атрибута BGP Connector – 200:1:20.0.5.5. Эта информация пригодится впоследствии для проверок RPF, когда пойдёт multicast-трафик.

Проверка работоспособности пути multicast-трафика

Передача multicast-трафика несколько более сложна. Первым делом нужно убедиться, что дерево MDT построено как от R1 до R5, так и в обратном направлении. Проверим группы PIM MDT на каждом PE:

R1#show ip pim mdt 
  MDT Group       Interface   Source                   VRF
* 232.1.1.1       Tunnel0     Loopback0                RED

R1#show ip pim mdt bgp
MDT (Route Distinguisher + IPv4)               Router ID         Next Hop
  MDT group 232.1.1.1
   200:1:20.0.5.5                              10.0.6.6          10.0.6.6

R5#show ip pim mdt 
  MDT Group       Interface   Source                   VRF
* 232.1.1.1       Tunnel0     Loopback0                RED

R5#show ip pim mdt bgp
MDT (Route Distinguisher + IPv4)               Router ID         Next Hop
  MDT group 232.1.1.1
   100:1:10.0.1.1                              20.0.4.4          20.0.4.4

В выводах команд выше обратите внимание на значения next-hop для MDT BGP. В AS 100 оно указывает на R6, тогда как в AS 200 – на R4. Эти значения попадут в Proxy Vector в сообщениях PIM Join. Проверим multicast-маршруты для дерева (20.0.5.5, 232.1.1.1), начиная с R1 и продолжая вдоль R2, R6, R4 и R5:

R1#show ip mroute 232.1.1.1
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

(20.0.5.5, 232.1.1.1), 00:58:49/00:02:59, flags: sTIZV
  Incoming interface: Serial2/0.12, RPF nbr 10.0.12.2, vector 10.0.6.6
  Outgoing interface list:
    MVRF RED, Forward/Sparse, 00:58:49/00:01:17

(10.0.1.1, 232.1.1.1), 00:58:49/00:03:19, flags: sT
  Incoming interface: Loopback0, RPF nbr 0.0.0.0
  Outgoing interface list:
    Serial2/0.12, Forward/Sparse, 00:58:47/00:02:55

R1#show ip mroute 232.1.1.1 proxy
(20.0.5.5, 232.1.1.1)
  Proxy                      Assigner         Origin    Uptime/Expire
  200:1/10.0.6.6             0.0.0.0          BGP MDT   00:58:51/stopped

R1 указывает для источника 20.0.5.5 значение RPF proxy, равное 10.0.6.6. Обратите внимание, что в таблице маршрутизации присутствует дерево в сторону 10.0.1.1, которое берёт начало от R5. У этого дерева нет proxy, так как дерево уже находится в целевой AS.

Следующие на проверку – R2 и R6, где мы должны найти ту же информацию (помним о том, что именно proxy убирает vector при получении PIM Join):

R2#show ip mroute 232.1.1.1
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

(10.0.1.1, 232.1.1.1), 01:01:41/00:03:25, flags: sT
  Incoming interface: Serial2/0.12, RPF nbr 10.0.12.1
  Outgoing interface list:
    Serial2/0.26, Forward/Sparse, 01:01:41/00:02:50

(20.0.5.5, 232.1.1.1), 01:01:43/00:03:25, flags: sTV
  Incoming interface: Serial2/0.26, RPF nbr 10.0.26.6, vector 10.0.6.6
  Outgoing interface list:
    Serial2/0.12, Forward/Sparse, 01:01:43/00:02:56

R2#show ip mroute 232.1.1.1 proxy 
(20.0.5.5, 232.1.1.1)
    Proxy                      Assigner         Origin    Uptime/Expire
    200:1/10.0.6.6             10.0.12.1        PIM       01:01:46/00:02:23

Обратите внимание на такое же значение proxy vector для (20.0.5.5, 232.1.1.1), как и у R1. Как и следовало ожидать, присутствует и противоположно направленное дерево от R5 к R1, которое не использует RPF proxy vector в AS 100.

Перейдём к выводу команд с R6. Стоит отметить, что R6 в курсе про два proxy vector, одним из которых является он сам:

R6#show ip mroute 232.1.1.1
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

(10.0.1.1, 232.1.1.1), 01:05:40/00:03:21, flags: sT
  Incoming interface: Serial2/0.26, RPF nbr 10.0.26.2
  Outgoing interface list:
    Serial2/0.46, Forward/Sparse, 01:05:40/00:02:56

(20.0.5.5, 232.1.1.1), 01:05:42/00:03:21, flags: sTV
  Incoming interface: Serial2/0.46, RPF nbr 172.16.46.4, vector 172.16.46.4
  Outgoing interface list:
    Serial2/0.26, Forward/Sparse, 01:05:42/00:02:51

R6#show ip mroute proxy
(10.0.1.1, 232.1.1.1)
  Proxy                      Assigner         Origin    Uptime/Expire
  100:1/local                172.16.46.4      PIM       01:05:44/00:02:21
(20.0.5.5, 232.1.1.1)
  Proxy                      Assigner         Origin    Uptime/Expire
  200:1/local                10.0.26.2        PIM       01:05:47/00:02:17

Выводы команд с R4 похожи на выводы с R6 – так же присутствуют proxy для обоих деревьев multicast:

R4#show ip mroute 232.1.1.1
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

(10.0.1.1, 232.1.1.1), 01:08:42/00:03:16, flags: sTV
  Incoming interface: Serial2/0.46, RPF nbr 172.16.46.6, vector 172.16.46.6
  Outgoing interface list:
    Serial2/0.45, Forward/Sparse, 01:08:42/00:02:51

(20.0.5.5, 232.1.1.1), 01:08:44/00:03:16, flags: sT
  Incoming interface: Serial2/0.45, RPF nbr 20.0.45.5
  Outgoing interface list:
    Serial2/0.46, Forward/Sparse, 01:08:44/00:02:46

R4#show ip mroute proxy
(10.0.1.1, 232.1.1.1)
  Proxy                      Assigner         Origin    Uptime/Expire
  100:1/local                20.0.45.5        PIM       01:08:46/00:02:17
(20.0.5.5, 232.1.1.1)
  Proxy                      Assigner         Origin    Uptime/Expire
  200:1/local                172.16.46.6      PIM       01:08:48/00:02:12

Наконец, вывод с R5 зеркален тому, что мы видели на R1. Однако в этом случае роли multicast-деревьев поменялись местами: для дерева в сторону R1 установлено значение proxy vector:

R5#show ip mroute 232.1.1.1
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

(10.0.1.1, 232.1.1.1), 01:12:07/00:02:57, flags: sTIZV
  Incoming interface: Serial2/0.45, RPF nbr 20.0.45.4, vector 20.0.4.4
  Outgoing interface list:
    MVRF RED, Forward/Sparse, 01:12:07/00:00:02

(20.0.5.5, 232.1.1.1), 01:13:40/00:03:27, flags: sT
  Incoming interface: Loopback0, RPF nbr 0.0.0.0
  Outgoing interface list:
    Serial2/0.45, Forward/Sparse, 01:12:09/00:03:12

R5#show ip mroute proxy
(10.0.1.1, 232.1.1.1)
  Proxy                      Assigner         Origin    Uptime/Expire
  100:1/20.0.4.4             0.0.0.0          BGP MDT   01:12:10/stopped

Таблица BGP на R5 также содержит атрибут BGP Connector для префикса интерфейса Ethernet на R1:

R5#show bgp vpnv4 unicast vrf RED 192.168.1.0
BGP routing table entry for 200:1:192.168.1.0/24, version 6
Paths: (1 available, best #1, table RED)
  Not advertised to any peer
  100, imported path from 100:1:192.168.1.0/24
    20.0.4.4 (metric 65) from 20.0.4.4 (20.0.4.4)
      Origin incomplete, metric 0, localpref 100, valid, internal, best
      Extended Community: RT:100:1 RT:200:1
        Connector Attribute: count=1
       type 1 len 12 value 100:1:10.0.1.1
      mpls labels in/out nolabel/18

Помимо атрибута BGP Connector, нужны маршруты до источников multicast, которые переданы по IPv4 multicast AF. Эта информация должна быть в таблицах BGP как на R1, так и на R5:

R5#show bgp ipv4 multicast
BGP table version is 3, local router ID is 20.0.5.5
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*>i10.0.1.1/32      20.0.4.4                 0    100      0 100 i
*> 20.0.5.5/32      0.0.0.0                  0         32768 i

R1#show bgp ipv4 multicast
BGP table version is 3, local router ID is 10.0.1.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*> 10.0.1.1/32      0.0.0.0                  0         32768 i
*>i20.0.5.5/32      10.0.6.6                 0    100      0 200 i

Настало время проверить связность для multicast. Убедимся, что R1 и R5 видят друг друга как соседей PIM через MDT, а затем запустим multicast ping в сторону группы, которую слушают R1 и R5:

R1#show ip pim vrf RED neighbor 
PIM Neighbor Table
Mode: B - Bidir Capable, DR - Designated Router, N - Default DR Priority,
      S - State Refresh Capable
Neighbor          Interface                Uptime/Expires    Ver   DR
Address                                                            Prio/Mode

20.0.5.5          Tunnel0                  01:31:38/00:01:15 v2    1 / DR S P

R5#show ip pim vrf RED neighbor 
PIM Neighbor Table
Mode: B - Bidir Capable, DR - Designated Router, N - Default DR Priority,
      S - State Refresh Capable
Neighbor          Interface                Uptime/Expires    Ver   DR
Address                                                            Prio/Mode

10.0.1.1          Tunnel0                  01:31:17/00:01:26 v2    1 / S P

R1#ping vrf RED 239.1.1.1 repeat 100
Type escape sequence to abort.
Sending 100, 100-byte ICMP Echos to 239.1.1.1, timeout is 2 seconds:

Reply to request 0 from 192.168.1.1, 12 ms
Reply to request 0 from 20.0.5.5, 64 ms
Reply to request 1 from 192.168.1.1, 8 ms
Reply to request 1 from 20.0.5.5, 56 ms
Reply to request 2 from 192.168.1.1, 8 ms
Reply to request 2 from 20.0.5.5, 100 ms
Reply to request 3 from 192.168.1.1, 16 ms
Reply to request 3 from 20.0.5.5, 56 ms

На этом проверку тестового стенда можно считать пройденной.

Вывод

В этой статье автор продемонстрировал, как можно использовать расширения MP-BGP и PIM для эффективной реализации Inter-AS multicast VPN между автономными системами, которые построены без опоры на BGP в ядре сети. PIM SSM отвечает за построение multicast-деревьев между AS, а MDT SAFI – за обнаружение адресов активных MDT-групп и соответствующих им PE. PIM RPF Proxy Vector обеспечивает корректное выполнение проверки RPF в ядре сети, не использующем BGP, за счет использования адреса proxy в качестве целевого. Наконец, атрибут BGP Connector обеспечивает прохождение проверки RPF внутри самого VRF.

Источники

Multicast VPN
Multicast Tunnel Discovery
PIM RPF Vector
MDT SAFI
MDT SAFI Configuration
PIM RPF Proxy Vector Configuration