Protocol independent multicast что это

Обновлено: 05.07.2024

На этой странице описывается настройка PIM на маршрутизаторах Cisco.

Так как тема достаточно обширная, то многое вынесено на отдельные страницы, а на этой собраны те настройки, которые актуальны для всех режимов работы PIM.

Оборудование Cisco поддерживает несколько вариантов протокола PIM:

Кроме PIM-DM, все остальные варианты работают на основе PIM-SM. А работа PIM-SSM основана на IGMPv3.

Как правило, настройки протокола достаточно просты, при соблюдении некоторых условий и понимании принципов работы. Проще всего работать с PIM, когда область работы PIM совпадает с протоколом маршрутизации, который используется в сети. Так как PIM использует unicast таблицу маршрутизации для проверки RPF, такое совпадение доменов маршрутизации упрощает работу с PIM.

Содержание

Как и другим протоколам, для того чтобы маршрутизировать мультикаст, PIM должен построить дерево для передачи мультикаст. В зависимости от того, какой именно вариант PIM работает, может использоваться sourse tree, shared tree, одно из них, или оба одновременно.

Для PIM таблица маршрутизации мультикаст будет состоять не из маршрутов, как для unicast, и из записей вида (источник, группа) или (S, G). Эти записи могут быть двух типов:

  • (S, G) — когда известен источник. Эта запись характерна для SPT-дерева,
  • (*, G) — когда дерево строится к некой общей точке (RP). Эта запись характерна для shared tree.

Кроме самой записи, (S, G) или (*, G), для каждой записи хранится информация о том, какой интерфейс локального маршрутизатора ведет вверх по дереву, к источнику или RP (и откуда, соответственно, будет приходить данные мультикаст), и какие интерфейсы ведут вниз, к получателям или нижестоящим соседям (куда данные мультикаст будут передаваться).

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

Второе фундаментальное понятие, связанное с маршрутизацией мультикаст — проверка RPF.

Reverse Path Forwarding (RPF) — это проверка, которую выполняют маршрутизаторы, для того чтобы убедиться, что multicast трафик передается по пути без петель.

Подробнее об RPF:

Основная страница: RPF

PIM может работать в нескольких режимах, которые можно считать разными протоколами. Базовые принципы работы, такие как, установка отношений соседства, проверка RPF, работают во всех вариантах PIM одинаково. Разные варианты протокола отличает то, как маршрутизаторы заполняют таблицу маршрутизации мультикаст, как маршрутизатор передает пакеты, которые получил от источника, каким образом маршрутизаторы узнают об источниках и группах.

