Версия 15:13, 10 февраля 2017

Next-generation MVPN

В старой модели для сигнализации использовался PIM, для форвардинга - GRE-tunnels.

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

При использовании 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).

Config

PE-PE MP-BGP - добавляет 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; }}}}}

Monitoring

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

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