MVPN

MVPN - L3VPN, в котором клиенту предоставляется возможность пускать свой мультикаст через сеть провайдера [сигнального unicast и датного multicast трафика], дополнительно к L3VPN. В подобных решениях могут быть совершенно разные топологии. Источники и получатели должны быть однозначно на сети клиента. RP можно использовать как на сети клиента, так и на сети провайдера. Для обнаружения RP могут использоваться также разные механизмы. И также можно использовать как SSM, так и ASM. И даже dense или sparse mode. И между PE<>CE могут использоваться разные протоколы static, ospf, bgp [любой вариант l3vpn]. То есть многообразие полнейшее.

В качестве транспортного протокола на сети провайдера могут выступать и GRE и MPLS.

Next-generation MVPN

В старой модели для сигнализации использовался PIM, для форвардинга - GRE-tunnels. [Multicast for Draft-Rosen VPNs]

В новой модели для сигнализации - BGP, для форвардинга - MPLS. [NG MVPN, MBGP Multicast VPN]

При использовании BGP, как сигнального протокола: ввели 7 MP-BGP NLRI (Oo).

• Provider multicast service interface (PMSI) - туннель для передачи мультикаста.
• Inclusive-PMSI (I-PMSI)

• multidirectional I-PMSI - позволяет всем PE передавать мультикаст всем остальным PE.
• unidirectional I-PMSI - позволяет одному PE передавать мультикаст всем остальным PE.

• Selective-PMSI (S-PMSI) - PE передает мультикаст только тому PE, который отправил запрос на присоединение к forwarding-tree.

В качестве PMSI может быть использован P2MP RSVP. Плюс - для передачи можно использовать обычные методы защиты RSVP LSP.

Выдержка для напоминания: В случае использования P2MP: source PE отправляет одну копию трафика. Копирование трафика происходит на том роутере, на котором происходит дальнейшее разветвление путей передачи трафика (branch point).

MP-BGP для Multicast-VPN

Сейчас тут будет описание предназначений каждого из типов NLRI. Сначала покажется сложным, но надо прочитать, чтобы хоть примерно ориентироваться. Зато потом при чтении раздела Trees все встанет на свои места.

AFI 1/ SAFI 5

Роуты с "правильными" target community помещаются в bgp.mvpn.0 (общая) и instance-name.mvpn.0 (по аналогии с l3vpn используются bgp.l3vpn.0 и instance-name.inet.0)

В рамках этой family (MP-BGP MVPN family) существует еще 7 типов NLRI (далее называемых "Роутами"):

Type 1. Intra-AS Iclusive MVPN Membership Discovery

Отправляется всеми роутерами, участвующими в MVPN.

Если используется I-PMSI, эти роуты определяют куда автоматически строить p2mp lsp.

Эти роуты тэгируются атрибутом "PMSI Tunnel".

  1  |   10.1.1.1:1    | 65412
Type | Sending PE's RD | Sending PE's AS

Type 2. Inter-AS inclusive MVPN Membership Discovery

Используются для поиска участников между PE-роутерами, находящимися в разных AS. В книге на них забивается.

  2  |   10.1.1.1:1    | 65412
Type | Sending PE's RD | Sending PE's AS

Type 3. Selective MVPN Autodiscovery Route

Отправляется PE-маршрутизатором, который, собственно, инициирует S-PMSI

   3 | 10.255.170.100:1| 32       |   192.168.194.2  |    32    |    224.1.2.3     | 10.255.170.100
Type | Sending PE's RD | C-S Mask | C-S using S-PMSI | C-G Mask | C-G using S-PMSI | Sending PE's lo0

пример:

3:172.30.5.1:32767:32:172.17.17.1:32:239.0.0.1:172.30.5.1/240

Type 4. Selective MVPN Autodiscovery Route for Leaf

Отправляется заинтересованным в получении мультикаст-потока PE-роутером в ответ на получение Type 3.

  4 (type)  | <здесь идет этот самый type 3, который мы только что получили. Да, целиком. Длинный.> | <Тут наш lo0 ipaddress>

