Basics of routing & switching: Multicast

Basics of
Switching & Routing

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

Этот документ доступен по лицензии Creative Commons
«Attribution-NonCommercial-ShareAlike» 3.0 Непортированная
(http://creativecommons.org/licenses/by-nc-sa/3.0/deed.ru)

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

Multicast R&S
  Основы Milticast
  PIM Dense Mode
  PIM Sparse Mode
o  Auto-RP
o  BSR
  IGMP v2   MBGP for Multicast
  MVR   MSDP
o  Anycast RP
  PIM-SSM
  IGMP v3
  IGMP v2 / SSM interoperability


Multicast
Routing &
Switching


Что такое Multicast

Источник

Unicast

Источник

Multicast


Преимущества Multicast
  Высокая эффективность
o  трафик получают и обрабатывают только те, кто его явно
запросил
  Масштабируемость
o  объем трафика не растет вместе с абонентами
o  нагрузка на устройства не растет вместе с абонентами

0.8

0.6
Traffic Multicast
0.4
Mbps Unicast
0.2

0
1 20 40 60 80 100
# Clients


Недостатки Multicast
Multicast-трафик передается поверх UDP
  негарантированная доставка
при нештатных ситуациях в сети возможны потери пакетов
  слабый контроль за использованием ресурсов сети
отсутствие механизмов TCP windowing и “slow-start” могут вызвать
перегруженность каналов связи
  дублирование данных
  неупорядоченное получение данных
при нештатных ситуациях в сети возможны дублирование или приход
пакетов не в той последовательности, в которой они были
отправлены источником

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

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

IGMP HDTV

AS101
PIM

  MBGP
  MSDP IGMP
Snooping

AS100 HDTV
IGMP


Адресация Multicast
Sender & Receiver
  Каждая multicast-группа
идентифицируется Group 2 Member
Class-D адресом Sender
  Для получения данных
абонент должен быть
участником группы Non-Group
Member
  Данные, посылаемые в
группу, будут получены всеми
участниками группы
  Для посылки данных в группу
отправитель не должен быть Group 1
Group
1&2
участником группы Member Member
  Адрес источника никогда не Receiver Receiver
может быть 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
Некоторые из назначенных Multicast-групп:
Группа Описание
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

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


Адресация Multicast (ч.3)
32 Bits
В Class-D IP-адресе верхние 4 бита всегда
1110, для идентификации группы остается 1110
28 Bits

28 бит
Блок адресов 01-00-5e делегирован
239.255.0.1
5 Bits
IANA, из них половина (23 бита) Lost

0100.5E-00.0000 – 0100.5E-7F.FFFF
распределена для адресации Multicast
в Ethernet-сетях 01-00-5e-7f-00-01
25 Bits 23 Bits
Таким образом, при трансляции
48 Bits
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.
http://www.multicast.org.uk/address-tools/


Shortest Path Tree (SPT)
Sender 2

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

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

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


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


Multicast Forwarding

Для пересылки Multicast-трафика используется
пара (S,G), а получатель неизвестен
Механизмы управления доставкой трафика:
  Reverse Path Forwarding (RPF)
транзитный маршрутизатор пересылает полученный multicast-пакет
только в том случае, если источник трафика доступен через
интерфейс, с которого данный пакет получен
  TTL Threshold
административное ограничение по TTL multicast-пакета
  Administrative Boundary
ограничение по разрешенным в заданной части сети multicast-группам


Reverse Path Forwarding
  В таблице Unicast-маршрутизации
блок адресов 151.10.0.0/16 маршрутизируется S=151.10.7.11

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

  Multicast-пакет с адресом
Router#sh ip route
узла-отправителя 151.10.7.11, […]
пришедший из интерфейса S1, O IA 150.10.0.0/16 via x.x.x.x, Serial1
будет переправлен в каждый
интерфейс, где находятся абоненты данной multicast-группы.
  Никакие multicast-пакеты никогда не будут отправлены в тот
интерфейс, с которого были получены.


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

Таблица, из которой
Administrative Distance
известен источник
Unicast (Distance of route)
iMBGP 200
eMBGP 20
DVMRP 0
Static mroute 0


TTL Threshold

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


Administrative Boundary
Administrative Boundary = 239.0.0.0/8

239.x.x.x multicast 239.x.x.x multicast
packets packets
S0 S1

  Конфигурируется командой “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

Source

  Информация о состоянии (S,
G) создается на каждом
Multicast Packets маршрутизаторе сети
Prune Messages   После окончания процесса
After “Prune” flow Flood-Prune информация (S, G)
все равно остается на каждом
Receiver 1 маршрутизаторе сети


PIM-DM operations (ч.2)

Source

Receiver 2

Graft Message

Receiver 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): 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
  Assert содержит metric и administrative distance
