25

Введение (можно пропустить)

Отличие Source Specific Multicast от “обычного”(Any Source Multicast(ASM)) в его сигнализации и фильтрации. Формально, существует 3 модели распространения multicast – ASM, SFM(source filtered multicast) и SSM. Но в действительности, с точки зрения запроса мультикаст-трафика со стороны клиента, SSM можно рассматривать как частный случай SFM. Модель SSM подразумевает, что мультикаст группы принадлежат к диапазону адресов 232.0.0.0/8, а IGMPv3 exclude mode запросы не отправляются клиентом и игнорируются свитчами и роутерами, их обрабатывающими.

В классическом варианте, внутри сети оператора используется протокол PIM для распространения мультикаста между роутерами, при этом задействуются RP(точка(и) рандеву) для регистрации источников (S,G) и получения информации о них роутерами, у которых клиенты запросили мультикаст. Использование IGMPv3 в режиме include mode и отказ от exclude mode позволяет избавиться от этих RP, что упрощает конфигурацию сети и, вообще говоря, повышает надёжность(за счёт понижения сложности). Использование адресов 232.0.0.0/8 позволяет роутерам понять что от них хотят, когда вещают или запрашивают мультикаст от них. Получая такой мультикаст(data-трафик), роутер знает, что его не надо регистрировать на RP (сеть может быть смешанная и использовать 1, 2 или 3 модели распространения multicast), а получая IGMPv3 запрос от клиента(include mode) на запрос канала из сети 232.0.0.0/8, роутер не пытается его интерпретировать как ASM с фильтром(т.е. SFM), а сразу шлёт PIM JOIN для построения SPT, если канал (S,G) ранее не был подключен. В терминологии SSM канал определён как (S,G). В общем случае(в зависимости от оборудования) можно изменить диапазон адресов, относящийся к SSM.

Как настроить мультикаст

Эта инструкция предназначена для тех, кто разобрался с настройкой Wi-Fi роутера ASUS RT-N12, RT-N11P или RT-N10, но пока не настроил работу ТВ (впрочем, для других моделей маршрутизаторов ASUS путь будет тем же).

Перед настройкой подключите ТВ приставку к одному из разъемов LAN на тыльной стороне вашего роутера, после чего выполните следующие простые шаги.

1. Зайдите в настройки вашего роутера. Обычно для этого нужно ввести адрес 192.168.1.1 в адресную строку любого браузера и ввести логи и пароль от веб-интерфейса настроек (стандартно — admin и admin соответственно, но обычно при первоначальной настройке роутера логин и пароль изменяются).
2. На главной странице в меню слева выберите пункт «Локальная сеть» (или ЛВС в некоторых вариантах прошивок), а на следующей странице перейдите на вкладку IPTV
3. В разделе «LAN порт» в пункте «Выбор порта IPTV STB» выберите порт LAN на роутере, к которому подключена ТВ приставка провайдера.
4. Примените сделанные настройки.

Примечание: для некоторых популярных провайдеров, в частности для Ростелеком и Билайн для работы телевидения IPTV также может потребоваться включить опции:

• Многоадресная маршрутизация IGMP Proxy
• IGMP Snooping

Сделать это можно на той же странице настроек Wi-Fi роутера ASUS.

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

Возможные проблемы при настройке Wi-Fi роутера

Udpxy — серверное приложение для передачи данных из сетевого потока мультикаст канала (вещаемого по UDP) в HTTP-соединение запрашивающего клиента.

Основная задача udpxy заключается в передаче данных, считанных из мультикаст-канала (рассылающего данные подписчикам по протоколу UDP), в клиентское соединение, работающее в протоколе TCP. Таким образом, клиент, не имея возможности работать с протоколом UDP, может послать запрос udpxy, установить TCP соединение и работать с данными, полученными из указанного (в изначальном запросе) мультикаст-канала. Такая возможность востребована при просмотре IPTV на мобильных устройствах, телевизорах с функциональностью SmartTV и игровых консолях.

Функция Udp Proxy на роутерах Keenetic II реализована в качестве отдельного компонента микропрограммы. Для установки данного компонента необходимо:

1. Заходим в раздел Система, на вкладкеКомпоненты находим пункт UDP-HTTP прокси (udpxy) и отмечаем его галочкой;
2. Нажимаем на кнопку Обновить внизу страницы;

Обратите внимание!

Мультикастовые 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.

