Вход в личный кабинет Что такое многоадресная рассылка?
Многоадресная рассылка, или Multicast — это способ передачи данных по сетям IPv4, который обеспечивает доставку единого потока информации одновременно тысячам частных или корпоративных пользователей. Работа в режиме Multicast предусматривает, что отправитель передает пакеты данных выбранной группе адресатов. При этом допускается подключение этих адресатов к разным подсетям.
Протокол IPv4 предполагает организацию отправки пакетов тремя способами:
- адресация определенному устройству;
- широковещательная рассылка;
- многоадресная рассылка.
В первом случае трафик передается только на конкретный компьютер. Этот способ позволяет пользователю выполнять значительную часть действий в интернете. Однако передача конкретному устройству потокового видео или других массивных объемов данных приведет к повышенной нагрузке на сеть.
Широковещательная рассылка предполагает передачу данным от отправителя все подключенным к конкретной сети хостам. Сегодня этот метод используется редко, поскольку создает помехи для передачи других видов трафика.
Оптимальным решением становится многоадресная рассылка, при которой пакеты доставляются каждому подключенному к сети с определенным адресом хосту. Это дает значительную экономию полосы пропускания и снижает нагрузку на сеть.
При многоадресной рассылке сообщения отправляются на адрес группы Multicast, не имеющей географических и физических ограничений — то есть узлы могут быть расположены в разных странах и регионах. Главное, чтобы они были подписаны на рассылку (присоединены к группе). Для присоединения к группе Multicast и используется протокол IGMP.
Igmp: what is behind the internet group management protocol
It has already been mentioned that group administration via IGMP is not the responsibility of the package sender. However, as with all other stations on the network (including the receiver) involved, this output host must support multicast connections. Receiving client requests for inclusion in a specific multicast group and notifying clients in the event of incoming multicast data streams is handled by the individual network routers on the path between the sender and receiver.
For this purpose, the Internet Group Management Protocol offers functions that a station can use to inform the router assigned to it that it is to be included in a multicast group. On the other hand, it enables the routers to remember outgoing interfaces of those receiver devices that are to receive certain IP multicast data streams to be able to send specific reports as soon as corresponding data is received. Multicast groups are characterized by their specific addresses from the 224.0.0x range. In most cases, the first point of contact for a device is the home internet router, which receives the membership application and forwards it to the next network node, typically the internet service provider’s router. This communication chain ends with the router of the data stream transmitter, which in turn duplicates the IP packet if required, if it has several outgoing interfaces to serve.
Pim sparse mode
За помощь в подготовке статьи спасибо JDima.За техническую поддержку спасибо Наташе Самойленко.КДПВ нарисована Ниной Долгополовой – замечательным художником и другом проекта.
В пуле статей СДСМ ещё много интересного до окончания, поэтому не нужно хоронить цикл из-за долгого отсутствия выпуска – с каждой новой статьёй сложность значительно возрастает. Впереди почти весь MPLS, IPv6, QoS и дизайн сетей.
Source addresses in igmpv3 reports for asm groups
IGMP extended access lists also can be used to permit or filter (deny) traffic based on (0.0.0.0, G), that is, (*, G) in IGMP reports that are non-SSM, such as Any Source Multicast (ASM).
Общее понимание multicast
Как известно, существуют следующие типы трафика:
Unicast
– одноадресная рассылка – один отправитель, один получатель. (
Пример i
Начнём с самого простого случая:
Пример ii
Добавим в схему коммутатор и ещё несколько клиентов:
Мультикастовый сервер по-прежнему вещает для группы 224.2.2.4. На коммутаторе все 4 порта должны быть в одном VLAN. Трафик приходит на коммутатор и по умолчанию рассылается во все порты одного VLAN’а. Значит все клиенты получают этот трафик. На них на всех в видеопроигрывателе так же указан групповой адрес 224.2.2.4.
В данной ситуаци трафик будут получать даже те, кто этого в общем-то и не хотел, то есть на нём не запущен ни плеер, ни что бы то ни было другое. Но только, если он в том же VLAN’е. Позже мы разберёмся, как с этим бороться.
Обратите внимание, что в данном случае от сервера-источника приходит только одна копия трафика на коммутатор, а не по отдельной копии на каждого клиента. И в нашем примере с SD каналами загрузка порта между источником и коммутатором будет не 1,2 Гб/с, а всего 60 Мб/с (2Мб/с * 30 каналов).
Собственно говоря, весь этот огромный диапазон (224.0.0.0-239.255.255.255) можно использовать. Ну, почти весь – первые адреса (диапазон 224.0.0.0/23) всё-таки зарезервированы под известные протоколы.
[
p15=”#unknown”>Список зарезервированных IP-адресов]Диапазон 224.0.0.0/24 зарезервирован под link-local коммуникации.
Мультикастовые пакеты с такими адресами назначения не могут выходить за пределы одного широковещательного сегмента. Диапазон 224.0.1.0/24 зарезервирован под протоколы, которым необходимо передавать мультикаст по всей сети, то есть проходить через маршрутизаторы.
Теория igmp – сети для самых маленьких
При отладке или в дампе, кстати, можно видеть, что между получением различных Report может пройти несколько секунд.
Сделано это для того, чтобы сотни клиентов все скопом не наводнили сеть своими пакетам Report, получив General Query. Более того, только один клиент обычно отправляет Report.
Дело в том, что Report отсылается на адрес группы, а следовательно доходит и до всех клиентов. Получив Report от другого клиента для этой же группы, узел не будет отправлять свой. Логика простая: маршрутизатор и так уже получил этот самый Report и знает, что клиенты есть, больше ему не надо.
Этот механизм называется
§
Выборы происходят довольно просто и интуитивно понятно.
Рассмотрим ситуацию с момента включения маршрутизаторов R1 и R2.
1) Активировали IGMP на интерфейсах.
2) Сначала по умолчанию каждый из них считает себя Querier.
3) Каждый отправляет IGMP General Query в сеть. Главная цель — узнать, есть ли клиенты, а параллельно — заявить другим маршрутизаторам в сегменте, если они есть, о своём желании участвовать в выборах.
4) General Query получают все устройства в сегменте, в том числе и другие IGMP-маршрутизаторы.
5) Получив такое сообщение от соседа, каждый маршрутизатор оценивает, кто достойнее.
6) Побеждает маршрутизатор с меньшим IP (указан в поле Source IP пакета IGMP Query). Он становится Querier, все другие — Non-Querier.
7) Non-Querier запускает таймер, который обнуляется каждый раз, как приходит Query с меньшим IP-адресом. Если до истечения таймера (больше 100 секунд: 105-107) маршрутизатор не получит Query с меньшим адресом, он объявляет себя Querier и берёт на себя все соответствующие функции.
8) Если Querier получает Query с меньшим адресом, он складывает с себя эти обязанности. Querier’ом становится другой маршрутизатор, у которого IP меньше.
§
§
1. Первым делом маршрутизатор отправил свой IGMP General Query после включения IGMP на его интерфейсе, чтобы узнать, есть ли получатели и заявить о своём желании быть Querier. На тот момент никого не было в этой группе.
2. Далее появился клиент, который захотел получать трафик группы 224.2.2.4 и он отправил свой IGMP Report. После этого пошёл трафик на него, но он отфильтрован из дампа.3. Потом маршрутизатор решил зачем-то проверить — а нет ли ещё клиентов и отправил IGMP General Query ещё раз, на который клиент вынужден ответить (4).
5. Периодически (раз в минуту) маршрутизатор проверяет, что получатели по-прежнему есть, с помощью IGMP General Query, а узел подтверждает это с помощью IGMP Report.
6. Потом он передумал и отказался от группы, отправив IGMP Leave.
7. Маршрутизатор получил Leave и, желая убедиться, что больше никаких других получателей нет, посылает IGMP Group Specific Query… дважды. И по истечении таймера перестаёт передавать трафик сюда.
8. Однако передавать IGMP Query в сеть он по-прежнему продолжает. Например, на тот случай, если вы плеер не отключали, а просто где-то со связью проблемы. Потом связь восстанавливается, но клиент-то Report не посылает сам по себе. А вот на Query отвечает. Таким образом поток может восстановиться без участия человека.
§