Реализация Inter-AS Multicast VPN сопряжена с рядом проблем, если ядро сети не задействует протокол BGP. Эта статья описывает решение задачи на базе Cisco IOS, которое использует расширения протоколов MP-BGP и PIM. Автор предполагает понимание читателем базовой реализации Cisco mVPN, а также расширений протоколов PIM и MP-BGP. mVPN – Multicast VPNMSDP – Multicast Source Discovery ProtocolPE – Provider EdgeCE – Customer EdgeRPF – Reverse Path ForwardingMP-BGP – Multi-Protocol BGPPIM – Protocol Independent MulticastPIM SM – PIM Sparse ModePIM SSM – PIM Source Specific MulticastLDP – Label Distribution ProtocolMDT – Multicast Distribution TreeP-PIM – Provider Facing PIM InstanceC-PIM – Customer Facing PIM InstanceNLRI – Network Layer Rechability InformationAF – address familyAS – autonomous system "Классический" 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. Вспомним формат сообщения BGP UPDATE в его классическом варианте:  Withdrawn prefixes и NLRI содержат префиксы IPv4, и их структура не подразумевает поддержку иных протоколов. Path attributes (например, AS_PATH, ORIGIN, LOCAL_PREF, NEXT_HOP) привязаны к NLRI; префиксы с разными наборами аттрибутов необходимо передавать разными UPDATE. Также стоит отметить, что NEXT_HOP – это IPv4 адрес. Чтобы реализовать в BGP поддержку протоколов, отличных от IPv4, были добавлены два новых transitive атрибута. Первый известен как MP_REACH_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 только в том случае, если оба маршрутизатора анонсируют поддержку этого протокола. 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, включает в себя модификацию протокола 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.  Есть ещё кое-что, что необходимо для функционирования "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 для 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 выбирается автомагически.  Cisco предложила использовать новый, optional transitive, атрибут – BGP Connector, который PE с настроенным multicast VPN должен экспортировать вместе с VPNv4 маршрутами. Этот атрибут состоит из двух частей:   Если 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. Обратите внимание, что интерфейс Loopback0 является источником для туннеля MDT, поэтому на нём должен быть включён PIM, чтобы активировать маршрутизацию multicast. R2 не выделяется ничем особенным: OSPF в качестве протокола маршрутизации, а также LDP для обмена метками. Стоит отметить, что R2 не использует PIM на интерфейсе в сторону R3, а на интерфейсе в сторону R6 не активен LDP. Выходит, что через R6 пролегает путь только multicast-трафика, тогда как R3 является частью MPLS LSP. R2 использует PIM SSM и RPF proxy vector в глобальном VRF. R3 – это ASBR в Inter-AS VPN Option B. Он устанавливает сессии BGP с R1 (PE) и R4 (другой ASBR). В рамках этих сессий активен только VPNv4. Обратите внимание, что next-hop для маршрутов VPNv4 должен быть заменён на свой собственный адрес, чтобы транспортный LSP от PE проходил через R3. Никакая информация о multicast или MDT SAFI на R3 не появляется. Второй ASBR из AS 100, R6, является multicast-only ASBR: он передаёт только multicast-префиксы и MDT SAFI между R1 и R4. MPLS неактивен на этом маршрутизаторе, так как единственная его задача – передача multicast-трафика между AS 100 и AS 200. MSDP в такой схеме не нужен, так как для построения multicast-деревьев применён PIM SSM. Стоит обратить внимание на несколько важных нюансов. Во-первых, 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. Последний неокученный маршрутизатор в схеме – R5. Он является PE в AS 200, настройка которого аналогична конфигурации R1. Он должен поддерживать VPNv4, MDT SAFI и multicast AF, чтобы получить всю необходимую информацию от ASBR. Очевидно, что нужно включить использование RPF Proxy Vector для MDT-дерева VRF RED, а также активировать PIM SSM в глобальном VRF для диапазона адресов по умолчанию. Как можно заметить, в AS 200 нет маршрутизатора, выполняющего роль ядра сети. Эта часть самая простая. Используем show команды, чтобы увидеть, происходит ли в конечном итоге обмен префиксами между PE, а также есть ли связность между ними: Обратите внимание, что для префикса 192.168.5.0/24 значение атрибута next-hop равно 10.0.3.3, а значение атрибута BGP Connector – 200:1:20.0.5.5. Эта информация пригодится впоследствии для проверок RPF, когда пойдёт multicast-трафик. Передача multicast-трафика несколько более сложна. Первым делом нужно убедиться, что дерево MDT построено как от R1 до R5, так и в обратном направлении. Проверим группы PIM MDT на каждом PE: В выводах команд выше обратите внимание на значения 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 указывает для источника 20.0.5.5 значение RPF proxy, равное 10.0.6.6. Обратите внимание, что в таблице маршрутизации присутствует дерево в сторону 10.0.1.1, которое берёт начало от R5. У этого дерева нет proxy, так как дерево уже находится в целевой AS.  Следующие на проверку – R2 и R6, где мы должны найти ту же информацию (помним о том, что именно proxy убирает vector при получении PIM Join): Обратите внимание на такое же значение proxy vector для (20.0.5.5, 232.1.1.1), как и у R1. Как и следовало ожидать, присутствует и противоположно направленное дерево от R5 к R1, которое не использует RPF proxy vector в AS 100. Перейдём к выводу команд с R6. Стоит отметить, что R6 в курсе про два proxy vector, одним из которых является он сам: Выводы команд с R4 похожи на выводы с R6 – так же присутствуют proxy для обоих деревьев multicast:  Наконец, вывод с R5 зеркален тому, что мы видели на R1. Однако в этом случае роли multicast-деревьев поменялись местами: для дерева в сторону R1 установлено значение proxy vector: Таблица BGP на R5 также содержит атрибут BGP Connector для префикса интерфейса Ethernet на R1: Помимо атрибута BGP Connector, нужны маршруты до источников multicast, которые переданы по IPv4 multicast AF. Эта информация должна быть в таблицах BGP как на R1, так и на R5: Настало время проверить связность для multicast. Убедимся, что R1 и R5 видят друг друга как соседей PIM через MDT, а затем запустим multicast ping в сторону группы, которую слушают R1 и R5: На этом проверку тестового стенда можно считать пройденной. В этой статье автор продемонстрировал, как можно использовать расширения 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 VPNMulticast Tunnel DiscoveryPIM RPF VectorMDT SAFIMDT SAFI ConfigurationPIM RPF Proxy Vector Configuration  Системный инженер