Немного резюмируем Эти два типа (3, 4, т.е. selective MVPN autodiscovery) помогают строить S-PMSI. Эти роуты анонсируются PE источника мультикаста в ответ на роуты типов 6 и 7 (позже будут), которые, по существу, запрашивают присоединение к мультикаст-дереву (BGP-аналог PIM-JOIN'а). Даже если PE источника узнаёт (из пришедшего роута типа 7), что удаленный PE получателя хочет получать определенный мультикаст-поток, он все равно посылает роут типа 3 как запрос к получателю на присоединение к S-PMSI. Роут типа 3 при этом тэгируется атрибутом PMSI Tunnel, позволяя PE-роутеру получателя узнавать подробности провайдерского туннеля (чтобы смочь присоединиться к нему).

Соответственно, в таблице <vrf-name>.mvpn.0 маршруты появятся только при использовании selective provider tunnel. Пример:

4:3:172.30.5.1:32767:32:172.17.17.1:32:239.0.0.1:172.30.5.1:172.30.5.7/240

Type 5. Source Active Autodiscovery

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

• Rsgister Messages
• MSDP
• Source Active Messages
• Directly Connected Source.

Нашел поток - объяви другим PE.

Type 6. Shared Tree Join Route

Когда PE получает от своего CE запрос на подключение к группе, то есть PIM join вида (*, G), он отправляет этот роут типа 6 другим PE, участвующим в данном MVPN. Ниже формат этого сообщения:

  6  | 10.255.170.100:1  | 65000         | 32        | 10.12.53.12  |    32    | 224.1.2.3
Type | RD of Upstream PE | Upstream's AS | C-RP Mask | C-RP Address | C-G Mask | C-G

И, наконец...

Type 7. Source Tree Join Route

  7  | 10.255.170.100:1  | 65000         | 32       | 10.12.53.12  |    32      | 224.1.2.3
Type | RD of Upstream PE | Upstream's AS | C-S Mask | C-S          | C-G Mask   | C-G

Отправляется PE-роутером (который сейчас станет получаетелем), получившим PIM-join (S, G) на vrf-интерфейсе (от клиента). В чем разница с предыдущим типом 6? Там был (*, G) а здесь (S, G).

То есть, в итоге что получается?

• Если PE находит у себя поток, то отправляет Type 5. Source Active Autodiscovery соседям - пусть знают, что есть такой источник, вещающий в такую-то группу.

• Если PE получил pim-join от CE на подключение к группе, то отправляет другим PE либо Type 6. Shared Tree Join Route если( *,G), либо Type 7. Source Tree Join Route если получил (S, G). И тогда...

• Если PE получил Type 6. Shared Tree Join Route или Type 7. Source Tree Join Route, он понимает, что удаленный PE хочет от него получать трафик определенной группы. Тогда, в ответ генерируется Type 3. Selective MVPN Autodiscovery Route, и идет к PE, приславшему Type [6,7]. И далее...

• Если PE, ранее отправивший Type[6-7], получает Type 3. Selective MVPN Autodiscovery Route, он берет этот Type 3, и отправляет его обратно, только уже в виде Type 4 (вроде, тупо меняя поле "Type").

Trees

Дерево (provider-tunnel) нужно для передачи мультикаст трафика. Должно быть построено только он PE, на котором регистрируется мультикаст от C-Source до удаленных PE, где расположены получатели мультикаста.

Разделяют 2 типа: Inclusive Trees, Selective Trees.

Можно использовать комбинацию, тогда для всего мультикаста будет использоваться Inclusive Trees, а для конкретных групп Selective Trees.

Inclusive Trees

Inclusive Tree - PE, при наличии у него мультикаста от источника, будет доставлять трафик от этого источника ко всем PE-получателям. Удобно, если все PE в данном vpn должны получать трафик.

Если мультикаст трафик должен доставляться лишь немногим удаленным PE, то этот способ слишком затратен по ресурсам/bandwith/etc...

Inclusive tree строится для всего мультикаст-трафика (то есть для всех групп) из данного VPN-сайта (для противопоставления есть Selective Tree, которые строятся: 1 группа = 1 tree).

Signaling

При включении VPN с использованием Inclusive Tree, каждый PE с каждым другим PE устанавливает Point-To-Multipoint LSP (где-то в начале книги было про то, как сделать это вручную. В данном же случае это делается автоматически, ибо работает MP-BGP с family mvpn). Причем не важно где будут источники, где получатели а где вообще ничего - все равно каждый участвующий в этом mvpn'е PE берет и устанавливает по одному p2mp lsp от себя ко всем соседям.

Получается, что если какой-либо PE не собирается быть источником, а планирует только получать трафик, то lsp, идущее от него к другим никогда не будет использоваться, но будет висеть и жрать ресурсы. Да, это так.

Есть способ на джуниперах отключить ненужное построение p2mp lsp от конкретных PE, если знаем, что PE никогда не будет вещать, а будет только получать. Но сути это не меняет.

Взгляд со стороны источника

Представим, что клиент-источник на сайте A (CE-1) использует PIM. Представим так же, что RP для данного PIM-домена настроена внутри VRF-Instance на PE, что является нормальной практикой.

Тогда CE начнет фигачить Register Message (в виде юникаста, до RP, т.е. до VRF в PE). Тогда-то и случится ситуация, что PE узнал о наличии потока из Register Message =) А дальше повторяется алгоритм (см. выше). Т.е этот PE шлет Type 5, объявляя всем другим PE о том, что у него есть источник. Ну и т.д.

