This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Каждая multicast-группа идентифицируется Class-D адресом Для получения данных абонент должен быть участником группы Данные, посылаемые в группу, будут получены всеми участниками группы Для посылки данных в группу отправитель не должен быть участником группы Адрес источника никогда не может быть Class-D адресом
Передаются с 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) сетях
В 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.
Кратчайший путь (lowest cost) между источником и получателями
Пересылка трафика осуществляется по двум параметрам – адресу источника (Source) и адресу группы (Group), поэтому описание дерева выглядит следующим образом: (S,G)
Каждое дерево строится на основе адреса источника и адреса группы, поэтому для каждой пары строится свое дерево
Также известно как Shared Path Tree В общем дереве multicast-потоки от нескольких источников собираются в единую точку – Rendezvous Point (RP) – из которой далее пересылаются получателям потоков. Поскольку источники потоков скрыты, то пересылка трафика осуществляется по одному параметру (Группе), вне зависимости от адреса источника и описание дерева выглядит следующим образом: (*,G) Источник регистрируется на RP (посылкой соответствующего Register Message) и RP регистрируется в SPT к источнику.
Для пересылки 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
TTL Threshold задается на каждом интерфейсе. Значение по-умолчанию – 0 (нет установленного лимита). У всякого входящего пакета значение TTL уменьшается на единицу. Если результат <= 0, то пакет отбрасывается. Если получившееся значение TTL >= установленного на исходящем интерфейсе лимита, то пакет форвардится в этот интерфейс. Если получившееся значение TTL < установленного на исходящем интерфейсе лимита, то пакет отбрасывается.
Dense Mode (push model) o По умолчанию трафик распространяется по всей сети o Маршрутизаторы, у которых нет получателей multicast-трафика, в явном виде отказываются от этого трафика o Процесс пересылки и отказа от трафика повторяется периодически o Протоколы PIM-DM, DVMRP, MOSPF
Sparse Mode (pull model) o Маршрутизаторы явно запрашивают multicast-трафик при возникновении активных получателей o Трафик пересылается только в те фрагменты сети, где есть активные получатели o Протокол PIM-SM
При детектировании петли граничные маршрутизаторы шлют в сегмент сообщение 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)
При детектировании петли граничные маршрутизаторы шлют в сегмент сообщение 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 подача трафика в сегмент прекращается до следующей
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
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
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
С помощью протокола Internet Group Management Protocol (IGMP) абонентские устройства (компьютер,
Set-Top-Box (STB) и другие) сообщают о своем желании подключиться к multicast-группе, которая
распространяется по IP-сети RFC 1112 описывает первую (устаревшую) версию RFC 2236 описывает IGMP v2 – наиболее широко распространенная версия RFC 3376 описывает IGMP v3
Кратчайший путь для Unicast-трафика (AS3 – AS4 – AS5) не работает для Multicast-трафика Нужна отдельная таблица маршрутизации для Multicast Multiprotocol BGP extensions
Multicast-префиксы не размещаются в таблице маршрутизации
Security tip: если разместить источники в RFC1918-адресах и распространять их через MBGP, то доступа к ним из Unicast-пространства не будет
Не является заменой протоколу PIM – не передает и не поддерживает состояние multicast distribution tree PIM при построении дерева использует маршруты в следующем порядке: 1/Static, 2/MBGP, 3/Unicast
o RP осведомлены обо всех источниках в своем домене Источники регистрируются на RP посредством “PIM
Register” RP обмениваются информацией об источниках посредством сообщений MSDP SA (Source Active)
o RP осведомлены обо всех получателях в своем домене Получатели подключаются к RP посредством Join (*, G) RP подключаются к источникам в других доменах посредством Join (S, G)
Резервирование RP внутри одного домена o основано на MSDP
RFC 3446 Концепция в общем:
o Внутри одного домена размещается несколько RP с одинаковым IP-адресом o Источники и получатели пользуются ближайшим (в соответствии с unicast-маршрутизацией) RP
балансировка нагрузки между несколькими RP
o Для обмена информацией между RP об активных источниках используется MSDP
Зачем протоколу PIM-SM требуется Shared Tree / Rendezvous Point?
o Для того, чтобы узнавать о появлении новых источников
А что если источник известен заранее? o Абонентские устройства должны слать запрос в виде (S, G) для подключения к SPT o Shared Tree / RP больше не нужен o Различные источники могут использовать одинаковые группы и никак не мешать друг другу
В сети присутствует два (и более) одновременно работающих источника вещания с одинаковыми IP-адресами Получатель подключается к ближайшему (с точки зрения IGP) источнику Источник, пока активен, анонсирует себя посредством IGP (например, RIPv2) Преимущества
o Не нужен MSDP (как в случае с Anycast-RP) o Балансирование нагрузки o Резервирование
Решает проблему распределения адресов o потоки идентифицируются парой (S, G), а не только группой o операторы могут использовать одни и те же группы, поскольку пара (S, G) уникальна
Позволяет избегать атак: o трафик от неизвестных источников не расходует емкость сети o трафик от неизвестных источников не попадает на абонентские устройства поскольку источники не зарегистрированы в каталоге
Сообщения «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