Версия 18:15, 15 июля 2018

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

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

Next-generation MVPN

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

В новой модели для сигнализации - BGP, для форвардинга - MPLS. Как и во всех остальных сервисах (L3VPN, L2VPN, VPLS...). [NG MVPN, MBGP Multicast VPN]

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

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

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-роутеру получателя узнавать подробности провайдерского туннеля (чтобы смочь присоединиться к нему).

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

Отправляется 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

Inclusive Trees

Inclusive Tree - это абстракция, в которой мы полагаем, что PE при наличии у него источника потока, будет доставлять трафик от этого источника ко всем PE-получателям. Удобно, если все PE в данном vpn должны получать трафик. Если мультикаст трафик должен доставляться лишь немногим удаленным PE, то этот способ слишком затратен по ресурсам/bandwith/etc... Inclusive tree существует для всего мультикаст-трафика из данного VPN-сайта (для противопоставления есть Selective Tree, которые строятся для каждой группы отдельные).

Signaling

При включении VPN с использованием Inclusive Tree, каждый PE с каждым другим PE устанавливает Point-To-Multipoint LSP (где-то в начале книги было про то, как сделать это вручную. В данном же случае это делается автоматически, ибо работает MP-BGP с family mvpn). Причем не важно где будут источники, где получатели а где вообще ничего - все равно каждый участвующий в этом mvpn'е PE берет и устанавливает по одному p2mp lsp от себя ко всем соседям. Получается, что если какой-либо PE не собирается быть источником, а планирует только получать трафик, то lsp, идущее от него к другим никогда не будет использоваться, но будет висеть и жрать ресурсы. Да, это так. И мы как-то можем на джуниперах отключить ненужное построение p2mp lsp на от конкретных 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 6 роут, он конвертирует его в обычный PIM (S, G) Join и посылает клиентскому DR (Designated Router), таким образом завершая построение мультикаст-дерева.

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

Forwarding

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

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

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).

MVPN Modes

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; }}}}}

Виды 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
> mvpn-mode            MVPN mode of operation
  receiver-site        MVPN instance has sites only with multicast receivers
> route-target         Configure route-targets for MVPN routes
  sender-site          MVPN instance has sites only with multicast sources
> traceoptions         Trace options for BGP-MVPN
  unicast-umh-election  Upstream Multicast Hop election based on unicast route preference

Monitoring

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

Проверка provider-tunnel

show rsvp session
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 тоже используется Dafault 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 политики, где нужно

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

Не знаю насколько я правильно поняла, но: если используем только 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;

@@ Строка 139: / Строка 139: @@
 ** Я понимаю, что рассматривается пример с одним получателем, и можно было бы построить простое p2p-lsp. А ну как кто-то еще пришлет такой же JOIN? Пусть уж лучше сразу будет построено p2mp.
 * Теперь можно срать в LSP пакетами с мультикастом так же, как в прошлый раз (в случае с Inclusive Tree).
-===MVPN Modes===
+==MVPN Modes==
 ==Config==

Глава 12. Multicast VPNs: различия между версиями