Взгляд со стороны получателя

Некий CE, собравшийся получать мультикаст-трафик, шлет обычный igmp join куда положено (например, Фред запустил VLC и подписался на IPTV-канал udp://@242.0.5.5:1234). Допустим, это Source Specific Join, т.е. "(S, G)". PE-роутер получателя конвертирует этот IGMP-join в Source Tree Join Route (Type 7) и посылает к PE-источнику. Когда PE, к которому подключен источник, получает этот Type 7 роут, он конвертирует его в обычный PIM (S, G) Join и посылает клиентскому DR (Designated Router), таким образом завершая построение мультикаст-дерева.

Аналогично работает и с Type 6, то есть когда прилетает (*, G) от CE.

На этом с сигналингом закончили, дальше начинается форвардинг.

Forwarding

• CE-источник посылает обычный мультикаст-пакет в сторону PE.
• PE его принимает, определяет в какую lsp совать, навешивает один mpls label (один!) и посылает в LSP. LSP до получателя имеется ввиду.
• На каком-то из P-роутеров этот пакет копируется и отправляется в два или более интерфейсов к двум или более PE (такова суть p2mp lsp). Если есть 2 получателя.
• Каждый получающий PE видит метку MPLS, снимает ее, сует пакет в нужный VRF, там уже по PIM видит в какой интерфейс направить этот пакет.

Таким образом пакет прошел по нашей сети и отправился клиенту, а клиент доставил его до Фреда. У Фреда появился первый заветный кадр видео в окне его VLC =)

Config

Пример настройки inclusive tree:

r1> show configuration routing-instances spoke-to-hub    
provider-tunnel {
   rsvp-te {
       label-switched-path-template {
           p2mp-mcast;
r1> show configuration protocols mpls label-switched-path p2mp-mcast 
template;
bandwidth 30m;
hop-limit 5;
priority 5 5;
link-protection;
p2mp;

Selective Tree

Отдельное дерево будет построено для каждой из пар Source, Group.

Как работает

• Как только мы все настроили и закоммитили, каждый PE посылает каждому другому PE Type 1, чем заявляет свое участие в mvpn.
  • Type 1 не содержит атрибута PMSI Tunnel, так что никаких p2mp lsp построено не будет до тех пор, пока кто-то не начнет просить поток.
• Допустим кто-то начал вещать. Получивший поток PE отсылает Type 5 Auto Discovery Route удаленным PE. Ну как и в прошлый раз.
• Дальше все как в прошлый раз - дальний PE получает от Фреда igmp join, конвертирует его в Type 7, посылает источническому PE.
• И теперь разница. Получив такой type 7, PE источника не начинает никуда ничего верещать. Ведь LSP-то не установлен. Теперь вступают в игру Type[3-4].
• PE источника (напомню, он сейчас имеет приходящий мультикаст поток, а так же знает, что удаленный PE выразил желание этот поток получать) посылает Type 3. Selective MVPN Autodiscovery Route ко всем PE.
• Только запросивший поток PE отвечает на это своим Type 4. Selective MVPN Autodiscovery Route for Leaf.
• Теперь PE1 строит свою p2mp lsp к тому, от которого пришел Type 4, и шлет PIM JOIN к клиентскому DR.
  • Я понимаю, что рассматривается пример с одним получателем, и можно было бы построить простое p2p-lsp. А ну как кто-то еще пришлет такой же JOIN? Пусть уж лучше сразу будет построено p2mp.
• Теперь можно срать в LSP пакетами с мультикастом так же, как в прошлый раз (в случае с Inclusive Tree).

Config

Пример настройки:

r1> show configuration routing-instances spoke-to-hub    
   selective {
       tunnel-limit 5;
       group 239.0.0.1/32 {
           source 172.31.64.0/21 {
               rsvp-te {
                   label-switched-path-template {
                       selective-mcast;
               threshold-rate 100000;
r1> show configuration protocols mpls label-switched-path selective-mcast 
template; 
p2mp;
bandwidth 60m;
hop-limit 5;
priority 5 5;
link-protection;

Если нет требования строить какой-то кастомный lsp, то можно указать дефолтный template:

set routing-instances 1 provider-tunnel selective group 239.0.0.1/32 source 172.31.64.0/21 rsvp-te label-switched-path-template default-template

При этом не в protocols mpls настраивать дополнительно ничего не нужно.

Для * вместо конкретного ip источника можно указать (для запросов (* , G)):

set routing-instances 1 provider-tunnel selective group 239.0.0.1/32 wildcard-source

Группы можно указывать диапазоном: group 239.0.0.0/24

MVPN Modes

По дефолту MPVN работает в режиме SPT-only (shortest-path tree). В этом режиме активные источники буду изучены с помощью VPN source-active routes. source tree join (C-S, C-G) При получении (C-S, C-G), PE сразу же такой join преобразует в Type7.

Также существует (RPT)-SPT mode. Тут используются shared tree join (С-*,С-G) запросы к RP.

Когда в режиме SPT-only от получателя прийдет (*, C-G) - PE-роутер ищет активный источник для группы. Если такой есть, то PE создает source tree customer multicast route [Type5], и отправляет его к PE с активным источником. На PE receiver приходит (*,G), которое транслируется в Type7 NLRI (S,G). К (S,G) добавляется community no-advertise и маршрут добавляется в таблицу.

Источник определяется MVPN's single-forwarder election. Этот подход позволяет определить одного передатчика для (C-S) [customer-source].

• Если активный unicast route к источнику идет через интерфейс, то этот маршрут используется как upstream mcast hop.
• Если активный unicast route к источнику находится в VPN, MVPN выбирает upstream mcast hop, основываясь на бОльшем IP в составе import community и локального master lo адреса.

Для SPT-only этого подхода достаточно. Для PRT-SPT нужно также добавить некоторые административные ограничения [приоритезацию] для исключения дублирования трафика по SPT и shared tree.

Алгоритм обработки C-join:

• на PE прилетел (C-*, C-G).

user@PE3> show pim join extensive instance vpna 224.1.1.1
Group: 224.1.1.1
   Source: *
   RP: 10.12.53.1

• PE генерирует Type6 и ставит его в <vrf>.mvpn.0. Type6 в качестве source ставит адрес RP.

user@PE3> show route table vpna.mvpn.0 detail | nd 6:10.1.1.1

• RT и RD Type6 парсятся при lookup ip RP в <vrf>.inet.0
• Как только источник начинает вещать, ближайший к нему PE кладет маршрут Type5 в <vrf>.mvpn.0 таблицу.
• Type5, которые кладутся в <vrf>.mvpn.0, по протоколу BGP передаются другим PE.
• Удаленный PE теперь имеет Type5 и Type6 для (C-*, C-G) и теперь готов состряпать из этого Type7. RD для Type7 и Type6 будут одинковыми, если они получены от одного PE.
• Type7 устанавливается в <vrf>.mvpn.0 и передается другим PE. [в случае, если PE получает source tree C-join, то Type7 генерируется и расслылается автоматически и этому join не нужно проходить через предыдущие этапы].

• Если Type7 имеет RT, совпадающий с rt-import на Sender PE, то Sender PE ставит его в <vrf>.mvpn.0
• На Sender PE (который рядом с источником) Type7 транслируется в обычный C-join в рамках VRF. C-join в свою очередь добавляется на receiver PE в C-PIM database. И как я поняла по PIM распространяется на все PE в виде join. То есть в таблице <vrf>.mvpn.0 будут видны одни и те же маршруты, изученные по BGP и по PIM:

PE1> show route table vpna.mvpn.0 detail |  nd 7:10.1.1.1
7:10.1.1.1:1:65000:32:192.168.1.2:32:224.1.1.1/240 (2 entries, 2 announced)
       *PIM    Preference: 105 
              Next hop type: Multicast (IPv4)
               Next-hop reference count: 30
               State: <Active Int>
               Age: 1d 2:19:04
               Task: PIM.vpna
               Announcement bits (2): 0-PIM.vpna 1-mvpn global task
               AS path: I
               Communities: no-advertise target:10.1.1.1:64
         BGP    Preference: 170/-101 
               Next hop type: Indirect
               Next-hop reference count: 4
               Source: 10.1.1.3
               Protocol next hop: 10.1.1.3
               Indirect next hop: 2 no-forward
               State: <Secondary Int Ext>
               Inactive reason: Route Preference
               Local AS: 65000 Peer AS: 65000
               Age: 53:27      Metric2: 1
               Task: BGP_65000.10.1.1.3+179
               Announcement bits (2): 0-PIM.vpna 1-mvpn global task
               AS path: I
               Communities: target:10.1.1.1:64
               Import Accepted
               Localpref: 100
               Router ID: 10.1.1.3
               Primary Routing Table bgp.mvpn.0

• Обычный C-Join на Seder PE обрабатывается как обычный pim join.

SPT-only mode не дает возможности использовать C-RP. Небольшое пояснение: при (*,C-G) запросе, роутер должен узнать об активных источниках через Type5. Type5 может сгенерировать только MVPN PE роутер. Т.о. этот PE должен знать обо всех register messages. Это произойдет только если:

• C-RP размещен на PE в MVPN
• Между PE (в рамках MVPN) и C-RP настроен MSPD.

Если оба этих условия не пригодны для нашей сети, то можно работать с RPT-SPT. Плюсы SPT-only:

- Проще работать с source-tree customer.
- Не нужно предпринимать никаких действия, чтобы не дублировался трафик при переключении с RPT на SPT.
- Проще control plane 
- Проще обслуживание

Настройка:

[edit routing-instances spoke-to-hub protocols mvpn]
+      mvpn-mode {
+          spt-only;

Sender/Receiver site

Каждый site mvpn можно настраивать как Sender или Receiver only. По дефолту site работает в режиме и sender и receiver.

• Sender-site: не присоединяется к туннелям, анонсируемым с других PE
• Receiver-site: не отправляет PMSI атрибуты.

Одновременно нельзя на одном site в конфете указать и sender и receiver.

Config

PE-PE MP-BGP [или PE<>RR] - добавляем inet-mvpn signaling:

[edit protocols bgp group in]
      family inet-mvpn {
          signaling; }
[edit protocols mpls]
   label-switched-path mvpn {
       template;
       no-cspf;
       p2mp;}
[edit routing-instances]
      MVPN {
          instance-type vrf;
          interface ge-0/0/0.10;
          interface lo0.3;
          route-distinguisher 10.200.86.5:0001;
          provider-tunnel {
             rsvp-te {
                 label-switched-path-template {
                     mvpn;}}}
         vrf-target target:1111:0001;
         vrf-table-label;
         protocols {
             bgp {
                 group ext {
                     type external;
                     neighbor 192.168.55.2 {
                         peer-as 65500; }}}
             pim {
                 rp {
                     static {
                         address 15.15.15.2; }}
                 interface all {
                     mode sparse;}}
             mvpn {
                 mvpn-mode {
                     spt-only; }}}}}

Если разбираем пример, где RP на сети провайдера, то на PE с RP - прописываем local RP, на remote PE - тоже нужно прописывать RP static. Без этого не приходят pim join от CE на remote PE.

Виды provider-tunnels:

> ingress-replication  Ingress Replication Tunnel 
> ldp-p2mp             LDP point-to-multipoint LSP for flooding
> mdt                  Data MDT tunnels for PIM MVPN
> pim-asm              PIM-SM provider tunnel
> pim-ssm              PIM-SSM provider tunnel
> rsvp-te              RSVP-TE point-to-multipoint LSP for flooding
> selective            Selective tunnels

Пример использования selective-tunnels:

[edit routing-instances MVPN provider-tunnel]
  selective {
      group 224.7.7.0/24 {
          wildcard-source {
              rsvp-te {
                  label-switched-path-template {
                      mvpn; }}}}}

mvpn параметры внутри vrf:

mvpn-join-load-balance  MVPN Join Load Balancing Algorithm
traceoptions         Trace options for BGP-MVPN
unicast-umh-election  Upstream Multicast Hop election based on unicast route preference
receiver-site        MVPN instance has sites only with multicast receivers
sender-site          MVPN instance has sites only with multicast sources

Если топология для mvpn (например, full mesh) должна быть отличной от топологии для l3vpn (например, hub and spoke).

route-target         Configure route-targets for MVPN routes

mvpn-mode            MVPN mode of operation
  > rpt-spt              MVPN works in multicast RPT and SPT mode
  > spt-only             MVPN works in multicast SPT only mode (default mode)

Monitoring

show pim join instance MVPN extensive
show multicast route extensive instance MVPN
show route table MVPN.mvpn.0

На egress PE:

r7# run show mvpn neighbor inet    
Instance : MVPN
 MVPN Mode : SPT-ONLY
 Neighbor                              I-P-tnl
 172.30.5.1                            RSVP-TE P2MP:172.30.5.1, 25759,172.30.5.1

r7# run show mvpn c-multicast inet           
Instance : MVPN
 MVPN Mode : SPT-ONLY
 C-mcast IPv4 (S:G)               Ptnl                  St
 0.0.0.0/0:239.0.0.1/32      
 172.17.17.1/32:239.0.0.1/32   RSVP-TE P2MP:172.30.5.1, 25759,172.30.5.1         DS
 0.0.0.0/0:239.5.5.1/32      

- - - пояснение:
 0.0.0.0/0:239.0.0.1/32      - Type 6 join (*,G)
 0.0.0.0/0:239.5.5.1/32      - Typ6 6 join (*,G)
 172.17.17.1/32:239.0.0.1/32 - Type 7 (S,G)

Проверка provider-tunnel на ingress PE:

r7# run show rsvp session ingress 
Ingress RSVP: 16 sessions
To              From            State   Rt Style Labelin Labelout LSPname 
172.30.5.7      172.30.5.1      Up       0  1 SE       -   347858 172.30.5.7:172.30.5.1:32767:mvpn:MVPN

show route forwarding-table destination 224.7.7.7 extensive

Multicast for Draft-Rosen VPNs

Draft-rosen 6 - для ASM модели.

Draft-rosen 7 - для SSM модели.

Старый подход, где для сигнализации использовался PIM, для форвардинга - GRE-tunnels [Multipoint GRE (MP-GRE)].

MP-GRE - в отличие от обычного GRE, в качестве адреса назначения - ip multicast group [Пр.: 239.1.2.3]. А адрес источника - обычный unicast ip [зачастую просто адрес lo роутера].

Соответственно для одного VRF на всех PE должен быть определен один и тот же group-address.

Полностью построенное дерево для передачи трафика называется Multicast Distribution Tree [MDT].

MDT-дерева строится 2. Одно для сигналинга [default MDT], второе для форвардинга.

Через default MDT передается весь сигнальный трафик клиента. Более того, до установления Data MDT тоже используется Default MDT [до момента, пока не пришло оповещение, что построен более оптимальный туннель для передачи конкретного мультикаст потока].

Может работать как для ASM, так и для SSM модели.

При использовании ASM [draft-rosen 6] - в конфигурации ip dest для MP-GRE задаем адрес через vpn-group-address 232.0.0.1 ------ Default MDT Address

При использовании SSM [draft-rosen 7] - в конфигурации ip dest для MP-GRE задаем адрес через provider-tunnel pim-ssm group-address 232.0.0.1.

Комбинированный метод ASM + auto-discovery: provider-tunnel pim-asm instead. Описание для понимания: https://forums.juniper.net/t5/Junos/Please-help-confounded-by-Draft-Rosen-6-or-7/m-p/288183#M10101

Рассмотрим пример конфига для ASM.

Обязательно нужно включить в конфигурацию:

• interface lo0.x - создаем новый unit, который запихиваем в

• vrf interfaces
• vrf protocols pim
• IGP, BGP политики, где нужно

Внутри настройки routing-instance:

• protocols pim interface - включить все интерфейсы, участвующие в pim.
• protocols pim mode sparse-dense - либо глобально, либо для каждого интерфейса.
• protocols pim group-address - на всех PE должен быть определен один и тот же group-address. Должен быть уникальным в рамках всей сети. [Пример: 239.1.1.1]

• protocols pim version 2- либо глобально, либо для каждого интерфейса.
• protocols pim rp local - для PE, которые выполняют роль RP. Либо можно использовать любой другой механизм задания RP (bootstrap, auto-rp,...). RP также может использоваться на стороне клиента.
• protocols pim rp static - на остальных PE, CE роутерах. (если используем не static rp, то остальные роутеры настраиваем в соответствие с методом)
• routing-options rib-groups - создание rib-groups. - опять же при необходимости.
• routing-instances instance-name protocols pim rib-group - для указания группы для RPF. [наверное] - при необходимости.

Не знаю насколько я правильно поняла, но: если используем только protocols pim group-address, то этого должно быт достаточно для установления Default MDT.

Если хотим использовать комбинированный вариант ASM + auto-discovery = provider-tunnel pim-asm group-address 239.1.1.1, то в конфиг нужно добавить protocols pim mvpn.

Если используем SSM, то тоже конфигурируем связку: provider-tunnel pim-ssm group-address 239.1.1.1, то в конфиг нужно добавить protocols pim mvpn.

protocols pim mvpn - служит для автоматического обнаружения других PE в рамках VRF.

Пример конфига [ASM, RP на стороне клиента, используем auto-rp]:

[edit routing-instances vrf-ospf protocols pim]
       dense-groups {
           224.0.1.39/32;
           224.0.1.40/32;
       }
       vpn-group-address 239.1.1.1;
       rp {
           auto-rp discovery;
       }
       interface all {
           mode sparse-dense;

MDT

Data MDT строятся для более оптимальной передачи мультикаст трафика.

Используются mt- интерфейсы. Как для default, так и для data MDT.

Пример для ASM-модели

[edit routing-instances vrf-ospf protocols pim]
+      mdt {
+          threshold {
+              group 239.0.0.1/32 {
+                  source 0.0.0.0/0 {
+                      rate 30000;
+              group 239.0.0.2/32 {    - группа
+                  source 0.0.0.0/0 {    - любой источник
+                      rate 30000;          - ограничение скорости
+          tunnel-limit 5;              - ограничение на кол-во туннелей
+          group-range 239.0.0.0/24;