Естественно, ни на одной сетевой карте, не может быть настроен такой MAC-адрес, поэтому он никогда не будет в поле Source MAC Ethernet-кадра и никогда не попадёт в таблицу MAC-адресов. Значит такие кадры должны рассылаться как любой Unknown Unicast во все порты VLAN’а.

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

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

Configuring IGMP Proxy

To configure a downstream interface, enable IGMP on that interface. To configure IGMP proxy on the system, complete the following tasks:

1. Enable IP multicasting.
2. Identify the interface that you want to act as the upstream interface.
3. Enable IGMP proxy on that interface.
4. (Optional) Specify how often the system should send unsolicited reports to routers on the upstream interface.
5. (Optional) Specify how long the system should assume that there is an IGMPv1 querier router on the subnet after the system receives an IGMP V1 query on this interface.

    ip igmp-proxy

Use to enable IGMP proxy on an interface.

• The interface for which you enable IGMP proxy is the upstream interface.
• Example

host1(config)#ip multicast-routing

host1(config-if)#ip igmp-proxy

Use the no version to disable IGMP proxy on an interface.

    ip igmp-proxy unsolicited-report-interval

Use to specify how often the upstream interface should transmit unsolicited reports.

host1(config-if)#ip igmp-proxy unsolicited-report-interval 
600

Use the no version to transmit unsolicited reports using the default value, 400 seconds.

    ip igmp-proxy V1-router-present-time

Use to specify how long the system assumes that there is an IGMPv1 querier router on the subnet after the system receives an IGMP V1 query on this interface.

host1(config-if)#ip igmp-proxy V1-router-present-time 600

Use the no version to set the time to the default value, 10 seconds.

IGMP Snooping Proxy

У пытливого читателя может возникнуть вопрос по тому, как IGMP Snooping узнаёт все клиентские порты, учитывая, что на IGMP Query отвечает только один самый быстрый клиент, как мы говорили выше. А очень просто: IGMP Snooping не позволяет сообщениям Report ходить между клиентами. Они отправляются только в восходящие порты к маршрутизаторам. Не видя Report от других получателей этой группы, клиент обязан ответить на Query в течение Max Response Time, указанном в этом Query.

В итоге в сети на 1000 узлов на один IGMP Query в течение секунд 10 (обычное значение Max Response Time) придёт 1000 Report’ов маршрутизатору. Хотя ему достаточно было бы и одного для каждой группы.

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

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

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

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

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

Querier

Рассмотрим чуть более сложный случай:

В клиентский сегмент подключено два (или больше) маршрутизатора, которые могут вещать трафик. Если ничего не сделать, мультикастовый трафик будет дублироваться — оба маршрутизатора ведь будут получать Report от клиентов. Во избежание этого существует механизм выбора Querier — опрашивателя. Тот кто победит, будет посылать Query, мониторить Report и реагировать на Leave, ну и, соответственно, он будет отправлять и трафик в сегмент. Проигравший же будет только слушать 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 меньше.

Тот редкий случай, когда меряются, у кого меньше.

Ещё пара слов о других версиях IGMP

Версия 1 отличается по сути только тем, что в ней нет сообщения Leave. Если клиент не хочет больше получать трафик данной группы, он просто перестаёт посылать Report в ответ на Query. Когда не останется ни одного клиента, маршрутизатор по таймауту перестанет слать трафик.

Во-вторых, что более важно, IGMPv3 стал поддерживать SSM в чистом виде. Это так называемый Source Specific Multicast

В этом случае клиент может не просто запросить группу, но также указать список источников, от которых он хотел бы получать трафик или наоборот не хотел бы. В IGMPv2 клиент просто запрашивает и получает трафик группы, не заботясь об источнике.

Содержимое IGMP Membership Report в IGMPv3

Итак, IGMP предназначен для взаимодействия клиентов и маршрутизатора. Поэтому, возвращаясь к Примеру 2, где нет маршрутизатора, мы можем авторитетно заявить — IGMP там — не более, чем формальность. Маршрутизатора нет, и клиенту не у кого запрашивать мультикастовый поток. А заработает видео по той простой причине, что поток и так льётся от коммутатора — надо только подхватить его.

Напомним, что IGMP не работает для IPv6. Там существует протокол MLD.

Реализация

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

Операционные системы семейств BSD, Linux и Windows поддерживают клиентскую часть протокола. В системе Linux IGMPv3 был добавлен в версии ядра 2.5. Для FreeBSD IGMPv3 был добавлен в версии 8.0.

Для реализации серверной части IGMP в Linux используются демоны, например, mrouted может действовать как IGMP маршрутизатор. Существуют также целые программные комплексы (такие, как XORP), позволяющие превратить обычный компьютер в полнофункциональный маршрутизатор групповой передачи.

В OpenBSD поддержка IGMP в ядре изначально включает в себя базовую поддержку маршрутизации, а имеющиеся в составе ОС демоны mrouted и dvmrpd позволяют решать более сложные задачи (например, туннелирование multicast-трафика).

Рис. 1. Настройка сети с многоадресным источником и получателями

Многоадресный источник подключается к коммутатору 1, который является коммутатором Catalyst 6500 с модулем управления Supervisor Engine 720 с ПО Cisco IOS. Так же надо помнить, что Вам, компания Ветрикс http://vetriks.ru , которая оказывает услуги аутсорсинга информационных технологий сама решает такие проблемы. Получатель 1 подключается к коммутатору 1, а получатель 2 подключается к коммутатору 2. Коммутатор 2 – это коммутатор Catalyst 3750. Между коммутатором 1 и коммутатором 2 существует соединение уровня 2, доступ или магистраль.

В данной настройке можно заметить, что получатель 1, который находится на одном коммутаторе с источником, получает многоадресный поток без затруднений. Однако получатель 2 не получает многоадресного трафика. Цель данного документа – устранить данную проблему.

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

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

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

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

Расчехлили SSH, проверили CPU, проверили утилизацию интерфейсов и волосы дыбом — загрузка почти под 100% на всех интерфейсах одного VLAN’а. Петля! Но откуда ей взяться, если никаких работ не проводилось? Минут 10 проверки и вы заметили, что на восходящем интерфейсе к ядру у вас много входящего трафика, а на всех нисходящих к клиентам — исходящего. Для петли это тоже характерно, но как-то подозрительно: внедрили мультикаст, никаких работ по переключению не делали и скачок только в одном направлении.

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

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

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

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

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

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

Multicast Flooding

Справочная информация

ДокументыЗаконыИзвещенияУтверждения документовДоговораЗапросы предложенийТехнические заданияПланы развитияДокументоведениеАналитикаМероприятияКонкурсыИтогиАдминистрации городовПриказыКонтрактыВыполнение работПротоколы рассмотрения заявокАукционыПроектыПротоколыБюджетные организацииМуниципалитетыРайоныОбразованияПрограммыОтчетыпо упоминаниямДокументная базаЦенные бумагиПоложенияФинансовые документыПостановленияРубрикатор по темамФинансыгорода Российской Федерациирегионыпо точным датамРегламентыТерминыНаучная терминологияФинансоваяЭкономическаяВремяДаты2015 год2016 годДокументы в финансовой сферев инвестиционной

/routing igmp-proxy mfc

Multicast forwarding cache (MFC) status.

• group (IP address) : IGMP group address
• source (IP address) : multicast data originator address
• upstream-interface (interface name) : packet stream is coming in router through this interface
• downstream-interfaces (interface name) : packet stream is going out of router through this interface
• bytes (integer) : total amount of received multicast traffic
• packets (integer) : total amount of received multicast packets
• wrong-packets (integer) : total amount of received multicast packets that arrived on a wrong interface, for example, a multicast stream that is received on a downstream interface instead of upstream interface

Включение функции прослушки

Для того чтобы отслеживать multicast-трафик, требуется сначала включить IGMP snooping и настроить его самостоятельно. Рассмотрим, как это сделать на коммуникаторах D-Link при реализации схемы многоадресной передачи данных. Команды для активизации сетевой прослушки:

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

Для того чтобы исключить порт из сетевой группы, когда коммуникатор получил запрос Leave от клиента, используется функция IGMP Snooping Fast Leave. Она позволяет прекращать передачу ненужных потоков данных по сети с целью ее более эффективной работы. Для активизации этой функции используется следующая команда:

Например, видеосервер, вы хотите отправить видеоконтент нескольким адресатам. Желтые точки — это слишком много хостов, другие компьютеры, подключенные в той же локальной сети, которые не будут получать видео трафик. Для этого необходимо, чтобы видеосервер создал логическую группу многоадресной передачи, например, многоадресный адрес 3, и адресатов, которые должны получать контент, если они регистрируются в той же группе 3, что и приемники. Это гарантирует, что контент отправляется только тем клиентам, которых вы хотите.

Мой ответ: не бойтесь, не сдавайтесь, не торопитесь, чтобы все учиться, делайте это легко и по частям. Моя миссия — облегчить учебу и дать вам направление. Следующий рисунок, это довольно просто, и это точно, хорошо? До следующей статьи или следующего класса.

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

3300/3310/3750/8200RQ

Настройка IGMP Snooping

(QSW)(Config)#set igmp — включение IGMP Snooping

(QSW)(Config)#set igmp vlan 777 — выбор влана

(QSW)(Config)#set igmp fast-leave 777 — включение IGMP Snooping Fast Leave во влане

(QSW)(Config)#set igmp report-suppression 777 — подавление пакетов Report

(QSW)(Config)#set igmp report-suppression source-address 10.10.254.33 — source IP-адрес для отправки IGMP Report 

(QSW)(Config)#interface 1/0/24

(QSW)(Interface 1/0/24)#igmp snooping mrouter-port — настройка mrouter порта

Настройка Querier

(QSW)(Config)#set igmp querier — включение querier

(QSW)(Config)#set igmp querier vlan 777 — выбор влана для querier

(QSW)(Config)#set igmp querier address 10.10.254.33 — ip-адрес querier 

(QSW)(Config)#set igmp querier version 2 — выбор версии IGMP

Настройка ограничения мультикаст групп при помощи аксесс-листа

(QSW)(Config)#access-list 6000 permit any 224.1.1.1 0.0.0.255 — разрешенный диапазон 

(QSW)(Config)#access-list 6000 deny every — запрет для всех остальных групп

(QSW)(Config)#interface 1/0/1

(QSW)(Interface 1/0/1)#ip access-group 6000 in — применения аксесс-листа на клиентском интерфейсе

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

Описание протокола IGMP

В настоящий момент существует три версии этого протокола — IGMP v1 , IGMP v2 , IGMP v3 . Наиболее распространена версия 2.Формат IGMPv2 пакета (Рис. 1):

Рис. 1

Адрес группы представляет собой широковещательный IP-адрес, на который осуществляется рассылка контента. Например, 224.200.200.205.

В IGMPv2 существуют следующие типы сообщений (Рис. 2):

Рис. 2

Маршрутизатор (quierier) периодически посылает в сеть IGMP запрос с типом «Запрос о составе группы» для выяснения состава группы на текущий момент времени. Если ответа от абонентских устройств не последовало, то маршрутизатор отключает эту группу и более не пересылает пакеты для данной группы.

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

Четвертый, и последний тип IGMP-сообщений — это сообщение leave_group. Это сообщение не является обязательным. Маршрутизатор приходит к выводу, что в данную группу рассылки более не входят присоединенные к нему хосты, если ни один хост не отвечает на его сообщение membership_jquery с конкретным групповым адресом.

Реализация

А теперь встаём следующая проблема – как это организовать. Представьте себе, что в сети у провайдера очень много узлов, коммутаторов, маршутизаторов, серверов и есть центральный сервер того же IPTV. Задача сервера отправить трафик таким образом, чтобы он максимально быстро через минимальное количество узлов дошёл до пользователя.

При этом нужно это сделать так, чтобы не образовалось кольцо – когда трафик начинает ходить по кругу и бесконечно. Поэтому путь пакетов будет выглядеть как дерево, да и топология будет использоваться подобная. То есть выходя пакет от сервера он подходит к одному из узлов. Дальше узел должен определить куда дальше отправлять пакет.

А теперь мы подобрались к протоколу IGMP (Internet Group Management Protocol) — это такой протокол, который позволяет быстро подключаться клиенту к ближайшему маршрутизатору. Он сообщает ему, что нужен трафик по тому или иному каналу. Если же запроса к маршрутизатору нет, то он просто простаивает и тем самым высвобождает ресурсы сети.

Также используется PIM (Protocol Independent Multicast) протокол – эта такая система, которая выстраивает адрес от сервера к конечному получателю через одну ветвь дерева. При этом система постоянно мониторит путь, чтобы менять его, если какой-то сегмент выключен или был перемещён.

Проще говоря, сервер транслирует только один сигнал каждого телевизионного канала. И пользователи получают только сигнал того канала, который запросили. Одновременно один сигнал могут получать и несколько приёмников. Именно для этого и нужен протокол IGMP.

Unicast

Тип передачи данных Unicast (индивидуальный) используется для обычной передачи данных от хоста к хосту. Способ Unicast работает в клиент-серверных и пиринговых (peer-to-peer, от равного к равному) сетях.

В unicast пакетах в качестве IP адреса назначения используется конкретный IP адрес устройства, для которого этот пакет предназначен. IP адрес конкретного устройства состоит из порции адреса сети (в которой находится это устройство) и порции адреса хоста (порции, определяющей это конкретное устойчиво в его сети). Это все приводит к возможности маршрутизации unicast пакетов по всей сети.

Multicast и broadcast пакеты, в отличие от unicast пакетов, имеют свои собственные специальные (зарезервированные) IP адреса для использования их в заголовке пакетов в качестве пункта назначения. Из-за этого, broadcast пакеты в основном ограничены пределами локальной сети. Multicast трафик также может быть ограничен границами локальной сети, но с другой стороны также может и маршрутизироваться между сетями.

В IP сетях unicast адрес является адресом, то есть адресом конечного устройства (например, компьютера). Для типа передачи данных unicast, адреса хостов назначаются двум конечным устройствам и используются (эти адреса) как IP адрес источника и IP адрес получателя.

В течение процесса инкапсуляции передающий хост размещает свой IP адрес в заголовок unicast пакета в виде адреса источника, а ИП адрес принимающего хоста размещается в заголовке в виде адреса получателя. Используя эти два IP адреса, пакеты unicast могут передаваться через всю сеть (т.е. через все подсети).

Настройка IPTV + VLC

Все нижеописанные действия по настройке продемонстрированы на примере приложения IPTV от разработчика Александра Софронова и плеера VLC для Android, но вышеперечисленные приложения имеют схожий функционал, и если вы захотите использовать другой клиент для просмотра потокового ТВ, разобраться в нем по аналогии не составит труда. Также, если будут проблемы с воспроизведением видео, полезно ознакомиться с инструкцией .

Установите приложение IPTV:

Установите плеер VLC:

Запустите приложение IPTV. Программа предложит добавить плейлист с каналами. Плейлист – это текстовый файл с расширением «.m3u» или «.xspf», содержащий список адресов потоков на ТВ каналы. Обычно поставщик интернета предоставляет ссылку на него. Плейлисты можно достаточно легко найти в интернете и скачать. После добавления плейлиста программа отобразит все содержащиеся в нем каналы.

Нажмите на желаемый канал и приложение IPTV запустит VLC плеер с выбранным каналом.

На этом можно было бы закончить, если бы не одно «но»!

Много провайдеров предпочитают вещать поток по multicast протоколу (ссылки типа udp://), так как он по сравнению с unicast’ом (обычно https:// протокол) позволяет существенно оптимизировать занимаемую ширину канала, вещая поток всем, а не создавать отдельные сессии для каждого телезрителя.

К сожалению, много устройств на Android не поддерживают UDP-multicast потоки, кроме нескольких моделей, у которых udpxy вшит в прошивку.

Для передачи IPTV на Android устройства нужна система транскодирования, которая будет передавать IPTV не multicast’ом, а потоком поверх HTTP.

Современные роутеры с прошивкой на основе Linux типа DD-WRT и Open-WRT уже имеют подобную систему, но если у вас бюджетный роутер без поддержки транскодирования, можно организовать собственный прокси с помощью компьютера, подключенного в общую сеть с устройством на Android.

Для операционных систем Windows нужно скачать программу UDP-to-HTTP Proxy .

Для операционных систем семейства Linux UDP-to-HTTP Proxy сервер находится .

Настройка UDP-to-HTTP Proxy (Windows)

Настройка программы заключается в указании IP-адресов интерфейса UDP-мультикаста и интерфейса HTTP-сервера. Для случая, если ваш компьютер и устройство на Android находятся в одной сети, это один и тот же адрес и равен он IP-адресу вашего ПК. Раскройте список «Интерфейс мультикаста», он уже должен содержать IP-адрес компьютера (последний в списке).

Нажмите на кнопку «Запустить».

Сервер запущен, теперь переходим к настройкам на Android-устройстве.

Настройка IP-TV на роутерах

В данном разделе описаны эти принципы.

Примечание. Если вы не хотите заниматься этим самостоятельно, передайте компьютерную сеть на ИТ аутсорсинг В данном разделе приведено простое и четкое объяснение, касающееся данной конкретной проблемы. Подробное объяснение этих терминов см. в разделе Дополнительные сведения данного документа.

Протокол IGMP

IGMP – это протокол, который обязывает конечные хосты (получатели) сообщить многоадресному маршрутизатору (опросчику IGMP) о намерении конечного хоста получать определенный многоадресный трафик. То есть, это протокол, использующийся между маршрутизатором и конечными хостами и позволяющий:

Маршрутизаторам запрашивать конечные хосты о потребности в определенном многоадресном потоке (запрос IGMP)

Конечным хостам сообщать и отвечать маршрутизатору о потребности в определенном многоадресном потоке (отчеты IGMP)

Функция отслеживания IGMP

Функция отслеживания IGMP – это механизм посылки многоадресного трафика только на те порты, к которым подключены получатели. Данный механизм увеличивает эффективность, так как он позволяет коммутатору уровня 2 избирательно рассылать многоадресные пакеты только на те порты, которые в них нуждаются. Без функции отслеживания IGMP маршрутизатор отправляет пакеты на каждый порт. Коммутатор следит за обменом сообщениями IGMP между маршрутизатором и конечными хостами. В данном случае коммутатор создает таблицу отслеживания IGMP, в которой присутствует список всех портов, которые запросили определенную группу многоадресной передачи.

Порт Mrouter

Порт mrouter – это порт с точки зрения коммутатора, который подключается к многоадресному маршрутизатору. Необходимо присутствие, по крайней мере, одного порта mrouter для работы коммутаторов по отслеживанию IGMP. Это требование подробно описано в разделе Общие сведения о проблеме и ее решения данного документа.

Многоадресная рассылка на L2

Любой IP-трафик версии 4 (IPv4) с IP-адресом назначения в диапазоне от 224.0.0.0 до 239.255.255.255 является многоадресным потоком. Все многоадресные пакеты IPv4 соответствуют предварительно определенному MAC-адресу IEEE с форматом 01.00.5e.xx.xx.xx.

Примечание. Функция отслеживания IGMP действует в случае, если MAC-адреса многоадресной рассылки соответствуют IEEE-совместимому MAC-диапазону. Согласно разработке данной функции, отслеживание некоторых зарезервированных диапазонов многоадресной рассылки не предполагается. Если не соответствующий критериям многоадресный пакет исходит из коммутируемой сети, он отправляется через эту VLAN, где расценивается как широковещательный трафик.

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

В этом примере источник Source-A отправляет данные по адресам 224.1.1.1, 224.1.1.2 и 224.1.1.3. Источник Source-B отправляет данные по адресам 224.2.2.2, 224.2.2.3 и 224.2.2.4. Один из маршрутизаторов — RP 1 или RP 2 — может быть процессором маршрутизации для всех групп. Однако, если вы хотите, чтобы разные процессоры маршрутизации обрабатывали разные группы, все маршрутизаторы должны включать группы, которые будет обслуживать процессор маршрутизации. Для этого типа конфигурации статического процессора маршрутизации необходимо, чтобы на всех маршрутизаторах домена PIM были настроены одинаковые команды ip pim rp-addressaddress acl. Кроме того, для создания подобной конфигурации можно использовать более простую в настройке функцию .

ip multicast-routing 
 
ip pim RP-address 1.1.1.1 2
ip pim RP-address 2.2.2.2 3 
 
access-list 2 permit 224.1.1.1 
access-list 2 permit 224.1.1.2 
access-list 2 permit 224.1.1.3
access-list 3 permit 224.2.2.2 
access-list 3 permit 224.2.2.3 
access-list 3 permit 224.2.2.4

ip multicast-routing
  
ip pim RP-address 1.1.1.1 2 
ip pim RP-address 2.2.2.2  3
 
access-list 2 permit 224.1.1.1 
access-list 2 permit 224.1.1.2 
access-list 2 permit 224.1.1.3 
access-list 3 permit 224.2.2.2 
access-list 3 permit 224.2.2.3 
access-list 3 permit 224.2.2.4 

ip multicast-routing 
ip pim RP-address 1.1.1.1  2 
ip pim RP-address 2.2.2.2  3
 

access-list 2 permit 224.1.1.1 
access-list 2 permit 224.1.1.2 
access-list 2 permit 224.1.1.3 
access-list 3 permit 224.2.2.2 
access-list 3 permit 224.2.2.3 
access-list 3 permit 224.2.2.4