Два основных режима, в которых может работать PIM:

  • Dense Mode (PIM-DM)
    • Логика работы протокола предполагает, что в домене много получателей мультикаст. Как правило, этот вариант PIM редко используется
    • PIM-DM использует только деревья SPT
    • В PIM-DM маршрутизаторы распространяют (флудят) трафик по всему домену мультикаст
      • С помощью этого все маршрутизаторы узнают о существующих парах (источник, группа)
      • Это значит, что все маршрутизаторы в мультикаст домене знают обо всех группах и источниках, которые есть в домене
      • PIM-SM использует shared деревья
        • Но также и SPT деревья
        • Все маршрутизаторы в мультикаст домене знают об RP (как именно они узнают об RP, написано в разделе PIM-SM)
        • В дальнейшем возможно переключение на SPT
        • Запись (S, G), в отличие от PIM-DM, есть только на RP и маршрутизаторе, который регистрировал источник на RP
        • То есть, только RP знает обо всех группах и источниках в домене. Остальные маршрутизаторы знают только об RP
        • Когда появляются клиенты, которые хотят получаться трафик определенной группы, маршрутизатор, ближайший к клиентам, отправляет по направлению к RP запрос на добавление себя в дерево
        • Записи (S, G) есть на RP и на маршрутизаторах, которые регистрировали источники
        • Записи (*, G) появляются, когда есть клиенты, которые хотят получать трафик какой-то группы
        • При переключении на SPT, на маршрутизаторах появятся записи (S, G)

        Также в Cisco отдельно выделяют вариант PIM Sparse-Dense, который является гибридом соответствующих вариантов PIM. Подробнее о нем на странице PIM-SM в Cisco.


        Кроме протоколов PIM-DM и PIM-SM, есть также протоколы, которые основаны на PIM-SM, но имеют свою специфику работы:

        • Bidirectional PIM (BIDIR-PIM)
          • Предполагается, что источники и клиенты могут быть одними и теми же устройствами
          • Создан для работы по модели many-to-many
          • От PIM-SM BIDIR отличает то, как трафик идет от источника к RP.
            • Принцип передачи трафика от RP к получателям остается неизменным.
            • Новый механизм, который заменяет регистрацию и проверку RPF, это Designated Forwarder (DF)
            • Работает с IGMPv3
              • IGMPv3 позволяет клиентам отправлять запрос на получения трафика не только определенной группы, но и от определенного источника
              • IGMPv3 совместим с IGMPv2, то есть может отправлять запросы вида (*, G)

              Протоколы PIM-SM, BIDIR-PIM и PIM-SSM могут одновременно использоваться сети. Они не исключают друг друга. Если все три протокола должны работать в сети одновременно, то разграничение их работы выполняется назначением разным протоколам разных диапазонов групп. То есть, в итоге, именно группа определяет каким образом будет обрабатываться трафик, по правилам какого протокола.

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

              PIM-DM на сегодняшний день уже считается устаревшим протоколом и редко используется.

              PIM-SM используется чаще других и при небольших количествах групп и источников, может работать в любой сети.

              BIDIR-PIM используется для оптимизации работы сетей, в которых используются приложения с моделью взаимодействия many-to-many. По сравнению с работой PIM-SM, в BIDIR-PIM эти приложения намного меньше влияют на сеть даже при большом количестве групп и источников.

              PIM-SSM используется в сетях, где поддерживается IGMPv3, так как именно в этой версии IGMP клиент может указать рассылку от какого источника он желает (или не желает) получать.

              В PIM-DM информация об источнике и группе распространяется по всему домену мультикаст. Выполняется это с помощью процедуры флудинга. Распространение информации об источнике и группе происходит независимо от того, есть ли в данный момент клиенты, которые хотят получать данные этой группы.

              Так как информация передается всем маршрутизаторам, то каждый маршрутизатор знает о существующих группах и источниках. И следовательно, когда появляется клиент, которых хочет получать трафик определенной группы, любой маршрутизатор в мультикаст домене знает где находится источник, который передает данные этой группы, и строит SPT-дерево к источнику.

              Как правило, в реальной жизни, этот вариант PIM редко используется.

              Основная страница: PIM-DM

              В PIM-SM информация не флудится по всему домену, как в PIM-DM. В PIM-SM маршрутизаторы добавляются в дерево передачи мультикаст трафика, только если они явно отправляют PIM Join. То есть, явно сообщают о том, что они хотят получать трафик определенной группы. Это происходит, когда у маршрутизатора есть непосредственно присоединенные клиенты, которые хотят получать трафик (отправили IGMP Join), или когда он получил PIM Join от нижестоящего маршрутизатора.

              Для координации работы в домене PIM-SM, одному из маршрутизаторов назначается роль rendezvous point (RP). RP знает обо всех парах (источник, группа) в домене. А все остальные маршрутизаторы обязательно должны знать, IP-адрес RP.

              Когда появляется новый источник мультикаст, маршрутизатор, который непосредственно присоединен к источнику, регистрирует источник на RP. Таким образом RP узнает об источнике и о том, на какой адрес группы источник передает трафик, то есть о паре (S, G).

              Когда маршрутизаторы получают запросы от клиентов, на присоединение к группе, то они отправляют запрос "вверх" к RP. То есть, строят shared дерево с вершиной в RP (shared потому что RP будет вершиной для всех групп). Так как RP знает об источнике, то от RP до источника строится дерево SPT, с вершиной в источнике. RP соединяет эти два дерева.

              Основная страница: PIM-SM

              Bidirectional PIM (BIDIR-PIM) создан для оптимизации работы PIM в сетях, где модель взаимодействия many-to-many. То есть, в таких сетях, где получатели и источники это одни и те же устройства.

              По сути, BIDIR-PIM использует как основу PIM-SM, но с некоторыми изменениями.

              BIDIR-PIM использует только RPT-деревья (shared tree). И, вместо проверки RPF, использует понятие Designated Forwarder (DF). А деревья, которые BIDIR-PIM строит к RP, теперь двунаправленные.

              Основная страница: BIDIR-PIM

              Несмотря на то, что разные варианты работы PIM (а можно сказать и разные протоколы из семейства PIM), работают по-разному, у них есть базовые общие принципы работы.

              • Маршрутизатор который анонсирует наименьшую AD протокола маршрутизации, который использовался для получения маршрута к источнику.
              • Если AD совпадает, то выигрывает маршрутизатор который анонсирует наименьшую метрику для маршрута, который ведет к источнику.
              • Если метрика совпадает, то выигрывает маршрутизатор с наибольшим IP-адресом в этой локальной сети.

              Маршрутизатор, который был выбран, называется Forwarder.

              После выборов Forwarder продолжает отправлять multicast трафик в сеть. Другие маршрутизаторы, которые участвовали в выборах, исключают интерфейс ведущий в сегмент с множественным доступом из списка исходящих интерфейсов.

              Если таблица маршрутизации изменилась и путь к источнику multicast трафика новый, то PIM-DM тоже должен внести изменения.

              Сети для самых маленьких. Часть 9.4. Мультикаст. Мультикаст на канальном уровне

              Последняя статья из серии про мультикаст. Рассмотрим особенности мультикастовых MAC адресов, IGMP Snooping и Multicast VLAN Replication.

              Мультикаст на канальном уровне

              Итак, позади долгая трудовая неделя с недосыпами, переработками, тестами — вы успешно внедрили мультикаст и удовлетворили клиентов, директора и отдел продаж.

              Пятница — не самый плохой день, чтобы обозреть творение и позволить себе приятный отдых.

              Но ваш послеобеденный сон вдруг потревожил звонок техподдержки, потом ещё один и ещё — ничего не работает, всё сломалось. Проверяете — идут потери, разрывы. Всё сходится на одном сегменте из нескольких коммутаторов.

              Дотошное расследование показало, что компьютер клиента заражён и рассылает IGMP Query на все мультикастовые адреса подряд.

              Потери пакетов начались, потому что коммутаторам пришлось пропускать через себя огромный объём трафика. Это вызвало переполнение буферов интерфейсов.

              Главный вопрос — почему трафик одного клиента начал копироваться во все порты?

              Причина этого кроется в природе мультикастовых MAC-адресов. Дело в том, пространство мультикастовых IP-адресов специальным образом отображается в пространство мультикастовых MAC-адресов. И загвоздка в том, что они никогда не будут использоваться в качестве MAC-адреса источника, а следовательно, не будут изучены коммутатором и занесены в таблицу MAC-адресов. А как поступает коммутатор с кадрами, адрес назначения которых не изучен? Он их рассылает во все порты. Что и произошло.

              Это действие по умолчанию.


              Multicast Flooding

              Содержание

              Независимо от режима PIM, первое, что нужно сделать, включить маршрутизацию мультикаст:

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

              При включении PIM на интерфейсе автоматически включается и IGMP.

              Фактически, включать IGMP нужно только на интерфейсах к которым подключены клиенты. Но включение IGMP на всех транзитных участках сети позволяет работать, например, утилите mtrace.

              Мультикаст трафик в PIM маршрутизируется в соответствии с правилами режима, который настроен для конкретной мультикаст группы.

              Реализация PIM в Cisco поддерживает такие режимы мультикаст групп:

              На маршрутизаторах Cisco одновременно могут работать группы всех четырех режимов.

              Чаще всего, встречается ситуация, когда на основе домена PIM-SM, должны работать также группы в режиме BIDIR-PIM и PIM-SSM. Если все три протокола должны работать в сети одновременно, то разграничение их работы выполняется назначением разным протоколам разных диапазонов групп. То есть, в итоге, именно адрес группы определяет каким образом будет обрабатываться трафик, по правилам какого протокола.

              Трафик, которые передается в режиме Dense, сначала флудится по всему домену мультикаст, а зачем исключаются ветви дерева, где нет желающих получать трафик.

              В Cisco режим dense включается для групп:

              • для всех групп, если на интерфейсах включен режим dense
              • для групп 224.0.1.39 и 224.0.1.40, если на интерфейсах включен режим sparse-dense
                • если на интерфейсах включен PIM в режиме sparse-dense, то все группы, для которых у текущей RP нет соответствия, также будут работать в режиме dense

                Основная страница: PIM-DM в Cisco

                Работа режима sparse построена вокруг rendezvous point (RP). RP это точка, к которой строятся деревья от клиентов, которые хотят получать трафик определенной группы (RPT-деревья).

                В PIM-SM оба дерева, и RPT и SPT, односторонние. То есть, трафик может передаваться по ним только в одном направлении. В SPT от источника к RP, а в RPT от RP к клиентам.

                Основная страница: PIM-SM в Cisco

                В BIDIR-PIM работа протокола построена вокруг RP, как и в PIM-SM. Но в BIDIR-PIM используются только shared tree с вершиной в RP, и не используются SPT-деревья.

                Кроме того, BIDIR-PIM RPT-деревья двунаправленные, то есть, трафик по ним может передаваться в двух направлениях.

                В этом режиме IP-адрес RP используется всеми маршрутизаторами в домене для построения топологии без петель. Так как в BIDIR-PIM нет процедуры регистрации, и нет SPT, то трафик от источника идет по RPT-дереву до RP. И для того чтобы определить какому маршрутизатору разрешено передавать трафик вверх по RPT-дереву, в каждом сегменте выбирается маршрутизатор, который находится "ближе" всех в RP. Этот маршрутизатор называется Designated Forwarder (DF).

                В итоге, в BIDIR-PIM трафик передается только по RPT-дереву.

                BIDIR-PIM работает на основе PIM-SM. В том смысле, что на интерфейсах маршрутизаторов включается режим sparse. А затем включается режим BIDIR и указывается какой диапазон групп будет работать в этом режиме.

                Основная страница: BIDIR-PIM в Cisco

                Режим PIM-SSM работает с IGMPv3. Так как в IGMPv3 появилась возможность клиентам указывать от какого источника они хотят получать рассылку, то в PIM-SSM не нужны RP и, соответственно, нет RPT-деревьев. Маршрутизаторы, получив запрос от клиента, сразу видят рассылку какой группы клиент хочет получать и могут строить SPT-дерево непосредственно к источнику.

                Так как, как правило, PIM-SSM работает на основе существующего домена PIM-SM, то маршрутизаторы должны понимать, что для ряда групп не надо регистрировать источник на RP, что они работают в режиме SSM. Это указывается явно, при включении SSM режима. По умолчанию, группы диапазона 232.0.0.0/8 работают в режиме SSM.

                Основная страница: PIM-SSM в Cisco

                Проверка RPF — одно из самых важных понятий для PIM. Подробнее о сути проверки RPF, вариантах влияния на нее и настройках в Cisco:

                Основная страница: RPF

                Просмотр информации о значении интервала на интерфейсе:

                Хотя DR играет разную роль, в разных версиях PIM, настройка приоритета, для выбора маршрутизатора, который будет DR и принцип выбора, одинаковы для всех версий.

                В режиме PIM-DM выбор DR необходим только в том случае, если используется IGMPv1.

                По умолчанию у всех маршрутизаторов приоритет 1, поэтому DR выбирается на основании IP-адреса:

                • маршрутизатор у которого больше IP-адрес, становится DR.

                Настройка приоритета для выбора DR:

                Просмотр информации о приоритете интерфейса:

                Просмотр информации о приоритете соседа:

                Посмотреть содержимое таблицы IP multicast routing table:

                • summary — отображает суммарную информацию о каждой записи в таблице
                • count — отображает статистику о группе и источнике
                • active — отображает rate с которым активные источники передают информацию

                Флаги в таблице mroute:

                Как только на интерфейсе включен PIM, в таблице маршрутизации multicast сразу создается запись (*, 224.0.1.40). Это запись называется родительской (parent entry)

                Информация об интерфейсах настроенных для работы PIM:

                Информация о соседях:

                Информация о multicast маршрутизаторе (если не указывать адрес, то о локальном маршрутизаторе, с указанием адреса — о соседе):

                Показать активные RP:

                Отобразить как IP multicast делает RPF:

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

                Например, для выбранной схемы, PIM-DM включён на всех интерфейсах dyn, кроме интерфейса fa0/0 dyn3 и интерфейса fa1/0 dyn2.

                А на маршрутизаторе dyn3, маршрут OSPF к сети 192.168.1.0/24 проходит через интерфейсы на которых выключен PIM-DM:

                Для проверки настроек PIM-DM интерфейс fa1/0 dyn5 назначен участником группы 224.1.1.1:

                Проверка прохождения multicast трафика:

                Проверка RPF на dyn5:


                Проверка RPF на dyn3:

                Настройка статического маршрута на dyn3:

                Несмотря на название статический маршрут для multicast трафика, фактически это не маршрут, а возможность указать дополнительный путь позволяющий пройти проверку RPF.

                Просмотр информации о добавленном маршруте:

                Повторная проверка RPF на dyn3:

                Проверка прохождения multicast трафика:

                На всех интерфейсах dynamips настроен режим PIM sparse-dense:

                Так как dyn4 и dyn5 будут выполнять роль RP, а dyn3 роль mapping agent, то на их loopback-интерфейсах тоже включён режим PIM sparse-dense:

                Настройка dyn4 как RP для групп 224.4.4.4 и 224.5.5.5:

                Настройка dyn5 как RP для групп 224.4.4.4 и 224.5.5.5:

                Настройка dyn3 как RP mapping agent:

                Настройка фильтрации RP на dyn3.

                Настройка dyn4 как RP для группы 224.4.4.4:

                Настройка dyn5 как RP для группы 224.5.5.5:

                Ограничение количества маршрутов в таблице:

                Multicast scoping это возможность определения границ распространения multicast трафика.

                Методы multicast scoping:

                • TTL scoping — маршрутизатор сравнивает значение TTL в multicast пакете со значением TTL, которое настроено на каждом исходящем интерфейсе. Маршрутизатор передает пакет только через те интерфейсы на которых настроенное значение TTL меньше или равно значению TTL в пакете. На маршрутизаторах Cisco по умолчанию значение TTL на интерфейсе равно 0.
                • Administrative scoping

                Посмотреть настройки фильтра на интерфейсе:

                Multicast2.jpg

                В примерах 192.168.2.2 это источник трафика, а 192.168.6.5 клиент, группа 239.1.1.1.

                Мультикастовые MAC-адреса

                Так какие же MAC-адреса получателей подставляются в заголовок Ethernet таких пакетов? Широковещательные? Нет. Существует специальный диапазон MAC-адресов, в которые отображаются мультикастовые IP-адреса.

                Эти специальные адреса начинаются так: 0x01005e и следующий 25-й бит должен быть 0 (попробуйте ответить, почему так). Остальные 23 бита (напомню, всего их в МАС-адресе 48) переносятся из IP-адреса.

                Здесь кроется некоторая не очень серьёзная, но проблема. Диапазон мультикастовых адресов определяется маской 224.0.0.0/4, это означает, что первые 4 бита зарезервированы: 1110, а оставшиеся 28 бит могут меняться. То есть у нас 2^28 мультикастовых IP-адресов и только 2^23 MAC-адресов — для отображения 1 в 1 не хватает 5 бит. Поэтому берутся просто последние 23 бита IP-адреса и один в один переносятся в MAC-адрес, остальные 5 отбрасываются.

                Multicast MAC Address

                Фактически это означает, что в один мультикастовый MAC-адрес будет отображаться 2^5=32 IP-адреса. Например, группы 224.0.0.1, 224.128.0.1, 225.0.0.1 и так до 239.128.0.1 все будут отображаться в один MAC-адрес 0100:5e00:0001.

                Если взять в пример дамп потокового видео, то можно увидеть:

                Дамп мультикаста

                Дамп мультикаста

                IP адрес — 224.2.2.4, MAC-адрес: 01:00:5E:02:02:04.

                Есть также другие мультикастовые MAC-адреса, которые никак не относятся к IPv4-мультикаст (клик). Все они, кстати, характеризуются тем, что последний бит первого октета равен 1.

                Всего, что мы рассматривали прежде, вполне достаточно для полноценной передачи любого мультикастового трафика от потокового видео до биржевых котировок. Но неужели мы в своём почти совершенном мире будем мирится с таким безобразием, как широковещательная передача того, что можно было бы передать избранным?

                Вовсе нет. Специально для перфекционистов придуман механизм IGMP Snooping.

                Protocol independent multicast что это

                Если вы считаете, что её стоило бы доработать как можно быстрее, пожалуйста, скажите об этом.


                Protocol Independent Multicast (PIM) — это группа протоколов, которые занимаются маршрутизацией мультикаст. И, хотя некоторые основы работы протоколов из этой группы одинаковы, каждый конкретный протокол работает по-разному.

                "Protocol independent" в названии протокола означает, что PIM может работать с unicast таблицей маршрутизации, независимо от того, как именно она заполнены. То есть, он может использовать, например, маршруты OSPF, EIGRP, статические маршруты и др. Кроме того, сам PIM не передает информацию о маршрутах, а строит дерево для передачи мультикаст трафика на основе таблицы маршрутизации unicast.

                На этой странице описываются принципы работы PIM, которые одинаковы во всех вариантах протокола. А также кратко описаны основы работы каждого варианта PIM. Подробная информация на страницах соответствующих варианту PIM.

                Содержание

                PIM-SM информация не флудится по всему домену, как в PIM-DM. В PIM-SM маршрутизаторы добавляются в дерево передачи мультикаст трафика, только если они явно отправляют PIM Join. То есть, явно сообщают о том, что они хотят получать трафик определенной группы. Это происходит, когда у маршрутизатора есть непосредственно присоединенные клиенты, которые хотят получать трафик (отправили IGMP Join), или когда он получил PIM Join он нижестоящего маршрутизатора.

                Rendezvous Point (RP)

                PIM-SM 4.jpg

                Проблема с изучением этой информации в PIM-SM решается так: вместо флудинга, как в PIM-DM, в PIM-SM выбирается одна общая точка, один маршрутизатор, который будет хранить информацию о группах и источниках. Это обычный маршрутизатор PIM-SM (их может быть несколько), который выполняет роль rendezvous point (RP). И все маршрутизаторы в домене PIM-SM обязательно должны знать, кто выполняет роль RP.

                Когда маршрутизаторы получают запросы от клиентов, на присоединение к группе, то они отправляют запрос "вверх" к RP. В итоге строится дерево, для конкретной группы, где ветками будут маршрутизаторы, которые хотят получать пакеты конкретной группы, а вершиной построенного дерева будет RP. Но, так как для всех групп вершина всегда RP, то это дерево называется shared tree. На каждом маршрутизаторе, от RP вниз по дереву, который является частью дерева для конкретной группы G, будет запись вида (*, G), где * обозначает RP, общую вершину деревьев.

                PIM-SM 1a.jpg

                Построение дерева

                И, когда появятся желающие получать рассылку этой группы, маршрутизаторы построят shared tree до RP, а RP построит SPT-дерево к источнику. И клиенты смогут получить мультикаст пакеты по этому дереву составленному из двух. И, хотя построенное дерево может не быть кратчайшим для передачи пакетов получателям, такой подход существенно сокращает количество информации, которое надо хранить маршрутизаторам в домене мультикаст, по сравнению с PIM-DM. Кроме того, после того как реальные пакеты мультикаст, дойдут до маршрутизаторов к которым непосредственно подключены клиенты, эти маршрутизаторы, узнав IP-адрес источника из пакетов, могут инициировать переключение на SPT-дерево непосредственно к источнику трафика и исключить себя из shared tree.

                Модель распространения трафика PIM-SM, называется также pull model или explicit join.

                • Hello для обнаружения соседей и поддержания связи с соседями
                • Register для регистрации источника
                • Register-Stop
                • Join для добавления ветвей в дерево распространения мультикаст трафика
                • Prune для удаления ветвей из дерева распространения мультикаст трафика
                • Assert для выбора Forwarder
                • Bootstrap
                • Candidate-RP-Advertisement

                PIM-SM 1a.jpg

                После получения пакета Register, RP деинкапсулирует пакет и проверяет есть ли в таблице маршрутизации multicast запись для соответствующей группы. Если запись есть, то есть, RP знает о каких-то маршрутизаторах или хостах, которые хотят получать копии этого трафика, то копии трафика передаются через соответствующие интерфейсы.

                PIM-SM 1b.jpg

                В PIM-SM DR важен, так как маршрутизатор, который стал DR, отвечает за регистрацию источника на RP и в некоторых ситуациях, неправильный выбор DR может повлиять на работу сети.

                PIM-SM 0.jpg

                Для координации работы в домене PIM-SM, одному из маршрутизаторов (или нескольким) назначается роль rendezvous point (RP). RP знает обо всех парах (источник, группа) в домене засчет процедуры регистрации, которая описана выше.

                Для работы PIM-SM необходимо чтобы каждый маршрутизатор, который работает по PIM-SM, знал адрес RP. Для того чтобы выучить адрес RP маршрутизатор может использовать один из методов:

                • Адрес RP может быть настроен статически на всех маршрутизаторах.
                • Использовать протокол BootStrap Router (BSR) для назначения RP и для анонсирования её адреса для того чтобы все PIM-SM маршрутизаторы могли выучить адрес автоматически.
                • Использовать проприетарный протокол Cisco Auto-RP для выбора RP и для анонсирования её адреса для того чтобы все PIM-SM маршрутизаторы могли выучить адрес автоматически.

                Так как PIM-SM зависит от RP, то существуют механизмы для выбора избыточных RP:

                • Anycast RP с использованием Multicast Source Discovery Protocol (MSDP),
                • BootStrap Router (BSR)

                PIM-SM 4.jpg

                Когда в сети появляются желающие получать рассылку определенной группы, маршрутизаторы строят shared tree до RP, а RP строит SPT-дерево к источнику. После этого клиенты смогут получить мультикаст пакеты по этому дереву составленному из двух. И, хотя построенное дерево может не быть кратчайшим для передачи пакетов получателям, такой подход существенно сокращает количество информации, которое надо хранить маршрутизаторам в домене мультикаст, по сравнению с PIM-DM. Кроме того, после того как реальные пакеты мультикаст, дойдут до маршрутизаторов к которым непосредственно подключены клиенты, эти маршрутизаторы, узнав IP-адрес источника из пакетов, могут инициировать переключение на SPT-дерево непосредственно к источнику трафика и исключить себя из shared tree.

                Сначала маршрутизатор к которому подключены клиенты инициирует подключение к RPT. Переключиться на SPT маршрутизатор может после того как получит пакеты от источника трафика через RPT. RFC 2362 рекомендует настраивать переключение на SPT после того как было получено большое количество данных за определенный период времени от одного источника через RPT (какое количество данных и за какой промежуток времени в RFC не указывается). После превышения установленного порога маршрутизатор инициирует переключение на SPT.

                Запись (S,G) сохраняется с таблице маршрутизации до тех пор, пока от источника приходит трафик. Для записи установлен таймер Entry-timer. По его истечению, запись будет удалена.

                При статической настройке RP, IP-адрес RP должен быть настроен на всех маршрутизаторах.

                Протокол BootStrap Router (BSR) является частью спецификации PIM версии 2 и описывает стандартизированный механизм распространения информации об RP по домену PIM.

                В итоге, когда все маршрутизаторы знают о BSR-маршрутизаторе, те из них, кому будет назначена роль RP, смогут сообщить о себе BSR-маршрутизатору.

                BSR-маршрутизатор передает информацию обо всех известных ему RP по домену PIM.


                BSR-маршрутизатор:

                Для работы протокола BootStrap необходимо назначить административно:

                • кандидатов в BSR (candidate bootstrap router, C-BSR),
                • кандидатов в RP (candidate rendezvous point, C-RP).

                Среди C-BSR маршрутизаторов должен быть выбран маршрутизатор, который будет выполнять роль BSR. Каждому C-BSR соответствует определенный приоритет от 0 до 255 (в Cisco по умолчанию 0) и IP-адрес BSR.


                Каждому маршрутизатору C-RP соответствует определенный приоритет от 0 до 255 и IP-адрес RP. Маршрутизатор может быть настроен как C-RP для всех групп или только для определенных групп.

                Когда маршрутизатор должен присоединиться к shared tree он анализирует RP-Set полученный от BSR:

                • если для группы только одна C-RP, то соответствующий маршрутизатор выбирается RP,
                • если для группы есть несколько C-RP, то маршрутизатор с наименьшим приоритетом выбирается RP,
                • если для группы есть несколько C-RP с одинаковым приоритетом, то вычисляется хеш-функция. C-RP с большим значением хеш-функции становится RP,
                • если значение хеш-функции одинаковое, то C-RP с наибольшим IP-адресом станет RP.
                • G = Group prefix
                • M = Hash mask
                • C = C-RP address

                Auto-RP это проприетарный функционал на маршрутизаторах Cisco, который позволяет автоматизировать анонсирование информации о группах и RP, которые за них отвечают.

                Auto-RP это функционал который был доступен еще в PIMv1. В PIMv2 появился стандартизированный механизм, который позволяет реализовать аналогичный функционал.

                Для работы Auto-RP в сети надо выбрать и назначить маршрутизаторы:

                Для решения это проблемы есть несколько вариантов:

                • использовать на интерфейсах режим sparse-dense (команда ip pim sparse-dense-mode). Тогда будет использоваться:
                  • режим dense для групп для которых нет RP
                  • режим sparse для групп для которых есть RP
                  • включить глобально на маршрутизаторах auto-rp listener (команда ip pim autorp listener). Тогда будет использоваться:
                    • режим dense для групп 224.0.1.39 и 224.0.1.40
                    • режим sparse для всех остальных групп
                    • конечно этот вариант плох тем, что при попытке настроить динамическое назначение RP, приходит настраивать RP статически. Так что, этот вариант лучше не использовать

                    Anycast RP позволяет балансировать нагрузку между RP для одной и той же группы.

                    По протоколу MSDP RP сообщают друг другу об источниках о которых они знают.

                    На странице PIM-SM в Cisco описан пример работы PIM-SM на примере схемы, которая изображена на рисунке.

                    IGMP Snooping

                    Идея очень простая — коммутатор «слушает» проходящие через него IGMP-пакеты.

                    Для каждой группы отдельно он ведёт таблицу восходящих и нисходящих портов.

                    Если с порта пришёл IGMP Report для группы, значит там клиент, коммутатор добавляет его в список нисходящих для этой группы.

                    Если с порта пришёл IGMP Query для группы, значит там маршрутизатор, коммутатор добавляет его в список восходящих.

                    Таким образом формируется таблица передачи мультикастового трафика на канальном уровне.

                    В итоге, когда сверху приходит мультикастовый поток, он копируется только в нисходящие интерфейсы. Если на 16-портовом коммутаторе только два клиента, только им и будет доставлен трафик.

                    IGMP Snooping

                    IGMP Snooping

                    Гениальность этой идеи заканчивается тогда, когда мы задумываемся о её природе. Механизм предполагает, что коммутатор должен прослушивать трафик на 3-м уровне.

                    Впрочем, IGMP Snooping ни в какое сравнение не идёт с NAT по степени игнорирования принципов сетевого взаимодействия. Тем более, кроме экономии в ресурсах, он несёт в себе массу менее очевидных возможностей. Да и в общем-то в современном мире, коммутатор, который умеет заглядывать внутрь IP — явление не исключительное.

                    Задача № 3

                    пример сети PIM

                    Сервер 172.16.0.5 передает мультикаст трафик на группы 239.1.1.1, 239.2.2.2 и 239.0.0.x.

                    Настроить сеть таким образом, чтобы:

                    • клиент 1 не мог присоединиться к группе 239.2.2.2. Но при этом мог присоединиться к группе 239.0.0.x.
                    • клиент 2 не мог присоединиться к группе 239.1.1.1. Но при этом мог присоединиться к группе 239.0.0.x.

                    R1

                    R2

                    R3

                    R4

                    R5

                    PIM-SM

                    PIM Sparse Mode (PIM-SM) — это один из протоколов из семейства PIM.

                    IGMP Snooping Proxy

                    И происходит это каждую минуту.

                    В этом случае можно настроить проксирование IGMP-запросов. Тогда коммутатор не просто «слушает» проходящие пакеты, он их перехватывает.

                    Правила работы IGMP Snooping могут отличаться для разных производителей. Поэтому рассмотрим их концептуально:

                    1. Если на коммутатор приходит самый первый запрос Report на группу, он отправляется вверх к маршрутизатору, а интерфейс вносится в список нисходящих. Если же такая группа уже есть, интерфейс просто добавляется в список нисходящих, а Report уничтожается.
                    2. Если на коммутатор приходит самый последний Leave, то есть других клиентов нет, этот Leave будет отправлен на маршрутизатор, а интерфейс удаляется из списка нисходящих. В противном случае просто удаляется интерфейс, Leave уничтожается.
                    3. Если IGMP Query приходит от маршрутизатора, коммутатор перехватывает его, отправляет в ответ IGMP Report для всех групп, которые в данный момент имеют получателей.
                      А дальше, в зависимости от настроек и производителя, либо этот же самый Query рассылается во все клиентские порты, либо коммутатор блокирует запрос от маршрутизатора и сам выступает в роли Querier, периодически опрашивая всех получателей.

                    Таким образом снижается и доля лишнего служебного трафика в сети и нагрузка на маршрутизатор.

                    Multicast VLAN Replication

                    Сокращённо MVR. Это механизм для тех провайдеров, кто практикует VLAN-per-user, например.

                    Вот типичный пример сети, где MVR жизненно необходим:

                    Multicast VLAN Replication

                    Multicast VLAN Replication

                    Для решения этой проблемы и был разработан механизм Multicast VLAN Replication.

                    Вводится дополнительный VLAN — Multicast VLAN — в нём, соответственно, будет передаваться мультикастовый поток. Он «проброшен» непосредственно до последнего коммутатора, где трафик из него копируется во все клиентские интерфейсы, которые хотят получать этот трафик — это и есть репликация.

                    В зависимости от реализации репликация из Multicast VLAN может производиться в User-VLAN или в определённые физические интерфейсы.

                    Multicast VLAN Replication

                    Multicast VLAN Replication

                    На оборудовании Cisco MVR и IGMP Snooping настраиваются независимо. То есть можно отключить один и второй будет работать. Вообще же MVR основан на IGMP Snooping и на коммутаторах других производителей для работы MVR может быть обязательным включение IGMP Snooping.

                    Кроме того, IGMP Snooping позволяет осуществлять на коммутаторах фильтрацию трафика, ограничивать количество групп, доступных пользователю, включение IGMP Querier, статическую настройку восходящих портов, перманентное подключение к какой-либо группе (этот сценарий есть в сопутствующем видео), быструю реакцию на изменение топологии путём рассылки дополнительных Query, SSM-Mapping для IGMPv2 и т.д.

                    Заканчивая разговор об IGMP Snooping, хочется повторить — это необязательный функционал — всё и без него будет работать. Но это сделает сеть более предсказуемой, а жизнь инженера спокойнее.

                    Однако все плюсы IGMP Snooping можно обернуть и против себя. Один такой выдающийся случай можно почитать по ссылке.

                    К слову у той же Cisco есть протокол CGMP — аналог IGMP, который не нарушает принципы работы коммутатора, но он проприетарный и не сказать, что широко распространённый.

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

                    Самый простой способ, к которому мы уже не раз обращались в этой статье — запустить плеер, который может принять мультикастовый поток из сети. На нём можно вручную задать IP-адрес группы и наслаждаться видео.

                    Другой программный вариант, который часто используют провайдеры — специальное приложение, обычно весьма кастомное, в котором зашит набор каналов, используемых в сети провайдера. Нет необходимости что-то задавать вручную — нужно просто переключать каналы кнопками.

                    Оба эти способа дают возможность смотреть потоковое видео только на компьютере.

                    Третий же вариант позволяет использовать телевизор, причём как правило, любой. Для этого в доме клиента ставит так называемый Set-Top-Box (STB) — коробочка, устанавливаемая на телевизор. Это шелезяка, которая включается в абонентскую линию и разделяет трафик: обычный юникаст она отдаёт в Ethernet или WiFi, чтобы клиенты имели доступ в Интернет, а мультикастовый поток передаётся на телевизор через кабель (DVI, RGB, антенный итд.).

                    Часто вы, кстати, можете увидеть рекламу, где провайдер предлагает свои приставки для подключения телевидения — это и есть те самые STB

                    Задача 4

                    Напоследок нетривиальная задачка по мультикасту (авторы не мы, в ответах будет ссылка на оригинал).

                    Самая простая схема:

                    С одной стороны сервер-источник, с другой — компьютер, который готов принимать трафик.

                    Адрес мультикастового потока вы можете устанавливать сами.

                    И соответственно, два вопроса:

                    1. Что нужно сделать, чтобы компьютер мог получать поток и при этом не прибегать к мультикастовой маршрутизации?
                    2. Допустим, вы вообще не знаете, что такое мультикаст и не можете его настраивать, как передать поток от сервера к компьютеру?

                    Задача легко ищется в поисковике, но попробуйте решить её сами.

                    Незатронутыми в статье остались междоменная маршрутизация мультикастового трафика (MSDP, MBGP, BGMP), балансировка нагрузки между RP (Anycast RP), PGM, проприетарные протоколы. Но, я думаю, имея как точку старта эту статью, разобраться в остальном не составит труда.

                    Содержание серии статей про мультикаст

                    Читайте также: