Basics of routing & switching: Multicast

2010, Владимир Литовка (http://doka-ua.blogspot.com/) Switching & Routing – doka.ua – T102

Разработка: Владимир Литовка [email protected] http://doka-ua.blogspot.com/

Basics of Switching & Routing

Этот документ доступен по лицензии Creative Commons «Attribution-NonCommercial-ShareAlike» 3.0 Непортированная

(http://creativecommons.org/licenses/by-nc-sa/3.0/deed.ru)


Multicast R&S

  Основы Milticast   PIM Dense Mode   PIM Sparse Mode

o  Auto-RP o  BSR

  IGMP v2   MVR

  MBGP for Multicast   MSDP

o  Anycast RP   PIM-SSM   IGMP v3   IGMP v2 / SSM interoperability


Multicast Routing & Switching


Что такое Multicast

Источник

Unicast

Источник

Multicast


Преимущества Multicast

0

0.2

0.4

0.6

0.8

Traffic

Mbps

1 20 40 60 80 100 # Clients

Multicast Unicast

  Высокая эффективность o  трафик получают и обрабатывают только те, кто его явно запросил

  Масштабируемость o  объем трафика не растет вместе с абонентами o  нагрузка на устройства не растет вместе с абонентами


Недостатки Multicast

Multicast-трафик передается поверх UDP   негарантированная доставка

при нештатных ситуациях в сети возможны потери пакетов   слабый контроль за использованием ресурсов сети

отсутствие механизмов TCP windowing и “slow-start” могут вызвать перегруженность каналов связи

  дублирование данных   неупорядоченное получение данных

при нештатных ситуациях в сети возможны дублирование или приход пакетов не в той последовательности, в которой они были отправлены источником

Приложения Multicast должны отрабатывать нештатные ситуации самостоятельно


Семейство протоколов Multicast

HDTV

HDTV

AS100

AS101

IGMP

IGMP

  MBGP   MSDP

PIM

IGMP Snooping


Адресация Multicast

Sender

Sender & Receiver

Receiver Receiver

Group 1 & 2 Member

Group 1 Member

Group 2 Member

Non-Group Member

  Каждая multicast-группа идентифицируется Class-D адресом   Для получения данных абонент должен быть участником группы   Данные, посылаемые в группу, будут получены всеми участниками группы   Для посылки данных в группу отправитель не должен быть участником группы   Адрес источника никогда не может быть Class-D адресом


Адресация Multicast (ч.2)

Class D: 224.0.0.0 – 239.255.255.255   Reserved Link-Local Addresses : 224.0.0.0 – 224.0.0.255

Передаются с TTL=1 Пример: 224.0.0.5 – OSPF routers

  Other Reserved Addresses : 224.0.1.0 – 224.0.1.255 Передаются с TTL>1 Пример: 224.0.1.1 – Network Time Protocol

  Global Scope Addresses : o  232.0.0.0 – 232.255.255.255 – Source Specific Multicast o  233.0.0.0 – 233.255.255.255 – Static Global Group Address Assignment

•  AS Number вставляется в два средних октета •  нижний октет используется для распределения между группами •  RFC 2770 и draft-ietf-mboned-glop-addressing-xx.txt

  Administrative Scope Addresses : 239.0.0.0-239.255.255.255 Аналог RFC1918 для Unicast-адресов, зарезервированы для использования в закрытых (private) сетях


Well-known groups

Группа Описание 224.0.0.1 All Hosts 224.0.0.2 All Routers 224.0.0.5 OSPF AllSPFRouters 224.0.0.6 OSPF AllDRouters 224.0.0.9 RIPv2 224.0.0.13 PIMv2 224.0.0.18 VRRP 224.0.0.22 IGMPv3 Routers 224.0.1.39 Cisco AUTO-RP-ANNOUNCE 224.0.1.40 Cisco AUTO-RP-DISCOVERY

Некоторые из назначенных Multicast-групп:

http://www.iana.org/assignments/multicast-addresses/multicast-addresses.xml


В Class-D IP-адресе верхние 4 бита всегда 1110, для идентификации группы остается 28 бит

Блок адресов 01-00-5e делегирован IANA, из них половина (23 бита) 0100.5E-00.0000 – 0100.5E-7F.FFFF распределена для адресации Multicast в Ethernet-сетях

Таким образом, при трансляции IP-адреса в Ethernet-адрес теряются верхние 5 бит адреса и при проектировании сети следует учитывать этот факт (пересечение адресов 32:1).

Например, адреса: 224.10.0.1 (11100000.00001010.00000000.00000001) 225.138.0.1 (11100000.10001010.00000000.00000001)

будут транслироваться в одинаковый MAC-адрес 01-00-5E-0A-00-01.

Адресация Multicast (ч.3) 32 Bits

28 Bits

25 Bits 23 Bits

48 Bits

01-00-5e-7f-00-01

1110

5 Bits Lost

239.255.0.1

http://www.multicast.org.uk/address-tools/


Shortest Path Tree (SPT)

Sender 1

Sender 2

Receiver 1 Receiver 2

  Кратчайший путь (lowest cost) между источником и получателями

  Пересылка трафика осуществляется по двум параметрам – адресу источника (Source) и адресу группы (Group), поэтому описание дерева выглядит следующим образом: (S,G)

  Каждое дерево строится на основе адреса источника и адреса группы, поэтому для каждой пары строится свое дерево


Rendezvous Point Tree (RPT)

Source Tree Shared Tree

Sender 1

Sender 2

Receiver 1 Receiver 2

Rendezvous Point (RP)

  Также известно как Shared Path Tree   В общем дереве multicast-потоки от нескольких источников собираются в единую точку – Rendezvous Point (RP) – из которой далее пересылаются получателям потоков.   Поскольку источники потоков скрыты, то пересылка трафика осуществляется по одному параметру (Группе), вне зависимости от адреса источника и описание дерева выглядит следующим образом: (*,G)   Источник регистрируется на RP (посылкой соответствующего Register Message) и RP регистрируется в SPT к источнику.


Multicast Forwarding

Для пересылки Multicast-трафика используется пара (S,G), а получатель неизвестен

Механизмы управления доставкой трафика:   Reverse Path Forwarding (RPF)

транзитный маршрутизатор пересылает полученный multicast-пакет только в том случае, если источник трафика доступен через интерфейс, с которого данный пакет получен

  TTL Threshold административное ограничение по TTL multicast-пакета

  Administrative Boundary ограничение по разрешенным в заданной части сети multicast-группам


  В таблице Unicast-маршрутизации блок адресов 151.10.0.0/16 маршрутизируется через интерфейс S1.

  Multicast-пакет с адресом узла-отправителя 151.10.7.11, пришедший из интерфейса S0, будет без предупреждения отброшен.

  Multicast-пакет с адресом узла-отправителя 151.10.7.11, пришедший из интерфейса S1, будет переправлен в каждый интерфейс, где находятся абоненты данной multicast-группы.

  Никакие multicast-пакеты никогда не будут отправлены в тот интерфейс, с которого были получены.

Reverse Path Forwarding

S0

S1

S2

E0

S=151.10.7.11

Router#sh ip route [ … ] O IA 150.10.0.0/16 via x.x.x.x, Serial1


  Если маршрут доступен из двух и более источников, выбор основывается на administrative distance каждого источника, с учетом Multicast-расширений

Выбор маршрута для RPF

Таблица, из которой известен источник Administrative Distance

Unicast (Distance of route) iMBGP 200 eMBGP 20 DVMRP 0 Static mroute 0


  TTL Threshold задается на каждом интерфейсе. Значение по-умолчанию – 0 (нет установленного лимита).   У всякого входящего пакета значение TTL уменьшается на единицу. Если результат <= 0, то пакет отбрасывается.   Если получившееся значение TTL >= установленного на исходящем интерфейсе лимита, то пакет форвардится в этот интерфейс.   Если получившееся значение TTL < установленного на исходящем интерфейсе лимита, то пакет отбрасывается.

TTL Threshold

S1

S2 TTL Th = 16

E0 TTL Th = 0

TTL = 24

S0 TTL Th = 64


Administrative Boundary

S0 S1

Administrative Boundary = 239.0.0.0/8

239.x.x.x multicast packets

239.x.x.x multicast packets

  Конфигурируется командой “ip multicast boundary <acl>” на заданном интерфейсе

  Определяет набор multicast-групп, потоки из которых не будут пересекать границу (boundary) ни в одном из направлений


Построение Multicast Distribution Tree в сетях IP


Протоколы построения дерева

  Dense Mode (push model) o  По умолчанию трафик распространяется по всей сети o  Маршрутизаторы, у которых нет получателей multicast-трафика, в явном виде отказываются от этого трафика o  Процесс пересылки и отказа от трафика повторяется периодически o  Протоколы PIM-DM, DVMRP, MOSPF

  Sparse Mode (pull model) o  Маршрутизаторы явно запрашивают multicast-трафик при возникновении активных получателей o  Трафик пересылается только в те фрагменты сети, где есть активные получатели o  Протокол PIM-SM


PIM Dense Mode (PIM-DM)

  Не зависит от протоколов маршрутизации дерево строится на основе таблицы маршрутизации узла и неважно, как она сформирована

  Shortest Path Tree, строится на основе механизма Flood / Prune / Graft

o  multicast-трафик «разливается» по всей сети o  узлы без подписчиков отказываются от трафика o  при появлении подписчиков – заказывают трафик

  Flood / Prune периодически повторяется o  PIM State-Refresh – периодическая посылка Prune Refresh сообщений с ближайшего к источнику узла

  Механизм Assert для избежания дублирования

http://www.faqs.org/rfcs/rfc3973.html


PIM-DM operations


  Информация о состоянии (S, G) создается на каждом маршрутизаторе сети

  После окончания процесса Flood-Prune информация (S, G) все равно остается на каждом маршрутизаторе сети

Source

Multicast Packets Prune Messages

Receiver 1

After “Prune” flow


PIM-DM operations (ч.2)


Receiver 1

Receiver 2

Graft Message

Source


  При детектировании петли граничные маршрутизаторы шлют в сегмент сообщение Assert   Assert содержит metric и administrative distance до источника

o  побеждает (Assert Winner) лучший путь до источника o  или – наибольший (highest) IP-address o  прочие узлы (Assert Losers) прекращают посылки

Dec 9 00:40:53: PIM(0): Send v2 Assert on FastEthernet0/1 for 239.1.1.1, source 100.2.0.2, metric [110/20] Dec 9 00:40:53: PIM(0): Assert metric to source 100.2.0.2 is [110/20] Dec 9 00:40:53: PIM(0): Received v2 Assert on FastEthernet0/1 from 1.1.1.1 Dec 9 00:40:53: PIM(0): Assert metric to source 100.2.0.2 is [0/0] Dec 9 00:40:53: PIM(0): We lose, our metric [110/20] Dec 9 00:40:53: PIM(0): Prune FastEthernet0/1/239.1.1.1 from (100.2.0.2/32, 239.1.1.1)

PIM-DM Assert

Assert Message


  При детектировании петли граничные маршрутизаторы шлют в сегмент сообщение Assert   Assert содержит metric и administrative distance до источника

o  побеждает (Assert Winner) лучший путь до источника o  или – наибольший (highest) IP-address o  прочие узлы (Assert Losers) прекращают посылки

Dec 9 00:40:53: PIM(0): Send v2 Assert on FastEthernet0/1 for 239.1.1.1, source 100.2.0.2, metric [110/20] Dec 9 00:40:53: PIM(0): Assert metric to source 100.2.0.2 is [110/20] Dec 9 00:40:53: PIM(0): Received v2 Assert on FastEthernet0/1 from 1.1.1.1 Dec 9 00:40:53: PIM(0): Assert metric to source 100.2.0.2 is [0/0] Dec 9 00:40:53: PIM(0): We lose, our metric [110/20] Dec 9 00:40:53: PIM(0): Prune FastEthernet0/1/239.1.1.1 from (100.2.0.2/32, 239.1.1.1)

PIM-DM Assert

Assert Message

В случае выхода из строя Assert Winner подача трафика в сегмент прекращается до следующей

итерации Assert


PIM-DM State Refresh


Receiver 1

Receiver 2 Source

Next-Hop to source PIM-node

State-Refresh message reset Prune timer

Сообщение State Refresh включает метрику до источника. Таким образом, исчезает надобность в периодическом re-Assert


Прочие Dense-mode протоколы

  DVMRP o  собственная таблица маршрутизации (Truncated Broadcast Tree, TBT) o  RIP-like протокол формирования таблицы

•  максимальное количество хопов – 32 •  медленная сходимость

  Multicast OSPF (MOSPF)

o  требует OSPF в сети o  расчет дерева для каждой пары (S, G)

  Общие недостатки Dense-mode протоколов:

o  не поддерживается Shared Tree o  больший объем маршрутной информации ( F[S*G] ) o  периодические всплески трафика (Flood / Prune)


PIM Sparse Mode (PIM-SM)

  Не зависит от протоколов маршрутизации дерево строится на основе таблицы маршрутизации узла и неважно, как она сформирована

  Передача трафика по явному запросу (Pull Mode)

  Понятие Rendezvous Point (RP) – точка сбора трафика от источников для передачи получателям:

o  источник регистрируется на RP, между источниками и RP – Shortest Path Tree (SPT)

o  получатели регистрируются на RP, между получателями и RP – Rendezvous Point Tree (RPT)

  Возможность резервирования RP   Возможность переключения на SPT непосредственно между получателем и источником


Rendezvous Point

NHS

PIM-SM operations

Receiver 1

Source

Register (S,G) Register-Stop

1

2

3

4

4

5 5

6

1.  При появлении трафика ближайший к источнику (next-hop to source, NHS) PIM-узел (2) регистрируется на RP

[ … сеть ждет первого получателя …]

3.  IGMP Join (*, G) 4.  PIM Join (*, G) в сторону RP 5.  PIM Join (S, G) в сторону NHS 6.  Построенное дерево:

o  SPT между источником и RP o  RPT между RP и получателем


PIM Join/Prune Messages

  Multicast Source Address o  адрес источника multicast-потока o  если установлен флаг WC, то – адрес Rendezvous Point

  Multicast Group Address

  WC-bit (Wildcard flag) o  индикатор (*,G)

  RP-bit (RP Tree flag) o  запрос должен форвардиться вверх по RPT в направлении Rendezvous Point o  используется для отказа от трафика RPT при переключении на SPT


NHS

PIM-SM operations (ч.2)

Receiver 1

Source

Rendezvous Point

D0#sh ip mroute IP Multicast Routing Table Flags: S - Sparse, C - Connected, [ … ] (*, 239.1.1.1), 00:00:02/00:02:59, RP 2.2.0.6, flags: SC Incoming interface: POS3/0, RPF nbr 2.2.0.6 Outgoing interface list: FastEthernet0/0, Forward/Sparse, 00:00:02/00:02:59

Z0#sh ip mroute IP Multicast Routing Table Flags: T - SPT-bit set [ … ] (*, 239.1.1.1), 00:04:41/stopped, RP 2.2.0.6, flags: S Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: POS3/0, Forward/Sparse, 00:04:41/00:02:43 (100.2.0.2, 239.1.1.1), 00:00:11/00:02:59, flags: T Incoming interface: POS2/0, RPF nbr 2.2.0.2 Outgoing interface list: POS3/0, Forward/Sparse, 00:00:11/00:02:48

B0#sh ip mroute IP Multicast Routing Table Flags: P - Pruned, F - Register flag, [ … ] (*, 239.1.1.1), 00:09:42/stopped, RP 2.2.0.6, flags: SPF Incoming interface: POS2/0, RPF nbr 2.2.0.6 Outgoing interface list: Null (100.2.0.2, 239.1.1.1), 00:09:42/00:02:14, flags: FT Incoming interface: FastEthernet0/0, RPF nbr 0.0.0.0 Outgoing interface list: POS2/0, Forward/Sparse, 00:09:42/00:02:38


PIM flags

S Sparse Mode Группа работает в режиме Sparse

D Dense Mode Группа работает в режиме Dense

C Connected Участники группы непосредственно подключены

L Local Узел сам по себе является участником группы

P Pruned Outgoing Interface List пуст

T SPT flag Соответствует записям (S, G)

J Join SPT для (*, G)

Превышен порог переключения на SPT. Следующий пакет, пришедший по (*,G) вызовет переключение на (S,G)

J Join SPT для (S, G)

Было переключение с (*,G) на (S,G). При трафике ниже порога произойдет возврат на (*,G)

F Register flag По этой записи генерируются Register-* сообщения.

R RP flag on (S, G) RP-bit flag


NHS

NHR

PIM-SM switchover

Receiver 1

Source Rendezvous

Point

 Next-Hop to Receiver (NHR) может переключиться на SPT при o  обнаружении источника o  и превышении порога трафика в RPT

NOTE: значение порога по умолчанию – 0

 NHR шлет PIM Join (S, G) в сторону NHS

Join (S,G)


NHS

NHR

PIM-SM switchover (ч.2)

Receiver 1

Source Rendezvous

Point

При построении SPT и получении трафика в нем:

 NHR шлет PIM Prune (*, G) в сторону RP o  если RPT не нужен – исчезает

 RP шлет PIM Prune (S, G) в сторону NHS o  если SPT не нужен - исчезает

Prune (S,G)

Prune (*,G)


NHS

NHR

PIM-SM switchover (ч.3)

Receiver 1

Source Rendezvous

Point

После переключения c RPT на SPT, узел “Rendezvous Point” продолжает функционировать и для обслуживания новых подключений


  Если в сегменте более одного PIM-узла, то происходит выбор одного из них на роль Designated

  Designated Router – единственный в сегменте, который шлет PIM Join / Prune для этого сегмента   Побеждает PIM-узел (Designated Router) с

o  наибольшим приоритетом o  или – наибольшим (highest) IP-адресом

  Если Designated Router выходит из строя, то по истечении timeout происходят новые выборы DR

o  до выборов нового DR трафик в сегмент не поступает

Designated Router Election

PIM Hello


Идентификация Rendezvous Point в сети


Идентификация RP в сети

  Статическая o  ip pim rp-address … o  … на каждом PIM-узле o  все недостатки статической конфигурации

  Auto-RP o  Cisco Proprietary o  поддерживает PIM v1/v2 o  резервирование RP o  требует Dense Mode для используемых групп

  Bootstrap Router (BSR)

o  стандартный механизм o  резервирование PR и балансировка нагрузки o  только PIM v2 o  использует 224.0.0.13 (All-PIM-Routers) для работы


Auto-RP operations

  Candidate-RP (C-RP) o  список обслуживаемых групп определяется конфигурацией

o  RP-Announcements в группу 224.0.1.39 (Cisco Announce) с соответствием RP / Group List

  Настройка C-RP

ip pim send-rp-announce <interface> scope <ttl> group-list ? <1-99> Access-list reference for multicast groups WORD IP Named Standard Access list

Правило здравого смысла: используйте Loopback для идентификации C-RP


Auto-RP operations (ч.2)

  Mapping Agent (MA) o  подписан на группу «Cisco Announce» o  выбирает RP для каждого списка групп

победитель – Candidate-RP с highest IP address o  анонсирует финальный результат в группу 224.0.1.40 (Cisco Discovery) o  все PIM-узлы подписаны на «Cisco Discovery»

  Настройка MA ip pim send-rp-discovery <interface> scope <ttl> ip pim rp-announce-filter rp-list <acl> group-list <acl>

Правило здравого смысла: используйте Loopback для идентификации MA


Auto-RP Dense Mode

  Проблема курицы и яйца   Группы «Cisco Announce» и «Cisco Discovery» требуют Dense Mode   Два способа:

o  Глобальная конфигурация: Z0(config)#ip pim autorp listener

o  Конфигурация на каждом, участвующем в PIM, интерфейсе: Z0(config-if)#ip pim sparse-dense-mode


BSR Operations

  Candidate-RP

o  Список обслуживаемых групп определяется конфигурацией o  C-RP-Advertisement – выбранному BSR, unicast-сообщением

выбранный BSR анонсируется через группу «All-PIM-Routers» (224.0.0.13)

o  Настройка C-RP

ip pim rp-candidate <interface> ? group-list group-list (список обслуживаемых групп) interval RP candidate advertisement interval (TTL) priority RP candidate priority


BSR Operations (ч.2)

  Candidate-BSR (C-BSR) o  содержит полный список C-RP’s в домене o  рассылает список C-RP’s в группу «All-PIM-Routers» (224.0.0.13) o  все PIM-узлы самостоятельно выбирают RP для списка группа

поскольку алгоритм выбора строго определен, то все узлы получают в результате расчета одинаковый результат

o  использование механизма хэширования для балансировки нагрузки между RP’s


BSR Operations (ч.3)

  Настройка C-BSR

ip pim bsr-candidate <interface> <hash_mask_len> <priority> где:

o  Hash Mask Length определяет количество последовательных групп, которые будут отображаться на RP при балансировке, напр.

32 – hash_mask_len == 2бита == 4 группы

o  Priority определяет приоритет C-BSR при выборах. Чем выше значение – тем выше приоритет

при одинаковом приоритете – higher IP address

  Граница домена для сообщений BSR

Router(config-if)#ip pim bsr-border


PIM-SM: выводы   Оптимальное использование ресурсов сети:

o  простой эффективный алгоритм построения дерева o  использование существующей unicast routing table o  возможность переключения от RPT к SPT

  Механизмы резервирования Rendezvous Points o  регистрация в сети новых источников и их доступность для получателей не будут прерываться

  Основа для PIM-SSM   Основа для Inter-Domain Multicast Routing

o  При использовании с MBGP, MSDP

Multicast-сети практически любой сложности могут быть построены с использованием

PIM-SM


Построение Multicast Distribution Tree в сетях Ethernet


Internet Group Messaging Protocol

С помощью протокола Internet Group Management Protocol (IGMP) абонентские устройства (компьютер,

Set-Top-Box (STB) и другие) сообщают о своем желании подключиться к multicast-группе, которая

распространяется по IP-сети   RFC 1112 описывает первую (устаревшую) версию   RFC 2236 описывает IGMP v2 – наиболее широко распространенная версия   RFC 3376 описывает IGMP v3

TTL = 1 IGMP не передается за пределы сегмента


IGMP v2: заголовок

  Type: 0x11 = Group Membership Query 0x12 = Version 1 Membership Report 0x16 = Version 2 Membership Report 0x17 = Leave Group

  Maximum Response Time максимальное время, которое дается абонентским устройствам для ответ на запрос, в 1/10 secs. Default: 10 секунд

  Group Address: Multicast Group Address (0.0.0.0 for General Queries)

Max. Resp. Time Checksum

Group Address

Type

31 15 7


IGMP v2 запросы

Типы IGMP v2 запросов:

o  Join Group Membership Query c адресом multicast-группы IP dstaddr: 224.0.0.2 (All Routers)

o  Leave Leave Group с адресом multicast-группы IP dstaddr: 224.0.0.2 (All Routers)

o  General Query (v1 Membership Query) IP dstaddr: 224.0.0.1 (All Hosts) Ответ – Membership Report / group address

o  Group Specific Query (v2 Membership Query) IP dstaddr: адрес запрашиваемой группы Ответ – Membership Report / group address


IGMP v2

  Дополнительные механизмы o  Querier Election Mechanism

  IGMP Querier – выбранный узел, единственный опрашивающий сегмент

•  аналог PIM DR Election •  используется IGMP General Query •  побеждает минимальный IP-адрес

  при выходе из строя IGMP Querier – новые выборы •  IGMP Querier Timeout = 2x Query Interval (250 сек)

o  Response Suppression Mechanism в ответ на запросы отвечает только один хост (первый по случайному таймеру, в интервале до Maximum Response Time)


IGMP v2 обмен сообщениями

1.1.1.1

H2 H3

1.1.1.10 1.1.1.11 1.1.1.12

H2

Leave to 224.0.0.2

239.1.1.1

#1

  IGMP Querier посылает Group Specific Query

Group Specific Query to 239.1.1.1

#2

  Один из оставшихся участников группы шлет “Group Specific Membership”

Report to 239.1.1.1

239.1.1.1

#3

  Группа остается активной до тех пор, пока будут приходить ответы от активных хостов

  H2 отключается от группы и посылает сообщение Leave.

H1


Multicast VLAN Registration

SDTV

Multicast VLAN

Data VLAN

http://www.cisco.com/en/US/docs/switches/metro/me3400e/software/release/12.2_55_se/configuration/guide/swigmp.html

IGMP Join / Leave

SDTV

Два варианта поддержки MVR:

  MVR on Access Port   MVR on Trunk Port (поддерживается на некоторых моделях)


Interdomain Multicast Routing


Multiprotocol BGP extensions

AS5

AS1 AS2

AS4 No multicast

AS3

  Кратчайший путь для Unicast-трафика (AS3 – AS4 – AS5) не работает для Multicast-трафика   Нужна отдельная таблица маршрутизации для Multicast   Multiprotocol BGP extensions

PIM Join

Multicast Stream

PIM Join


MBGP for Multicast   Различные идентификаторы для различных типов префиксов:

o  AFI (Address Family Information) 1 для IPv4 / 2 для IPv6

o  SubAFI (Subsequent AFI) 1 (Unicast) / 2 (Multicast) / 3 (Unicast & Multicast)

  Multicast-префиксы не размещаются в таблице маршрутизации

Security tip: если разместить источники в RFC1918-адресах и распространять их через MBGP, то доступа к ним из Unicast-пространства не будет

  Не является заменой протоколу PIM – не передает и не поддерживает состояние multicast distribution tree   PIM при построении дерева использует маршруты в следующем порядке: 1/Static, 2/MBGP, 3/Unicast



MBGP for Multicast

X1

router bgp 101 no bgp default ipv4-unicast bgp log-neighbor-changes neighbor “X0” remote-as 100 neighbor “Z0” remote-as 100 ! address-family ipv4 no synchronization network 101.0.0.0 neighbor “X0” activate neighbor “X0” next-hop-self no auto-summary exit-address-family ! address-family ipv4 multicast neighbor “Z0” activate neighbor “Z0” next-hop-self no auto-summary exit-address-family

router bgp 100 no bgp default ipv4-unicast bgp log-neighbor-changes neighbor “X0” remote-as 100 neighbor “X0” update-source Loopback0 neighbor “X1” remote-as 101 ! address-family ipv4 no synchronization network 100.0.0.0 neighbor “X0” activate no auto-summary exit-address-family ! address-family ipv4 multicast network 100.2.0.0 mask 255.255.0.0 neighbor “X1” activate neighbor “X1” next-hop-self no auto-summary exit-address-family

router bgp 100 no synchronization bgp log-neighbor-changes network 100.0.0.0 network 192.168.0.0 neighbor “Z0” remote-as 100 neighbor “Z0” update-source Loopback0 neighbor “X1” remote-as 101 neighbor “X1” next-hop-self neighbor “X1” default-originate no auto-summary

X0

Z0

Multicast link

AS100

AS101

http://www.cisco.com/en/US/docs/ios/12_2/ip/configuration/guide/1cfmbgp.html


Multicast Source Discovery Protocol

http://www.cisco.com/en/US/docs/ios/12_2/ip/configuration/guide/1cfmsdp.html

  RFC 3618   Работает только с PIM-SM

o RP осведомлены обо всех источниках в своем домене  Источники регистрируются на RP посредством “PIM

Register”  RP обмениваются информацией об источниках посредством сообщений MSDP SA (Source Active)

o RP осведомлены обо всех получателях в своем домене  Получатели подключаются к RP посредством Join (*, G)  RP подключаются к источникам в других доменах посредством Join (S, G)


MSDP в действии

AS5 RP

AS3 RP

AS2 RP

AS1 RP AS4

RP

( 100.2.0.2, 239.1.1.1 ) MSDP SA

(S, G)

Register (S, G)

SA: Source Active


MSDP в действии (ч.2)

AS5 RP

AS3 RP

AS2 RP

AS1 RP AS4

RP

( 100.2.0.2, 239.1.1.1 )

Join (*,G)

Join (S,G)

Конечный узел (ближайший к получателю) может выполнить

переключение на SPT, отключаясь от своего RP (в примере – от RP-AS5)


Anycast RP

  Резервирование RP внутри одного домена o  основано на MSDP

  RFC 3446   Концепция в общем:

o  Внутри одного домена размещается несколько RP с одинаковым IP-адресом o  Источники и получатели пользуются ближайшим (в соответствии с unicast-маршрутизацией) RP

  балансировка нагрузки между несколькими RP

o  Для обмена информацией между RP об активных источниках используется MSDP


Anycast RP в действии

MSDP

Rec Rec Rec Rec

Src1 Src2

SA (src1) SA (src2) A

RP1

10.1.1.1 B

RP2

10.1.1.1


Anycast RP failover

Rec Rec Rec Rec

Src1 Src2

A

RP1

10.1.1.1 B

RP2

10.1.1.1


Anycast RP: конфигурация

ip pim rp-address 10.0.0.1 ip pim rp-address 10.0.0.1

Interface loopback 0 ip address 10.0.0.1 255.255.255.255 Interface loopback 1 ip address 10.0.0.2 255.255.255.255 ! ip msdp peer 10.0.0.3 connect-source loopback 1 ip msdp originator-id loopback 1

Interface loopback 0 ip address 10.0.0.1 255.255.255.255 Interface loopback 1 ip address 10.0.0.3 255.255.255.255 ! ip msdp peer 10.0.0.2 connect-source loopback 1 ip msdp originator-id loopback 1

MSDP B

RP2

A

RP1

C D


Source Specific Multicast IGMP v3


Source Specific Multicast

  Зачем протоколу PIM-SM требуется Shared Tree / Rendezvous Point?

o  Для того, чтобы узнавать о появлении новых источников

  А что если источник известен заранее? o  Абонентские устройства должны слать запрос в виде (S, G) для подключения к SPT o  Shared Tree / RP больше не нужен o  Различные источники могут использовать одинаковые группы и никак не мешать друг другу

  Source Specific Multicast (SSM) o  RFC 3569


Directory Server

NHR

2

SSM в действии

Receiver

Source

1

3 4

1. Получатель делает запрос к серверу-каталогу

2. … и посылает IGMP (S,G) Join 3. NHR формирует PIM (S,G) Join 4. По выстроенному SPT начинает передаваться поток


Модель Anycast Source

Source “A” 10.10.10.10

Source “B” 10.10.10.10

Анонсы IGP

  В сети присутствует два (и более) одновременно работающих источника вещания с одинаковыми IP-адресами   Получатель подключается к ближайшему (с точки зрения IGP) источнику   Источник, пока активен, анонсирует себя посредством IGP (например, RIPv2)   Преимущества

o  Не нужен MSDP (как в случае с Anycast-RP) o  Балансирование нагрузки o  Резервирование


Преимущества SSM

  Решает проблему распределения адресов o  потоки идентифицируются парой (S, G), а не только группой o  операторы могут использовать одни и те же группы, поскольку пара (S, G) уникальна

  Позволяет избегать атак: o  трафик от неизвестных источников не расходует емкость сети o  трафик от неизвестных источников не попадает на абонентские устройства поскольку источники не зарегистрированы в каталоге


IGMP v3

  IGMP v2 не позволяет явно задать источник   IGMP v3 (RFC 3376)

o  добавлены списки Include / Exclude Source явно определяющие список источников

o  другой Application Programming Interface (API) приложения / операционные системы должны быть расширены поддержкой IGMP v3

o  IGMP v3 Snooping отличается от IGMP v2 Snooping

необходима поддержка в коммутаторах доступа

o  Новая группа 224.0.0.22 (IGMPv3 Routers) o  Исчез механизм Report Suppression

http://alor.antifork.org/talks/IGMP-v3.ppt


IGMP v3 “Membership Report”   Добавился запрос “IGMPv3 Membership Report” (0x22):

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 0x22 | Reserved | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Number of Group Records (M) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . Group Record [1] . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . | . . . | . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . Group Record [M] . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


IGMP v3 “Group Record” +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Record Type | Aux Data Len | Number of Sources (N) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Multicast Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Address [1] | +- -+ . . . . . . +- -+ | Source Address [N] | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . Auxiliary Data . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Record Types (RFC 3376, 4.2.12 clause):

1 / MODE_IS_INCLUDE 2 / MODE_IS_EXCLUDE

3 / CHANGE_TO_INCLUDE_MODE 4 / CHANGE_TO_EXCLUDE_MODE

5 / ALLOW_NEW_SOURCES 6 / BLOCK_OLD_SOURCES


IGMP v3 operations

  Сообщения «Membership Report» отсылаются на destination IP-address 224.0.0.22 (IGMPv3 Routers)   Отвечают все хосты (no Report Suppression)

o  задержка ответа – случайное значение в интервале до Maximum Response Time o  если несколько запросов – у каждого своя задержка o  хост может давать комбинированный ответ с учетом ранее сформированные и задержанных сообщений

  Back compatibility o  маршрутизаторы, поддерживающие IGMPv3, должны поддерживать также IGMP v1/v2


Поддержка IGMPv3

  Операционные системы o  Windows XP o  Linux kernel 2.5 o  FreeBSD 8.0 o  Solaris 10   Коммутаторы (IGMP v3 Snooping)

o  Cisco Catalyst o  Juniper o  Alcatel o  Huawei o  Zyxel o  D-Link o  3Com o  Edge-Core


IGMPv2 / SSM interoperability

  Если абонентская сторона не поддерживает IGMP v3, то необходима трансляция IGMP v2 в PIM (S,G) Join   Доступные механизмы:

o  URL Rendezvous Protocol o  если приложение стартует из браузера

o  IGMPv3 Lite o  если приложение знает про IGMPv3, а ОС - нет

o  SSM Mapping o  если ни приложение, ни ОС не знают про IGMPv3

  Общая идея механизмов – сформировать Join (S,G) дополнительно к IGMP v2, предоставив маршрутизатору способы для генерации пары (S,G)


URL Rendezvous Protocol (URD)

  В HTML-документе присутствует две ссылки:

<FRAME SRC=“http://sessions.broadcast.com/sports.sdp” NAME=”Frame to start receiver app“>

<FRAME SRC=“http://www.broadcast.com:465/urd-helper? group=232.3.4.5&source=192.44.81.5” NAME=”URD URL“>

  Первая ссылка – штатный запрос о подключении к потоку на медиа-сервере, который вернет тип потока и параметры подключения к нему:

GET /sports.sdp HTTP/1.0 … Content-type: application/x-sdp … i=Sports Channel c=232.3.4.5

http://www.cisco.com/en/US/docs/ios/12_1t/12_1t5/feature/guide/dtssm5t.html


URL Rendezvous Protocol (ч.2)

Вторая ссылка – специальным образом сформированный запрос к порту 465, который будет обработан первым-же маршрутизатором:

IGMPv2

URD 101.2.0.1

(S,G) Join

Я понимаю, что это за запрос и запоминаю, что нужно подключиться к группе 239.1.1.1 на

источнике 101.2.0.1 как только (если еще нет) я получу с этого интерфейса IGMP v2 Membership

Report для группы 239.1.1.1


IGMPv3 Lite

  Применяется в том случае, если приложение понимает IGMPv3, а операционная система – нет

  Используется HSIL (Host Side IGMP Library) – API к IGMPv3Lite Daemon, работающему в операционной системе

http://www.cisco.com/en/US/docs/ios/12_1t/12_1t5/feature/guide/dtssm5t.html


IGMPv3 Lite в действии

IP SSM application

IP SSM API HSIL

IGMPv3Lite Daemon

Host Operation System

IGMPv3 Lite- aware Router

(S,G) Join

(*,G) Join

IGMPv2 Membership Report

UDP 465 Membership

Report INCLUDE

(S,G)


SSM Mapping

DNS Server

IGMPv2 join 232.1.2.3

Set Top Box (STB)

PIM (S,G) join

Source 172.23.20.70

Запрос к DNS

Формат записи в DNS: 3.2.1.232.ssm.cisco.com IN A 172.23.20.70

1

2 3

http://www.cisco.com/en/US/docs/ios/ipmulti/configuration/guide/imc_ssm_mapping.html


Топология лаборатории

B0

D0

X0 Z0

X1

A1

HDTV

HDTV

LO5

LO3

AS100

AS101

100.2.0.1/24 -> 2

.2 <= 1.1.1.0/24 => .1

100.2.1.1/24 -> 2

0.4

0.2

0.5 0.6

1.2

1.1

101.0.0.5/30 -> 6 101.0.0.1/30 -> 2

192.168.0.2/24 -> 1

101.2.0.1/24 -> 2

1.3 B1

2

1 3

1

4

2

3

1

4

HDTVLO1 LO4


End of 4th Day

Happy configuring!

Basics of routing & switching: Multicast

Technology

Transcript of Basics of routing & switching: Multicast