Winner подача трафика в сегмент
до источника
o  прекращается до следующей
o  побеждает (Assert Winner) лучший путь до источника
или – наибольший (highest) IP-address
итерации Assert
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): Received v2 Assert on FastEthernet0/1 from 1.1.1.1
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 State Refresh

Next-Hop to source
PIM-node

Receiver 2
Source

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



Прочие 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 непосредственно
между получателем и источником


PIM-SM operations
Register (S,G) 2
Register-Stop
6

Rendezvous
5 Point
Source 1 5

NHS
4
1.  При появлении трафика
ближайший к источнику (next-hop to source, NHS)
PIM-узел (2) регистрируется на RP
[ … сеть ждет первого получателя …]
4
3.  IGMP Join (*, G)
4.  PIM Join (*, G) в сторону RP
5.  PIM Join (S, G) в сторону NHS 3
6.  Построенное дерево: Receiver 1
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


PIM-SM operations (ч.2)
B0#sh ip mroute
IP Multicast Routing Table Rendezvous
Flags: P - Pruned, F - Register flag,
[ … ] NHS Point
(*, 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: Source
POS2/0, Forward/Sparse, 00:09:42/00:02:38

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 Receiver 1
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 D0#sh ip mroute
Incoming interface: POS2/0, RPF nbr 2.2.0.2 IP Multicast Routing Table
Outgoing interface list: Flags: S - Sparse, C - Connected,
POS3/0, Forward/Sparse, 00:00:11/00:02:48 [ … ]
(*, 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


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

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

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

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

P Pruned Outgoing Interface List пуст

T SPT flag Соответствует записям (S, G)
Join SPT Превышен порог переключения на SPT. Следующий пакет,
J для (*, G) пришедший по (*,G) вызовет переключение на (S,G)
Join SPT Было переключение с (*,G) на (S,G). При трафике ниже
J для (S, G) порога произойдет возврат на (*,G)
F Register flag По этой записи генерируются Register-* сообщения.

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


PIM-SM switchover

Rendezvous
Source Point
Join (S,G)
NHS

  Next-Hop to Receiver (NHR) может
переключиться на SPT при
o  обнаружении источника NHR
o  и превышении порога трафика в RPT
NOTE: значение порога по
умолчанию – 0
Receiver 1
  NHR шлет PIM Join (S, G) в сторону
NHS


PIM-SM switchover (ч.2)

Rendezvous
Source Point
Prune (S,G)
NHS

Prune (*,G)

При построении SPT и получении
трафика в нем:
NHR
  NHR шлет PIM Prune (*, G) в сторону RP
o  если RPT не нужен – исчезает
  RP шлет PIM Prune (S, G) в сторону NHS Receiver 1
o  если SPT не нужен - исчезает


PIM-SM switchover (ч.3)

Rendezvous
Source Point

NHS

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


Designated Router Election

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

  Designated Router – единственный в сегменте, который
шлет PIM Join / Prune для этого сегмента
  Побеждает PIM-узел (Designated Router) с
o  наибольшим приоритетом
o  или – наибольшим (highest) IP-адресом
  Если Designated Router выходит из строя, то по
истечении timeout происходят новые выборы DR
o  до выборов нового DR трафик в сегмент не поступает


Идентификация
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: заголовок
7 15 31
  Type: Type Max. Resp.
Checksum
0x11 = Group Membership Query Time
0x12 = Version 1 Membership Report
Group Address
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)


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.10 1.1.1.11 1.1.1.12
239.1.1.1 239.1.1.1
H1 H2 H3

Leave to Report to
#1 224.0.0.2 #3 239.1.1.1

1.1.1.1 Group Specific
Query to 239.1.1.1
  H2 отключается от группы и посылает
сообщение Leave. #2

  IGMP Querier посылает Group Specific Query
  Один из оставшихся участников группы шлет “Group Specific
Membership”
  Группа остается активной до тех пор, пока будут приходить
ответы от активных хостов


Multicast VLAN Registration

Multicast VLAN

Data VLAN

IGMP Join / Leave

SDTV SDTV

Два варианта поддержки MVR:
  MVR on Access Port
  MVR on Trunk Port (поддерживается на некоторых моделях)
http://www.cisco.com/en/US/docs/switches/metro/me3400e/software/release/12.2_55_se/configuration/guide/swigmp.html


Interdomain
Multicast
Routing


Multiprotocol BGP extensions

AS1 AS2
PIM Join

Multicast Stream
AS5 AS3

AS4
No multicast PIM Join

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


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
router bgp 100 router bgp 101
no bgp default ipv4-unicast no bgp default ipv4-unicast
bgp log-neighbor-changes bgp log-neighbor-changes
neighbor “X0” remote-as 100 neighbor “X0” remote-as 100
neighbor “X0” update-source Loopback0 neighbor “Z0” remote-as 100
neighbor “X1” remote-as 101 !
! address-family ipv4
address-family ipv4 no synchronization
Z0
no synchronization AS101 network 101.0.0.0
neighbor “X0” activate
network 100.0.0.0 Multic
ast lin neighbor “X0” next-hop-self
neighbor “X0” activate k
no auto-summary no auto-summary
X1
exit-address-family exit-address-family
!
! AS100 address-family ipv4 multicast
address-family ipv4 multicast
network 100.2.0.0 mask 255.255.0.0 neighbor “Z0” activate
neighbor “X1” activate neighbor “Z0” next-hop-self
X0 no auto-summary
neighbor “X1” next-hop-self
no auto-summary exit-address-family
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

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


Multicast Source Discovery Protocol

  RFC 3618
  Работает только с PIM-SM
o RP осведомлены обо всех источниках в своем
домене
 Источники регистрируются на RP посредством “PIM
Register”
 RP обмениваются информацией об источниках
посредством сообщений MSDP SA (Source Active)
o RP осведомлены обо всех получателях в своем
домене
 Получатели подключаются к RP посредством Join (*, G)
 RP подключаются к источникам в других доменах
посредством Join (S, G)

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


MSDP в действии

SA: Source Active
AS5
RP

AS3 RP

AS2 RP

RP

AS1 AS4
RP

( 100.2.0.2,
239.1.1.1 ) MSDP SA
(S, G)
Register
(S, G)


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

AS5
RP

AS3 RP

AS2 RP

Join (*,G)

RP
Join (S,G)
AS1 AS4
RP

( 100.2.0.2,
239.1.1.1 )
Конечный узел (ближайший к
получателю) может выполнить
переключение на SPT, отключаясь от
своего RP (в примере – от RP-AS5)


Anycast RP

  Резервирование RP внутри одного домена
o  основано на MSDP
  RFC 3446
  Концепция в общем:
o  Внутри одного домена размещается несколько RP с
одинаковым IP-адресом
o  Источники и получатели пользуются ближайшим (в
соответствии с unicast-маршрутизацией) RP
  балансировка нагрузки между несколькими RP
o  Для обмена информацией между RP об активных
источниках используется MSDP


Anycast RP в действии

Src1 Src2

RP1 RP2
MSDP
A B
SA (src1) SA (src2)
10.1.1.1 10.1.1.1

Rec Rec Rec Rec


Anycast RP failover

Src1 Src2

RP1 RP2

A B
10.1.1.1 10.1.1.1

Rec Rec Rec Rec


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

RP1 RP2
MSDP
A B
ip pim rp-address 10.0.0.1 ip pim rp-address 10.0.0.1

C D

Interface loopback 0 Interface loopback 0
ip address 10.0.0.1 255.255.255.255 ip address 10.0.0.1 255.255.255.255

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


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


SSM в действии
Directory
Server
Source

4 3
NHR

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


Модель Anycast Source
  В сети присутствует два (и более) Source “A” Source “B”
одновременно работающих 10.10.10.10 10.10.10.10
источника вещания с одинаковыми
IP-адресами
Анонсы
  Получатель подключается к IGP

ближайшему (с точки зрения 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 [N] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. Auxiliary Data .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Record Types (RFC 3376, 4.2.12 clause):
1 / MODE_IS_INCLUDE 3 / CHANGE_TO_INCLUDE_MODE 5 / ALLOW_NEW_SOURCES
2 / MODE_IS_EXCLUDE 4 / CHANGE_TO_EXCLUDE_MODE 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
(S,G) Join

URD 101.2.0.1

Я понимаю, что это за запрос и запоминаю, что
нужно подключиться к группе 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
IGMPv3Lite UDP 465
Daemon Membership
(S,G) Join Report IGMPv3 Lite- aware
INCLUDE Router
IP SSM API
(S,G)
HSIL
(*,G) Join

Host
Operation System

IGMPv2 Membership Report


SSM Mapping
Формат записи в DNS:

Source 3.2.1.232.ssm.cisco.com IN A 172.23.20.70
172.23.20.70

PIM (S,G) join 3
2
DNS Server
Запрос к DNS
IGMPv2 join
232.1.2.3 1

Set Top Box (STB)

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


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

HDTV LO3

A1 101.2.0.1/24 -> 2
AS101
1 1.1
B1
1.3 3
4 X1
1.2
101.0.0.1/30 -> 2 101.0.0.5/30 -> 6

2 LO4
LO1 HDTV 1
100.2.0.1/24 -> 2
2 0.2
192.168.0.2/24 -> 1
4 B0
0.5 0.6
1
X0 Z0 3
.2 <= 1.1.1.0/24 => .1

0.4
D0 100.2.1.1/24 -> 2

HDTV

AS100 LO5


End of 4 th Day

Happy
configuring! 

Basics of routing & switching: Multicast

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (6)

Similar to Basics of routing & switching: Multicast

Similar to Basics of routing & switching: Multicast (20)

Basics of routing & switching: Multicast