Глава 12. Multicast VPNs - История изменений

Наталия Бобкова в 18:00, 15 июля 2021

2021-07-15T18:00:35Z

← Предыдущая		Версия 18:00, 15 июля 2021
Строка 477:		Строка 477:
	+ tunnel-limit 5; - ограничение на кол-во туннелей		+ tunnel-limit 5; - ограничение на кол-во туннелей
	+ group-range 239.0.0.0/24;		+ group-range 239.0.0.0/24;
			=Дополнительная информация=
			*[[MVPN]]
			*[[Глава 2. Label Distribution Protocols (RSVP, LDP)]]
			*[[Traffic engineering]]

Наталия Бобкова в 12:09, 5 июля 2021

2021-07-05T12:09:30Z

← Предыдущая		Версия 12:09, 5 июля 2021
Строка 1:		Строка 1:
			{{#description2:Next-generation MVPN. Типы NLRI для Multicast-VPN. MVPN деревья. Режимы работы MVPN. Sender/Receiver site. Draft-Rosen VPNs. Конфигурация MVPN. Траблшутинг MVPN. Информация для подготовки к экзаменам Juniper.}}
	В целом, предоставления MVPN - это предоставление клиенту возможности пускать свой мультикаст через сеть провайдера [сигнального unicast и датного multicast трафика], дополнительно к l3vpn. В подобных решениях могут быть совершенно разные топологии. Источники и получатели должны быть однозначно на сети клиента. RP можно использовать как на сети клиента, так и на сети провайдера. Для обнаружения RP могут использоваться также разные механизмы. И также можно использовать как SSM, так и ASM. И даже dense или sparse mode. И между PE<>CE могут использоваться разные протоколы [любой вариант l3vpn]. То есть многообразие полнейшее.		В целом, предоставления MVPN - это предоставление клиенту возможности пускать свой мультикаст через сеть провайдера [сигнального unicast и датного multicast трафика], дополнительно к l3vpn. В подобных решениях могут быть совершенно разные топологии. Источники и получатели должны быть однозначно на сети клиента. RP можно использовать как на сети клиента, так и на сети провайдера. Для обнаружения RP могут использоваться также разные механизмы. И также можно использовать как SSM, так и ASM. И даже dense или sparse mode. И между PE<>CE могут использоваться разные протоколы [любой вариант l3vpn]. То есть многообразие полнейшее.

Наталия Бобкова: /* Multicast for Draft-Rosen VPNs */

2019-11-29T13:47:29Z

Multicast for Draft-Rosen VPNs

← Предыдущая		Версия 13:47, 29 ноября 2019
Строка 427:		Строка 427:
	:*'''vrf protocols pim'''		:*'''vrf protocols pim'''
	:*IGP, BGP политики, где нужно		:*IGP, BGP политики, где нужно
			Внутри настройки routing-instance:
	*'''protocols pim interface''' - включить все интерфейсы, участвующие в pim.		*'''protocols pim interface''' - включить все интерфейсы, участвующие в pim.
	*'''protocols pim mode sparse-dense''' - либо глобально, либо для каждого интерфейса.		*'''protocols pim mode sparse-dense''' - либо глобально, либо для каждого интерфейса.
			*'''protocols pim group-address''' - на всех PE должен быть определен один и тот же group-address. Должен быть уникальным в рамках всей сети. [Пример: 239.1.1.1]

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

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

Наталия Бобкова: /* Multicast for Draft-Rosen VPNs */

2019-11-29T13:42:51Z

Multicast for Draft-Rosen VPNs

← Предыдущая		Версия 13:42, 29 ноября 2019
Строка 428:		Строка 428:
	:*IGP, BGP политики, где нужно		:*IGP, BGP политики, где нужно
	*'''protocols pim interface''' - включить все интерфейсы, участвующие в pim.		*'''protocols pim interface''' - включить все интерфейсы, участвующие в pim.
	*'''protocols pim mode sparse''' - либо глобально, либо для каждого интерфейса.		*'''protocols pim mode sparse-dense''' - либо глобально, либо для каждого интерфейса.
	*'''protocols pim version 2'''- либо глобально, либо для каждого интерфейса.		*'''protocols pim version 2'''- либо глобально, либо для каждого интерфейса.
	*'''protocols pim rp local''' - для PE, которые выполняют роль RP. Либо можно использовать любой другой механизм задания RP (bootstrap, auto-rp,...). RP также может использоваться на стороне клиента.		*'''protocols pim rp local''' - для PE, которые выполняют роль RP. Либо можно использовать любой другой механизм задания RP (bootstrap, auto-rp,...). RP также может использоваться на стороне клиента.

Наталия Бобкова: /* Multicast for Draft-Rosen VPNs */

2019-11-29T13:40:15Z

Multicast for Draft-Rosen VPNs

← Предыдущая		Версия 13:40, 29 ноября 2019
Строка 409:		Строка 409:
	MDT-дерева строится 2. Одно для сигналинга [default MDT], второе для форвардинга.		MDT-дерева строится 2. Одно для сигналинга [default MDT], второе для форвардинга.

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

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

Наталия Бобкова: /* Config */

2019-01-12T17:16:01Z

Config

← Предыдущая		Версия 17:16, 12 января 2019
Строка 203:		Строка 203:
	Для * вместо конкретного ip источника можно указать (для запросов (* , G)):		Для * вместо конкретного ip источника можно указать (для запросов (* , G)):
	set routing-instances 1 provider-tunnel selective group 239.0.0.1/32 '''wildcard-source'''		set routing-instances 1 provider-tunnel selective group 239.0.0.1/32 '''wildcard-source'''

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

	==MVPN Modes==		==MVPN Modes==

Наталия Бобкова: /* Trees */

2019-01-12T17:07:39Z

Trees

← Предыдущая		Версия 17:07, 12 января 2019
Строка 106:		Строка 106:
	Дерево (provider-tunnel) нужно для передачи мультикаст трафика. Должно быть построено только он PE, на котором регистрируется мультикаст от C-Source до удаленных PE, где расположены получатели мультикаста.		Дерево (provider-tunnel) нужно для передачи мультикаст трафика. Должно быть построено только он PE, на котором регистрируется мультикаст от C-Source до удаленных PE, где расположены получатели мультикаста.

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

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

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

Наталия Бобкова: /* Selective Tree */

2019-01-12T17:05:52Z

Selective Tree

← Предыдущая		Версия 17:05, 12 января 2019
Строка 187:		Строка 187:
	threshold-rate 100000;		threshold-rate 100000;
	r1> show configuration protocols mpls label-switched-path selective-mcast		r1> show configuration protocols mpls label-switched-path selective-mcast
	template;		'''template;'''
			'''p2mp;'''
	bandwidth 60m;		bandwidth 60m;
	hop-limit 5;		hop-limit 5;
	priority 5 5;		priority 5 5;
	link-protection;		link-protection;
	~~p2mp;~~
			Если нет требования строить какой-то кастомный 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'''

	==MVPN Modes==		==MVPN Modes==

Наталия Бобкова: /* Trees */

2019-01-12T16:58:49Z

Trees

← Предыдущая		Версия 16:58, 12 января 2019
Строка 104:		Строка 104:

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

			Разделяют 2 типа:
	===Inclusive Trees===		===Inclusive Trees===
			Inclusive Tree - PE, при наличии у него мультикаста от источника, будет доставлять трафик от этого источника ко '''всем''' PE-получателям. Удобно, если все PE в данном vpn должны получать трафик.
	Inclusive Tree - ~~это абстракция~~, ~~в которой мы полагаем, что PE~~ при наличии у него источника ~~потока~~, будет доставлять трафик от этого источника ко '''всем''' PE-получателям. Удобно, если все PE в данном vpn должны получать трафик.

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

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

	====Signaling====		====Signaling====

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

Строка 129:		Строка 130:
	'''Взгляд со стороны получателя'''		'''Взгляд со стороны получателя'''

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

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

Наталия Бобкова: /* Type 7. Source Tree Join Route */

2019-01-12T16:28:41Z

Type 7. Source Tree Join Route

← Предыдущая		Версия 16:28, 12 января 2019
Строка 87:		Строка 87:
	И, наконец...		И, наконец...
	===Type 7. Source Tree Join Route===		===Type 7. Source Tree Join Route===
	7 \| 10.255.170.100:1 \| 65000 \| 32 \| 10.12.53.12 \| 32 \| 224.1.2.3		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 \| Mask ~~Source~~ \| ~~Source IP~~ \| ~~Group~~ Mask ~~\| Group~~ \| C-G		Type \| RD of Upstream PE \| Upstream's AS \| C-S Mask \| C-S \| C-G Mask \| C-G

	Отправляется PE-роутером (который сейчас станет получаетелем), получившим PIM-join (S, G) на vrf-интерфейсе (от клиента).		Отправляется PE-роутером (который сейчас станет получаетелем), получившим PIM-join (S, G) на vrf-интерфейсе (от клиента).