Глава 12. Multicast VPNs
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.
Когда 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; }}}}}
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
Старый подход, где для сигнализации использовался PIM, для форвардинга - GRE-tunnels.
Может работать как для ASM, так и для SSM модели. Рассмотрим пример конфига для 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, то остальные роутеры настроившем в соответствие с методом)
- group-address - на всех PE должен быть определен один и тот же group-address. [Например: 239.1.1.1]
- routing-instances instance-name protocols pim rib-group - для указания группы для RPF. [наверное] - при необходимости.
- routing-options rib-groups - создание rib-groups. - опять же при необходимости.
© Наталия Бобкова 2014—2022