Версия 3 поддерживает всё то, что поддерживает IGMPv2, но есть и ряд изменений. Во-первых, Report отправляется уже не на адрес группы, а на мультикастовый служебный адрес 224.0.0.22 . А адрес запрашиваемой группы указан только внутри пакета. Делается это для упрощения работы IGMP Snooping, о котором мы поговорим .

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

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

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

Повторим ещё раз

*Дамп отфильтрован по IGMP* .


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 отвечает. Таким образом поток может восстановиться без участия человека.

И ещё раз

Подробное описание всех терминов IGMP .

PIM

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

Существует несколько протоколов маршрутизации мультикастового трафика: DVMRP , MOSPF , CBT - все они по-разному решают такую задачу. Но стандартом де факто стал PIM - Protocol Independent Multicast .
Другие подходы настолько нежизнеспособны, что порой даже их разработчики практически признают это. Вот, например, выдержка из RFC по протоколу CBT:
CBT version 2 is not, and was not, intended to be backwards compatible with version 1; we do not expect this to cause extensive compatibility problems because we do not believe CBT is at all widely deployed at this stage.

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

• PIM Dense Mode (DM)
• PIM Sparse Mode (SM)

PIM Dense Mode

Но через некоторое время в эту же ветку маршрутизатор снова пытается отправить мультикаст - вдруг там появились получатели. Если не появились, ветка снова отрезается на определённый период. Если клиент на маршрутизаторе появился в промежутке между этими двумя событиями, отправляется сообщение Graft - маршрутизатор запрашивает отрезанную ветку обратно, чтобы не ждать, пока ему что-то перепадёт.
Как видите, здесь не стоит вопрос определения пути к получателям - трафик достигнет их просто потому, что он везде.
После «обрезания» ненужных ветвей остаётся дерево, вдоль которого передаётся мультикастовый трафик. Это дерево называется SPT - Shortest Path Tree .

Оно лишено петель и использует кратчайший путь от получателя до источника. По сути оно очень похоже на Spanning Tree в STP , где корнем является источник.

SPT - это конкретный вид дерева - дерево кратчайшего пути. А вообще любое мультикастовое дерево называется .

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

Что нам действительно важно сейчас - это механизм избежания петель.
Представим такую сеть:

Один источник, один получатель и простейшая IP-сеть между ними. На всех маршрутизаторах запущен PIM DM.

Что произошло бы, если бы не было специального механизма избежания петель?
Источник отправляет мультикастовый трафик. R1 его получает и в соответствии с принципами PIM DM отправляет во все интерфейсы, кроме того, откуда он пришёл - то есть на R2 и R3.

R2 поступает точно так же, то есть отправляет трафик в сторону R3. R3 не может определить, что это тот же самый трафик, который он уже получил от R1, поэтому пересылает его во все свои интерфейсы. R1 получит копию трафика от R3 и так далее. Вот она - петля.

Что же предлагает PIM в такой ситуации? RPF - Reverse Path Forwarding . Это главный принцип передачи мультикастового трафика в PIM (любого вида: и DM и SM) - трафик от источника должен приходить по кратчайшему пути.
То есть для каждого полученного мультикастового пакета производится проверка на основе таблицы маршрутизации, оттуда ли он пришёл.

1) Маршрутизатор смотрит на адрес источника мультикастового пакета.
2) Проверяет таблицу маршрутизации, через какой интерфейс доступен адрес источника.
3) Проверяет интерфейс, через который пришёл мультикастовый пакет.
4) Если интерфейсы совпадают - всё отлично, мультикастовый пакет пропускается, если же данные приходят с другого интерфейса - они будут отброшены.
В нашем примере R3 знает, что кратчайший путь до источника лежит через R1 (статический или динамический маршрут). Поэтому мультикастовые пакеты, пришедшие от R1, проходят проверку и принимаются R3, а те, что пришли от R2, отбрасываются.

Такая проверка называется RPF-Check и благодаря ей даже в более сложных сетях петли в MDT не возникнут.
Этот механизм важен нам, потому что он актуален и в PIM-SM и работает там точно также.
Как видите, PIM опирается на таблицу юникастовой маршрутизации, но, во-первых, сам не маршрутизирует трафик, во-вторых, ему не важно, кто и как наполнял таблицу.

Останавливаться здесь и подробно рассматривать работу PIM DM мы не будем - это устаревший протокол с массой недостатков (ну, как RIP).

Однако PIM DM может применяться в некоторых случаях. Например, в совсем небольших сетях, где поток мультикаста небольшой.

PIM Sparse Mode

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


Из настроек на R1 надо включить возможность маршрутизации мультикаста, PIM SM на двух интерфейсах (в сторону источника и в сторону клиента) и IGMP в сторону клиента. Помимо прочих базовых настроек, конечно (IP, IGP).

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

R1(config)#ip multicast-routing R1(config)#int fa0/0 R1(config-if)#ip pim sparse-mode R1(config-if)#int fa1/0 R1(config-if)#ip pim sparse-mode

Cisco тут как обычно отличается своим особенным подходом: при активации PIM на интерфейсе, автоматически активируется и IGMP. На всех интерфейсах, где активирован PIM, работает и IGMP.
В то же время у других производителей два разных протокола включаются двумя разными командами: отдельно IGMP, отдельно PIM.
Простим Cisco эту странность? Вместе со всеми остальными?

Плюс, возможно, потребуется настроить адрес RP (ip pim rp-address 172.16.0.1 , например). Об этом позже, пока примите как данность и смиритесь.

После того, как на источнике вы запустите вещание, надо проверить таблицу ещё раз.

Давайте разберём этот немногословный вывод.

Запись вида (*, 225.0.1.1) называется , /читается старкомаджи / и сообщает нам о получателях. Причём не обязательно речь об одном клиенте-компьютере, вообще это может быть и, например, другой PIM-маршрутизатор. Важно то, в какие интерфейсы надо передавать трафик.
Если список нисходящих интерфейсов (OIL) пуст - Null , значит нет получателей - а мы их пока не запускали.

Запись (172.16.0.5, 225.0.1.1) называется , /читается эскомаджи / и говорит о том, что известен источник. В нашем случае источник с адресом 172.16.0.5 вещает трафик для группы 224.2.2.4. Мультикастовый трафик приходит на интерфейс FE0/1 - это восходящий (Upstream ) интерфейс.

Итак, нет клиентов. Трафик от источника доходит до маршрутизатора и на этом его жизнь кончается. Давайте добавим теперь получателя - настроим приём мультикаста на ПК.
ПК отсылает IGMP Report, маршрутизатор понимает, что появились клиенты и обновляет таблицу мультикастовой маршрутизации.
Теперь она выглядит так:

Появился и нисходящий интерфейс: FE0/0, что вполне ожидаемо. Причём он появился как в (*, G), так и в (S, G). Список нисходящих интерфейсов называется OIL - Outgoing Interface List .

Добавим ещё одного клиента на интерфейс FE1/0:

(S, G): Когда мультикастовый трафик с адресом назначения 224.2.2.4 от источника 172.16.0.5 приходит на интерфейс FE0/1, его копии нужно отправить в FE0/0 и FE1/0.

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

Чтобы разобраться с тем, что такое PIM, обратимся к сети гораздо более сложной

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

Но пока не запущен PIM, IGMP, клиенты не запрашивают каналы.

Итак, момент времени 0.

Включаем мультикастовую маршрутизацию на всех пяти маршрутизаторах:

RX(config)#ip multicast-routing
PIM включается непосредственно на всех интерфейсах всех маршрутизаторов (в том числе на интерфейсе в сторону Сервера-источника и клиентов):

RX(config)#int FEX/X RX(config-if)#ip pim sparse-mode

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

Первое, что делает PIM - устанавливает соседство. Для этого используются сообщения . При активации PIM на интерфейсе с него отправляется PIM Hello на адрес 224.0.0.13 с TTL равным 1. Это означает, что соседями могут быть только маршрутизаторы, находящиеся в одном широковещательном домене.

Как только соседи получили приветствия друг от друга:

Теперь они готовы принимать заявки на мультикастовые группы.

Если мы сейчас запустим в вольер клиентов с одной стороны и включим мультикастовый поток с сервера с другой, то R1 получит поток трафика, а R4 получит IGMP Report при попытке клиента подключиться. В итоге R1 не будет знать ничего о получателях, а R4 об источнике.

Неплохо было бы если бы информация об источнике и о клиентах группы была собрана где-то в одном месте. Но в каком?

Такая точка встречи называется Rendezvous Point - RP . Это центральное понятие PIM SM. Без неё ничего бы не работало. Здесь встречаются источник и получатели.
Все PIM-маршрутизаторы должны знать, кто является RP в домене, то есть знать её IP-адрес.

Чтобы построить дерево MDT, в сети выбирается в качестве RP некая центральная точка, которая,

1. отвечает за изучение источника,
2. является точкой притяжения сообщений Join от всех заинтересованных.

Пусть пока R2 будет выполнять роль RP.
Чтобы увеличить надёжность, обычно выбирается адрес Loopback-интерфейса. Поэтому на всех маршрутизаторах выполняется команда:
RX(config)#ip pim rp-address 2.2.2.2
Естественно, этот адрес должен быть доступен по таблице маршрутизации со всех точек.
Ну и поскольку адрес 2.2.2.2 является RP, на интерфейсе Loopback 0 на R2 желательно тоже активировать PIM.

R2(config)#interface Loopback 0 RX(config-if)#ip pim sparse-mode

Сразу после этого R4 узнает об источнике трафика для группы 224.2.2.4:

И даже передаёт трафик:

На интерфейс FE0/1 приходит 362000 б/с, и через интерфейс FE0/0 они передаются.

Всё, что мы сделали:
Включили возможность маршрутизации мультикастового трафика (ip multicast-routing )
Активировали PIM на интерфейсах (ip pim sparse-mode )
Указали адрес RP (ip pim rp-adress X.X.X.X )

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

Разбор полётов

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

1) Клиент 1 отправляет IGMP Report для группы 224.2.2.4

2) R4 получает этот запрос, понимает, что есть клиент за интерфейсом FE0/0, добавляет этот интерфейс в OIL и формирует запись (*, G).

Здесь видно восходящий интерфейс FE0/1, но это не значит, что R4 получает трафик для группы 224.2.2.4. Это говорит лишь о том, что единственное место, откуда сейчас он может получать - FE0/1, потому что именно там находится RP. Кстати, здесь же указан и сосед, который прошёл RPF-Check - R2: 10.0.2.24. Ожидаемо.

R4 называется - LHR (Last Hop Router) - последний маршрутизатор на пути мультикастового трафика, если считать от источника. Иными словами - это маршрутизатор, ближайший к получателю. Для Клиента1 - это R4, для Клиента2 - это R5.

3) Поскольку на R4 пока нет мультикастового потока (он его не запрашивал прежде), он формирует сообщение PIM Join и отправляет его в сторону RP (2.2.2.2).

PIM Join отправляется мультикастом на адрес 224.0.0.13. «В сторону RP» означает через интерфейс, который указан в таблице маршрутизации, как outbound для того адреса, который указан внутри пакета. В нашем случае это 2.2.2.2 - адрес RP. Такой Join обозначается ещё как Join (*,G) и говорит: «Не важно, кто источник, мне нужен трафик группы 224.2.2.4».
То есть каждый маршрутизатор на пути должен обработать такой Join и при необходимости отправить новый Join в сторону RP. (Важно понимать, что если на маршрутизаторе уже есть эта группа, он не будет отправлять выше Join - он просто добавит интерфейс, с которого пришёл Join, в OIL и начнёт передавать трафик).
В нашем случае Join ушёл в FE0/1:

4) R2, получив Join, формирует запись (*, G) и добавляет интерфейс FE0/0 в OIL. Но Join отсылать уже некуда - он сам уже RP, а про источник пока ничего не известно.

Таким образом RP узнаёт о том, где находятся клиенты.

Если Клиент 2 тоже захочет получать мультикастовый трафик для той же группы, R5 отправит PIM Join в FE0/1, потому что за ним находится RP, R3, получив его, формирует новый PIM Join и отправляет в FE1/1 - туда, где находится RP.
То есть Join путешествует так узел за узлом, пока не доберётся до RP или до другого маршрутизатора, где уже есть клиенты этой группы.

Итак, R2 - наш RP - сейчас знает о том, что за FE0/0 и FE1/0 у него есть получатели для группы 224.2.2.4.
Причём неважно, сколько их там - по одному за каждым интерфейсом или по сто - поток трафика всё равно будет один на интерфейс.

Если изобразить графически то, что мы получили, то это будет выглядеть так:

Отдалённо напоминает дерево, не так ли? Поэтому оно так и называется - RPT - Rendezvous Point Tree . Это дерево с корнем в RP, а ветви которого простираются до клиентов.
Более общий термин, как мы упоминали выше, - MDT - Multicast Distribution Tree - дерево, вдоль которого распространяется мультикастовый поток. Позже вы увидите разницу между MDT и RPT.

5) Теперь врубаем сервер. Как мы уже выше обсуждали, он не волнуется о PIM, RP, IGMP - он просто вещает. А R1 получает этот поток. Его задача - доставить мультикаст до RP.
В PIM есть специальный тип сообщений - Register . Он нужен для того, чтобы зарегистрировать источник мультикаста на RP.
Итак, R1 получает мультикастовый поток группы 224.2.2.4:

R1 является FHR (First Hop Router) - первый маршрутизатор на пути мультикастового трафика или ближайший к источнику.

Обратите внимание на стек протоколов. Поверх юникастового IP и заголовка PIM идёт изначальный мультикастовый IP, UDP и данные.
Теперь, в отличие от всех других, пока известных нам сообщений PIM, в адресе получателя указан 2.2.2.2, а не мультикастовый адрес.

Такой пакет доставляется до RP по стандартным правилам юникастовой маршрутизации и несёт в себе изначальный мультикастовый пакет, то есть это… это же туннелирование!

На сервере 172.16.0.5 работает приложение, которое может передавать пакеты только на широковещательный адрес 255.255.255.255, с портом получателя UDP 10999.

Этот трафик надо доставить к клиентам 1 и 2:
Клиенту 1 в виде мультикаст трафика с адресом группы 239.9.9.9.
А в сегмент клиента 2, в виде широковещательных пакетов на адрес 255.255.255.255.

Замечание к топологии : в этой задаче только маршрутизаторы R1, R2, R3 находятся под управлением администраторов нашей сети. То есть, конфигурацию изменять можно только на них.

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

Настроить сеть таким образом, чтобы трафик группы 239.1.1.1 не передавался в сегмент между R3 и R5, и во все сегменты ниже R5.
Но при этом, трафик группы 239.2.2.2 должен передаваться без проблем.

То же, что Source DR, только для получателей мультикастового трафика - LHR (Last Hop Router) .
Пример топологии:

Receiver DR ответственен за отправку на RP PIM Join. В вышеприведённой топологии, если оба маршрутизатора отправят Join, то оба будут получать мультикастовый трафик, но в этом нет необходимости. Только DR отправляет Join. Второй просто мониторит доступность DR.
Поскольку DR отправляет Join, то он же и будет вещать трафик в LAN. Но тут возникает закономерный вопрос - а что, если PIM DR"ом стал один, а IGMP Querier"ом другой? А ситуация-то вполне возможна, ведь для Querier чем меньше IP, тем лучше, а для DR, наоборот.
В этом случае DR"ом выбирается тот маршрутизатор, который уже является Querier и такая проблема не возникает.

Правила выбора Receiver DR точно такие же, как и Source DR.

Проблема двух одновременно передающих маршрутизаторов может возникнуть и в середине сети, где нет ни конечных клиентов, ни источников - только маршрутизаторы.
Очень остро этот вопрос стоял в PIM DM, где это была совершенно рядовая ситуация из-за механизма Flood and Prune.
Но и в PIM SM она не исключена.
Рассмотрим такую сеть:

Здесь три маршрутизатора находятся в одном сегменте сети и, соответственно, являются соседями по PIM. R1 выступает в роли RP.
R4 отправляет PIM Join в сторону RP. Поскольку этот пакет мультикастовый он попадает и на R2 и на R3, и оба они обработав его, добавляют нисходящий интерфейс в OIL.
Тут бы должен сработать механизм выбора DR, но и на R2 и на R3 есть другие клиенты этой группы, и обоим маршрутизаторам так или иначе придётся отправлять PIM Join.
Когда мультикастовый трафик приходит от источника на R2 и R3, в сегмент он передаётся обоими маршрутизаторами и задваивается там. PIM не пытается предотвратить такую ситуацию - тут он действует по факту свершившегося преступления - как только в свой нисходящий интерфейс для определённой группы (из списка OIL) маршрутизатор получает мультикастовый трафик этой самой группы, он понимает: что-то не так - другой отправитель уже есть в этом сегменте.

Тогда маршрутизатор отправляет специальное сообщение .
Такое сообщение помогает выбрать PIM Forwarder - тот маршрутизатор, который вправе вещать в данном сегменте.

Не надо его путать с PIM DR. Во-первых, PIM DR отвечает за отправку сообщений PIM Join и Prune , а PIM Forwarder - за отправку трафика . Второе отличие - PIM DR выбирается всегда и в любых сетях при установлении соседства, А PIM Forwrder только при необходимости - когда получен мультикастовый трафик с интерфейса из списка OIL.

Выбор RP

Но представим совершенно невозможную в современных сетях ситуацию - R2 вышел из строя. Это всё - финиш. Клиент 2 ещё будет работать, поскольку произошёл SPT Switchover, а вот всё новое и всё, что шло через RP сломается, даже если есть альтернативный путь.
Ну и нагрузка на администратора домена. Представьте себе: на 50 маршрутизаторах перебить вручную как минимум одну команду (а для разных групп ведь могут быть разные RP).

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

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

Надо на самом деле отдать должное протоколу Auto-RP. Он был спасением в прежние времена. Но с появлением открытого и гибкого Bootstrap, он закономерно уступил свои позиции.

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

Чтобы информировать все мультикастовые маршрутизаторы домена о существующих RP вводится механизм BSR - BootStrap Router . Претендентов может быть несколько, как и C-RP. Они называются соответственно C-BSR . Настраиваются они похожим образом.

Пусть BSR у нас будет один и для теста (исключительно) это будет R1.
R1(config)interface Loopback 0 R1(config-if)ip pim sparse-mode R1(config-if)exit R1(config)#ip pim bsr-candidate loopback 0
Сначала из всех C-BSR выбирается один главный BSR, который и будет всем заправлять. Для этого каждый C-BSR отправляет в сеть мультикастовый BootStrap Message (BSM) на адрес 224.0.0.13 - это тоже пакет протокола PIM. Его должны принять и обработать все мультикастовые маршрутизаторы и после разослать во все порты, где активирован PIM. BSM передаётся не в сторону чего-то (RP или источника), в отличии, от PIM Join, а во все стороны. Такая веерная рассылка помогает достигнуть BSM всех уголков сети, в том числе всех C-BSR и всех C-RP. Для того, чтобы BSM не блуждали по сети бесконечно, применяется всё тот же механизм RPF - если BSM пришёл не с того интерфейса, за которым находится сеть отправителя этого сообщения, такое сообщение отбрасывается.

С помощью этих BSM все мультикастовые маршрутизаторы определяют самого достойного кандидата на основе приоритетов. Как только C-BSR получает BSM от другого маршрутизатора с бОльшим приоритетом, он прекращает рассылать свои сообщения. В результате все обладают одинаковой информацией.

На этом этапе, когда выбран BSR, благодаря тому, что его BSM разошлись уже по всей сети, C-RP знают его адрес и юникастом отправляют на него сообщения Candidte-RP-Advertisement , в которых они несут список групп, которые они обслуживают - это называется group-to-RP mapping . BSR все эти сообщения агрегирует и создаёт RP-Set - информационную таблицу: какие RP каждую группу обслуживают.

Далее BSR в прежней веерной манере рассылает те же BootStrap Message, которые на этот раз содержат RP-Set. Эти сообщения успешно достигают всех мультикастовых маршрутизаторов, каждый из которых самостоятельно делает выбор, какую RP нужно использовать для каждой конкретной группы.

BSR периодически делает такие рассылки, чтобы с одной стороны все знали, что информация по RP ещё актуальна, а с другой C-BSR были в курсе, что сам главный BSR ещё жив.
RP, кстати, тоже периодически шлют на BSR свои анонсы Candidate-RP-Advertisement.

Фактически всё, что нужно сделать для настройки автоматического выбора RP - указать C-RP и указать C-BSR - не так уж много работы, всё остальное за вас сделает PIM.
Как всегда, в целях повышения надёжности рекомендуется указывать интерфейсы Loopback в качестве кандидатов.

Завершая главу PIM SM, давайте ещё раз отметим важнейшие моменты

1. Должна быть обеспечена обычная юникастовая связность с помощью IGP или статических маршрутов. Это лежит в основе алгоритма RPF.
2. Дерево строится только после появления клиента. Именно клиент инициирует построение дерева. Нет клиента - нет дерева.
3. RPF помогает избежать петель.
4. Все маршрутизаторы должны знать о том, кто является RP - только с её помощью можно построить дерево.
5. Точка RP может быть указана статически, а может выбираться автоматически с помощью протокола BootStrap.
6. В первой фазе строится RPT - дерево от клиентов до RP - и Source Tree - дерево от источника до RP. Во второй фазе происходит переключение с построенного RPT на SPT - кратчайший путь от получателя до источника.

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

MDT - Multicast Distribution Tree . Общий термин, описывающий любое дерево передачи мультикаста.
SPT - Shortest Path Tree . Дерево с кратчайшим путём от клиента или RP до источника. В PIM DM есть только SPT. В PIM SM SPT может быть от источника до RP или от источника до получателя после того, как произошёл SPT Switchover. Обозначается записью - известен источник для группы.
Source Tree - то же самое, что SPT.
RPT - Rendezvous Point Tree . Дерево от RP до получателей. Используется только в PIM SM. Обозначается записью .
Shared Tree - то же, что RPT. Называется так потому, что все клиенты подключены к одному общему дереву с корнем в RP.

Типы сообщений PIM Sparse Mode:
Hello - для установления соседства и поддержания этих отношений. Также необходимы для выбора DR.
- запрос на подключение к дереву группы G. Не важно кто источник. Отправляется в сторону RP. С их помощью строится дерево RPT.
- Source Specific Join. Это запрос на подключение к дереву группы G с определённым источником - S. Отправляется в сторону источника - S. С их помощью строится дерево SPT.
Prune (*, G) - запрос на отключение от дерева группы G, какие бы источники для неё не были. Отправляется в сторону RP. Так обрезается ветвь RPT.
Prune (S, G) - запрос на отключение от дерева группы G, корнем которого является источник S. Отправляется в сторону источника. Так обрезается ветвь SPT.
Register - специальное сообщение, внутри которого передаётся мультикаст на RP, пока не будет построено SPT от источника до RP. Передаётся юникастом от FHR на RP.
Register-Stop - отправляется юникастом с RP на FHR, приказывая прекратить посылать мультикастовый трафик, инкапсулированный в Register.
- пакеты механизма BSR, которые позволяют выбрать маршрутизатор на роль BSR, а также передают информацию о существующих RP и группах.
Assert - сообщение для выбора PIM Forwarder, чтобы в один сегмент не передавали трафик два маршрутизатора.
Candidate-RP-Advertisement - сообщение, в котором RP отсылает на BSR информацию о том, какие группы он обслуживает.
RP-Reachable - сообщение от RP, которым она уведомляет всех о своей доступности.
*Есть и другие типы сообщений в PIM, но это уже детали*

А давайте теперь попытаемся абстрагироваться от деталей протокола? И тогда становится очевидной его сложность.

1) Определение RP,
2) Регистрация источника на RP,
3) Переключение на дерево SPT.

Много состояний протокола, много записей в таблице мультикастовой маршрутизации. Можно ли что-то с этим сделать?

На сегодняшний день существует два диаметрально противоположных подхода к упрощению PIM: SSM и BIDIR PIM.

SSM

• Поиска RP (протоколы Bootstrap и Auto-RP),
• Регистрации источника на мультикасте (а это лишнее время, двойное использование полосы пропускания и туннелирование)
• Переключения на SPT.

Кроме того, возможный вектор атаки в сети с активированной мультикастовой маршрутизацией - подключение злоумышленником своего источника и генерирование большого объёма мультикастового трафика, который перегрузит сеть. В SSM такое практически исключено.

Для SSM выделен специальный диапазон IP-адресов: 232.0.0.0/8.
На маршрутизаторах для поддержки SSM включается режим PIM SSM.

Router(config)# ip pim ssm

IGMPv3 и MLDv2 поддерживают SSM в чистом виде.
При их использовании клиент может

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

IGMPv1/v2, MLDv1 не поддерживают SSM, но имеет место такое понятие, как SSM Mapping . На ближайшем к клиенту маршрутизаторе (LHR) каждой группе ставится в соответствие адрес источника (или несколько). Поэтому если в сети есть клиенты, не поддерживающие IGMPv3/MLDv2, для них также будет построено SPT, а не RPT, благодаря тому, что адрес источника всё равно известен.
SSM Mapping может быть реализован как статической настройкой на LHR, так и посредством обращения к DNS-серверу.

Проблема SSM в том, что клиенты должны заранее знать адреса источников - никакой сигнализацией они им не сообщаются.
Поэтому SSM хорош в тех ситуациях, когда в сети определённый набор источников, их адреса заведомо известны и не будут меняться. А клиентские терминалы или приложения жёстко привязаны к ним.
Иными словами IPTV - весьма пригодная среда для внедрения SSM. Это хорошо описывает концепцию One-to-Many - один источник, много получателей.

А что если в сети источники могут появляться спонтанно то там, то тут, вещать на одинаковые группы, быстро прекращать передачу и исчезать?
Например, такая ситуация возможна в сетевых играх или в ЦОД, где происходит репликация данных между различными серверами. Это концепция Many-to-Many - много источников, много клиентов.
Как на это смотрит обычный PIM SM? Понятное дело, что инертный PIM SSM здесь совсем не подходит?
Вы только подумайте, какой хаос начнётся: бесконечные регистрации источников, перестроение деревьев, огромное количество записей (S, G) живущих по несколько минут из-за таймеров протокола.
На выручку идёт двунаправленный PIM (Bidirectional PIM, BIDIR PIM ). В отличие от SSM в нём напротив полностью отказываются от SPT и записей (S,G) - остаются только Shared Tree с корнем в RP.
И если в обычном PIM, дерево является односторонним - трафик всегда передаётся от источника вниз по SPT и от RP вниз по RPT - есть чёткое деление, где источник, где клиенты, то в двунаправленном от источника трафик к RP передаётся также вверх по Shared Tree - по тому же самому, по которому трафик течёт вниз к клиентам.

Это позволяет отказаться от регистрации источника на RP - трафик передаётся безусловно, без какой бы то ни было сигнализации и изменения состояний. Поскольку деревьев SPT нет вообще, то и SPT Switchover тоже не происходит.

Вот например:

Источник1 начал передавать в сеть трафик группы 224.2.2.4 одновременно с Источником2 . Потоки от них просто полились в сторону RP. Часть клиентов, которые находятся рядом начали получать трафик сразу, потому что на маршрутизаторах есть запись (*, G) (есть клиенты). Другая часть получает трафик по Shared Tree от RP. Причём получают они трафик от обоих источников одновременно.
То есть, если взять для примера умозрительную сетевую игру, Источник1 это первый игрок в стрелялке, который сделал выстрел, а Источник2 - это другой игрок, который сделал шаг в сторону. Информация об этих двух событиях распространилась по всей сети. И каждый другой игрок (Получатель ) должен узнать об обоих этих событиях.

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

Выглядит довольно просто - нужно отправлять мультикастовые пакеты в направлении RP и всё, но есть один нюанс, который всё портит - RPF. В дереве RPT он требует, чтобы трафик приходил от RP и не иначе. А у нас он может приходить откуда угодно. Взять и отказаться от RPF мы, конечно, не можем - это единственный механизм, который позволяет избежать образования петель.

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

Список OIL формируется только из тех интерфейсов, на которых маршрутизатор был выбран на роль DF.

Правила довольно прозрачны:

• Если запрос PIM Join/Leave приходит на тот интерфейс, который в данном сегменте является DF, он передаётся в сторону RP по стандартным правилам.
  Вот, например, R3. Если запросы пришли в DF интерфейсы, что помечены красным кругом, он их передаёт на RP (через R1 или R2, в зависимости от таблицы маршрутизации).
• Если запрос PIM Join/Leave пришёл на не DF интерфейс, он будет проигнорирован.
  Допустим, что клиент, находящийся между R1 и R3, решил подключиться и отправил IGMP Report. R1 получает его через интерфейс, где он выбран DF (помечен красным кругом), и мы возвращаемся к предыдущему сценарию. А R3 получает запрос на интерфейс, который не является DF. R3 видит, что тут он не лучший, и игнорирует запрос.
• Если мультикастовый трафик пришёл на DF интерфейс, он будет отправлен в интерфейсы из списка OIL и в сторону RP.
  Например, Источник1 начал передавать трафик. R4 получает его в свой DF интерфейс и передаёт его и в другой DF-интерфейс - в сторону клиента и в сторону RP, - это важно, потому что трафик должен попасть на RP и распространиться по всем получателям. Также поступает и R3 - одна копия в интерфейсы из списка OIL - то есть на R5, где он будет отброшен из-за проверки RPF, и другая - в сторону RP.
• Если мультикастовый трафик пришёл на не DF интерфейс, он должен быть отправлен в интерфейсы из списка OIL, но не будет отправлен в сторону RP.
  К примеру, Источник2 начал вещать, трафик дошёл до RP и начал распространяться вниз по RPT. R3 получает трафик от R1, и он не передаст его на R2 - только вниз на R4 и на R5.

Таким образом DF гарантирует, что на RP в итоге будет отправлена только одна копия мультикастового пакета и образование петель исключено. При этом то общее дерево, в котором находится источник, естественно, получит этот трафик ещё до попадания на RP. RP, согласно обычным правилам разошлёт трафик во все порты OIL, кроме того, откуда пришёл трафик.

Кстати, нет нужды более и в сообщениях Assert, ведь DF выбирается в каждом сегменте. В отличие от DR он отвечает не только за отправку Join к RP, но и за передачу трафика в сегмент, то есть ситуация, когда два маршрутизатора передают в одну подсеть трафик, исключена в BIDIR PIM.

Пожалуй, последнее, что нужно сказать о двунаправленном PIM, это особенности работы RP. Если в PIM SM RP выполнял вполне конкретную функцию - регистрация источника, то в BIDIR PIM RP - это некая весьма условная точка, к которой стремится трафик с одной стороны и Join от клиентов с другой. Никто не должен выполнять декапсуляцию, запрашивать построение дерева SPT. Просто на каком-то маршрутизаторе вдруг трафик от источников начинает передаваться в Shared Tree. Почему я говорю «на каком-то»? Дело в том, что в BIDIR PIM RP - абстрактная точка, а не конкретный маршрутизатор, в качестве адреса RP вообще может выступать несуществующий IP-адрес - главное, чтобы он был маршрутизируемый (такая RP называется Phantom RP).

Все термины, касающиеся PIM, можно найти в глоссарии .

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

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

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

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

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

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

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

Фактически это означает, что в один мультикастовый 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 .

IGMP-Snooping

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

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

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

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

Сервер 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.

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

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

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

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

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

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

За помощь в подготовке статьи спасибо …
За техническую поддержку спасибо Наташе Самойленко .
КДПВ нарисована Ниной Долгополовой - замечательным художником и другом проекта.

В пуле статей СДСМ ещё много интересного до окончания, поэтому не нужно хоронить цикл из-за долгого отсутствия выпуска - с каждой новой статьёй сложность значительно возрастает. Впереди почти весь MPLS, IPv6, QoS и дизайн сетей.

Как вы уже, наверно, заметили, у linkmeup появился новый проект - Глоссарий lookmeup (да, недалеко у нас ушла фантазия). Мы надеемся, что этот глоссарий станет самым полным справочником терминов в области связи, поэтому мы будем рады любой помощи в его заполнении. Пишите нам на [email protected]

Теги:

• сети для самых маленьких
• мультикаст
• pim
• igmp
• ssm

Цифровое телевидение обладает рядом преимуществ. В том числе, просмотр ТВ-каналов без помех и шумов, которые характерны для аналогового ТВ, просмотр видео формата HD, запись передач с помощью компьютера.Поэтому многие задаются вопросом, как подключить iptv через роутер. Технология IPTV (Internet Protocol Television) представляет собой новое поколение телевидения цифрового телевидения в сетях передачи данных, используя протокол IP. Вещание TB каналов проводится при помощи мультикаста. Мультикаст ом называют особую форму широковещания по протоколу IGMP , при которой сетевой пакет одновременно направлен определённому подмножеству адресатов. А вещание каналов происходит по протоколу UDP . Полоса, занимаемая одним каналом, составляет в среднем 4-5 Мб/с. Протоколом IGMP называют протокол управления групповой (multicast) передачей данных в сетях, которые основаны на протоколе IP. По умолчанию, большинством роутеров блокируется IGMP-траффик, поэтому они требуют подстройки. В данной статье будут даны рекомендации, как настроить iptv на роутере.

Самой актуальной проблемой для пользователей, которые настраивают IPTV через роутер, является правильная настройка этого стандарта в веб-интерфейсе роутера для обеспечения бесперебойной работы и подключение iptv через роутер. Не все роутеры можно использовать для этих целей.

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

Роутер для iptv должен поддерживать функцию iptv. Далее описаны примеры настройки основных моделей роутеров.

Роутеры D-Link

В моделях DIR-100 (120), DIR-300 NRU, DIR-300 (400), DIR-320, DIR-615, DIR-628, DIR-655 для настройки нужно открыть раздел Advanced – Advanced Network и установить галочку возле Enable multicast streams (Включение многоадресных потоков).

В моделях роутеров DIR-320 NRU, DIR-300 NRU (rev.B5), DIR-620 нужно
выбрать раздел Сеть – Соединения (слева) – WAN и поставить галочку возле – Включить IGMP.

После этого нужно зайти в раздел Сеть – Соединения – l2tp_eth2.2_0 и поставить галочку возле Keep Alive, параметр LCP интервал поставить 30, параметр LCP провалы поставить 5.

Чтобы завершить настройку роутера, нужно указать статический маршрут. Для этого открыв вкладку Дополнительно – Маршрутизация нужно нажать – Добавить (ввести данные приведенные ниже). После этого Вам будет доступен просмотр ip tv через роутер.

Роутеры Zyxel

Для настройки модели роутера P-330W EE нужно его перепрошить самой последней прошивкой, которую нужно скачать с сайта производителя . Потом в меню WAN найти поле Choose Bridge Port(s) и указать в нем тот LAN -порт, к которому будет подключаться TV – приставка.

Для настройки модели Keenetic и Keenetic Lite нужно выбрать в меню Домашняя сеть – IP-телевидение и поставить Режим TV-порт (подключение STB-приставки в порт LAN) либо выбрать – Автоматический (просмотр IPTV на компьютере).

Для моделей NBG334W EE и NBG460N EE нужно выбрать в меню Network –WAN – Advanced и поставить галочку возле Enable IGMP Snooping Multicast.
Кроме этого, для подключения IPTV приставки к роутеру необходимо выбрать опцию Choose IPTV STB PORT и установить там – один/несколько LAN портов.

Роутеры Asus

Для iptv может проводиться одним из двух, приведенных ниже, способов. В примере используется RT-G32 B.

1 способ . Откройте меню роутера и перейдите ЛВС -> Маршрут, в открывшемся окне поставьте галочку в поле “Включить многоадресную маршрутизацию” – “Yes”. Потом нажмите кнопку “Применить”.

При таких настройках в локальную сеть транслируется multicast поток для плеера VLC без изменений.

Достоинства такого способа:

1. Не требуется дополнительных настроек VLC плеера.

Недостатки:

1. Подключить компьютера для просмотра IPTV можно только через витую пару (Ethernet-кабель).
2. В момент просмотра IPTV, на других компьютерах локальной сети будет происходить падение скорости интернет соединения.
3. Внутри сети излишний multicast трафик.

2 способ . Вам нужно правильно настроить функцию ”IPTV UDP Multicast to HTTP Proxy”. Для этого нужно открыть меню роутера и перейти в раздел ЛВС -> Маршруты, поставить галочку возле пункта “Включить многоадресную маршрутизацию” – “Yes”. После этого найдите поле ”IPTV UDP Multicast to HTTP Proxy” и пропишите там произвольный порт. Для примера, 2323. Для сохранения изменений нажмите кнопку – “Применить”.

Преимущества второго способа:

1. Смотреть IPTV на компьютере можно по WiFi соединению. При этом надругих компьютерах локальной сети, не будет происходить падения скорости интернет-соединения.
2. Нет перегрузок роутера.
3. Multicast трафик не транслируется во внутреннюю сеть, а VLC плеер производит захват потока видео с wifi роутера.

Недостатки второго способа:

1. Необходимость изменения плейлиста для используемого мультимедиа плеера.
2. Можно использовать только iptv wifi роутер.

В VLC плей-лист при использовании функции «IPTV UDP Multicast to HTTP Proxy» необходимо внести такие правки:

Выберите файл плей-листа и откройте его в текстовом редакторе.
Найдите в тексте строки вида – udp://@ 239.23.0.200:1234/ и часть – udp://@, просто удалите. Нужно изменить все такие строки.
После этого, на место удаленной части udp://@ необходимо вставить адрес – http://192.168.1.1:2323/udp/ , в котором 192.168.1.1 – IP адрес для вашего wi-fi роутера, а 2323 – выбранный Вами в настройках прокси порт.
В результате Вы получите строку вида http://192.168.1.1:2323/udp/239.23.0.200:1234/

Роутеры NetGear

Для моделей WNR612v2, WNR1000v2, WNR3500L автоматически включен Multicast, и поэтому никаких настроек проводить не требуется.

Роутеры TRENDnet

Для модели TEW-432BRP нужно сначала обновить прошивку роутера до последней версии. После успешной перепрошивки, на роутере автоматически будет включен Multicast. Других настроек производить не надо.

Роутеры TP-Link

Для модели TL-WR1043ND нужно также обновить прошивку роутера до последней версии. После перепрошивки будет автоматически включен Multicast, и больше никаких настроек проводить не надо.

Возможные причины, когда не работает iptv через роутер и их устранение.

1. Устарел плейлист, необходимо его обновить (например, с сайта –
2. Возможно требуется обновление медиа проигрывателя. Лучше всего использовать релиз с сайта – http://www.videolan.org/ или воспользоваться IP-TV Player с сайта – http://triolan.tv/.
3. Видеопоток заблокировал файерволл Windows либо файерволл антивируса. Поэтому на время поиска причины его нужно отключить. Если после отключения все заработало, то необходимо настроить антивирус для разрешения приема IP-TV.
4. Роутер не пропускает IP-TV. Чтобы в этом убедиться нужно подключить кабель напрямую к компьютеру и прописать в настройках TCP/IP выданные Вам при подключении сетевые настройки. Если после этого IP-TV заработает, то значит проблема в роутере. У Вас должен быть роутер wifi с поддержкой iptv.
5. Если в Вашем компьютере используется 2 сетевые карты и совместный доступ в Интернет, то отключите внутреннюю сетевую карту.
6. Работу IP-TV может блокировать какое-то программное обеспечение. Для проверки, загрузите безопасный режим Windows с поддержкой сети.
7. Если все перечисленные здесь способы не помогли, то значит проблема, скорее всего, на стороне провайдера.

Настройки роутера для смарт ТВ

Роутер для смарт ТВ должен поддерживатьэту функцию.Соединение смарт ТВ с роутером рекомендуется проводить посредством патчкорда UTP-5e. Вы можете подключить роутер, роутер тв приставка, как на рисунке ниже.

Если в телевизоре есть функция WiFi, можно настроить соединения между смарт ТВ и роутером с помощью (WiFi) соединения. В этом случае, могут наблюдаться перерывы и зависания картинки при воспроизведении видео.

Сначала с помощью компьютера нужно настроить Ваш роутер для ТВ, чтобы был доступ к сети интернет. Когда роутер настроен и на компьютере все работает, можно настраивать интернет на Smart TV.
Нажмите клавишу «Меню» на пульте д/у телевизора и выберите
в меню пункт «Сеть».

Потом выберите пункт «Настройка сети» и если, телевизор подключен к роутеру кабелем, то сразу начнется настройка соединения через кабель, а если используется WiFi, то начнет настраиваться беспроводное соединение.

Нажмите на кнопку «Пуск» и начнется поиск WiFI-роутера. (Роутер должен быть включенным и находиться в сети). Когда Smart TV обнаружит WiFI-роутер, то появится такое окно.

Здесь нужно выбрать Ваш роутер и нажать «Далее». После этого роутер запросит ключ безопасности. Вам нужно ввести ключ, который Вы ввели при настройке WiFi-роутера.

Если ключ введен правильно, то установится беспроводное соединение.

Когда подключение к сети интернет установится, можно будет работать с сервисами SMART HUB.

IPTV – это цифровое телевидение, его можно подключить как к телевизору, так и к компьютеру, смартфону, медиа-плееру. Существует несколько способов подключения IP TV к , что дает возможность любому пользователю настроить и просматривать цифровые каналы, исходя из собственных возможностей, просто нужно знать, как это сделать правильно.

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

Подключить цифровое ТВ можно любым удобным способом, каждый из которых имеет свои нюансы:

• через подключенную приставку iptv;
• через роутер посредством беспроводного соединения;
• с помощью специальных приложений;
• через интернет-браузер.

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

Особенности подсоединения приставки

Подсоединение цифровой приставки мало чем отличается от . Соединение с роутером осуществляется через стандартный Ethernet-разъем, доступна и беспроводная настройка через Wi-Fi. При желании или некоторых сложностях, можно воспользоваться проводом и подсоединить его к LAN-разъему.

На любой приставке для IPTV присутствуют и другие выходы:

• AV для подключения к телевизорам устаревшего образца;
• HDMI для более современных панелей;
• USB разъем (обычно расположен спереди).

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

Настройка приставки

После подключения приставки, ее необходимо включить. Для просмотра IPTV на телевизоре выводится меню. Настраивать софт, в целом, довольно просто. На пульте ДУ есть кнопка Setup, после ее нажатия необходимо произвести следующие установки.

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

Беспроводное подключение

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

LG

Для обладателей техники LG доступно беспроводное подключение IPTV и вещание на телевизоре цифровых каналов через специально разработанную программу SS IPTV . Для доступа к нему потребуется соединение с Интернетом. Устанавливать приложение можно с USB-носителя или после скачивания.

Чтобы скачать и запустить программу, нужно зайти в меню Smart, открыть вкладку Smart World. В адресной строке прописать название SS IPTV и задать команду поиска. Когда утилита будет отображена в списке, ее необходимо установить, а затем открыть. Подключение интерактивного телевидения к телевизорам иных торговых марок, например Philips или Samsung, осуществляется схожим алгоритмом действий.

Philips

В телевизионных панелях Philips нужно установить соединение с Интернетом, подключившись в точке доступа (роутеру). Затем нажать кнопку Home на ПДУ, открыть меню конфигураций . В настройках сети выбрать пункт «Режим работы» и прописать значение DNS. Для подключения к цифровому телевидению достаточно загрузить любой из доступных виджетов.

Samsung

Для просмотра IPTV на телевизоре Samsung, как сделано и в предыдущих способах, нужно настроить соединение с сетью Интернет и установить специальную утилиту.

1. На ПДУ открыть меню Smart Hub, нажать кнопку «А». Здесь нужно создать учтенную запись, ввести логин Develop и пароль.
2. Затем войти в настройки и открыть пункт «Разработка». В поле IP-адрес прописать 188.168.31.14, или использовать альтернативный набор 31.128.159.40.
3. После выбрать вкладку «Синхронизация приложений», когда процесс закончится, нажать Enter.

Теперь в списке приложений пользователю будет доступна специальная утилита nStreamPlayer для просмотра IPTV телевидения.

IPTV – это специальная технология, которая при передачи данных в сетях, использует специальный IP протокол.

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

Настройка IP-TV на маршрутизаторах

Роутеры модели D-Link

Для часто покупаемой модели роутера марки D-LINK DIR 615 необходимо провести всего лишь 2 действия:

Для реже покупаемых моделей, например, для моделей DIR-320 NRU или DIR-300 NRU, нужно:

Роутеры модели Asus

Роутеры фирмы ASUS примечательны тем, что настройка IPTV может производиться 2-умя способами.

В моделях роутеров ASUS, чаще подключение делают так:

1. зайти в меню и перейти по вкладке ЛВС -> Маршрут.
2. откроется окошечко, в котором необходимо отметить пункт включения многоадресной маршрутизации. Не забудьте сохранить настройку, щёлкнув по кнопке «Применить».

Фото: Открытие меню и переход ЛВС -маршрут

Такой способ достаточно лёгкий, ведь отпадает необходимость тратить лишнее время на настройку дополнительных установленных программ, однако, при этом всю работоспособность всей сети берёт на себя роутер. Помимо этого, подключение выполняется только при условии присутствии «Ethernet-кабель», а при пользовании этой программы на других устройствах через локальную сеть скорость интернет соединения заметно снижается и становится меньше.

Роутеры модели Zyxel

Эти устройства должны быть перепрошиты самой последней доступной версией с официального сайта производителя роутера.

Настройка iptv через роутер ZYXEL KEENETIC START делается следующим образом:

1. зайти в меню WAN и найти поле «Choose Bridge Port(s)»;
2. в нём указываем тот LAN -порт, к которому будет подключаться TV — приставка.

Фото: настройка IPTV на модемах ZyXEL

Для некоторых моделей в конце настройки нужно выбрать опцию «Choose IPTV STB PORT» и установить там количество подключаемых LAN портов.

Роутеры модели TP-Link

Данный модельный ряд также нуждается в прошивке программы до последней доступной версии. Однако, после прошивки, в автоматическом режиме запускается Multicast, и сам настраивает программу. Возможными причинами неполадок может служить старый плейлист, не обновлённый медиа проигрыватель, блокировка со стороны антивируса, и неправильное подключение кабеля. Если ошибка не в этом, а подключение не произведено, то блокировка идёт со стороны интернет провайдера.

Настройка подключения услуги IPTV через роутер

Для оператора Ростелеком

Всемирно-известная компания «Ростелеком» одна из немногих фирм, которая предоставляет возможность просмотра цифрового телевидения в хорошем качестве на компьютере. Качество картинки и звука остаётся на высшем уровне.

Видео: настройка роутера Ростелеком

Настройка IPTVчерез роутер Ростелеком – процесс не сложный и не долгий, достаточно всего лишь:

1. грамотно написать заявление в сервисном центре компании;
2. дождаться технических работников компании, которые произведут необходимые настройки на станционном оборудовании;
3. после этого необходимо скачать на компьютер специальную программу для просмотра телевидения – IPTV Player.
4. скачать установочный файл самого плеера;
5. запустить появившийся файл и произвести пошаговую установку программы;
6. запускаем мастер установки и во всех пустых клетках ставим галочку, после чего нажимаем кнопку «Далее» и в дальнейшем «Установить»;
7. в конце установки жмём на клавишу «Готово», ожидаем завершение и выключение мастера установки, выбираем регион, где мы в данный момент находимся, и можно щёлкать каналы;
8. установка успешно завершена.

Для оператора Билайн

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

Фото: Настройка IPTV через маршрутизатор

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

Настройка роутера для оператора Билайн необычна тем, что в обязательном порядке нужно сделать выделение LAN порта для подключения IPTV приставки в специальный «Прозрачный режим». Лучше всего подключать к 4 LAN порту и производить установку, но если невозможно подключить к этому порту, то в ходе установки не забывайте ставить номер того порта, к которому произведено подключение.

Если появляется необходимость объединить порты для IP TV приставки, то делаем следующее:

1. деинсталлируем соединение WAN;
2. открываем меню «Сеть», заходим в раздел «Соединения» и выбираем соединение «WAN»;
3. открывается окно настройки выбранного соединения, в котором в нижней части этого окна необходимо нажать кнопку «Удалить»;
4. показывается результат, что соединение удалено и его больше нет в списке доступных соединений. Нужно сохранить этот момент;
5. после этого, производим соединение LAN порта с WAN портом. Для этого нужно выделить свободный LAN порт, зайти в меню «Дополнительно», открыть раздел «VLAN» и выбирать пункт «VLAN LAN»;
6. производим выбор порта LAN, лучше всего 4-ый порт, но можно и любой другой, и производим деинсталляцию этого порта;
7. получается, что объявлены только оставшиеся порты под номерами, соответствующими разъёмам на задней панели устройства. Нужно сохранить эти изменения и полностью перезагрузить устройство;
8. дальше добавляем VLAN WAN наш выделенный порт LAN 4;
9. нажимаем «сохранить изменения». Сохраняем все необходимые настройки и снова перезагружаем устройство. После этого появляется возможность добавления порта №5;
10. так как порт 4 и порт 5 принадлежат VLANWAN, то создаём соединение WAN и нажимаем клавишу «Добавить».

Фото: Схема подключения ТВ-Приставки

Такая установка оборудования возможна только в случае присваивания IP адреса клиенту по DHCPинтернет провайдером. Кабель от интернет провайдера подключается в задней части маршрутизатора. После выполнения таких не хитрых манипуляций порт 4 LAN стал параллельным с WAN портом и полностью доступен для подключения IPTV приставки.

Для оператора Триолан (triolan)

Подключение для оператора Триолан одно из самых доступных и лёгких. Производится всего лишь в несколько этапов.

Чтобы произвести установку нужно:

1. Отключить программу SPIfirewall.
2. Создать специальный документ /tmp/igmpproxy.conf, в котором высвечивается данный код:

quickleave phyint vlan1 upstream ratelimit 0 threshold 1 phyint br0 downstream ratelimit 0 threshold 1 phyint eth0 disabled phyint eth1 disabled phyint vlan0 disabled phyint lo disabled В данном случае стоит запомнить, что vlan1 означает WAN, а br0 – это бридж WAN-LAN.

3. запускаем igmpproxy, где видим # killall -9 igmprt # igmprt -c /tmp/igmpproxy.conf

Фото: Настройка компьютера для работы с IPTV

4. в конце остаётся только запустить программу VLC/IP-TV Player, которая самостоятельно выполнит настройки. Подключение выполнено, и можно наслаждаться просмотром телевидения.

Настройки для телевизоров смарт ТВ

Прежде чем приступать к настройке, необходимо выяснить, поддерживает ли роутер данную функцию или нет . Роутер должен поддерживать эту функцию, ведь соединение производится благодаря патчкорду UTP-5e.

Настройка интернета на телевизоре с функцией Смарт ТВ делается так:

Услуга IPTV от провайдера

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

Преимущества IPTV перед обычным эфирным ТВ

• Нет необходимости в ТВ-тюнере, установленном на вашем ПК.
• Возможность приостановить воспроизведение канала на определенное время.
• IPTV может предоставлять дополнительные услуги, такие как «Видео по запросу» (VOD, Video On Demand).

Принимать телевидение в формате IPTV можно двумя способами - через специальную приставку, которую предоставляет провайдер или приобретается отдельно. Также IPTV можно воспроизводить с помощью программного плеера, такого как IP-TV Player . Данное приложение является надстройкой для популярного проигрывателя VLC. Для показа каналов укажите город и провайдера, предоставляющего услугу IPTV. В результате в программу загрузится список каналов, и можно будет смотреть видео.

Программные плееры для воспроизведения IPTV: VLC , IPTV Player, PC Player и т.п.

Самая актуальная проблема для пользователей при настройки IPTV через роутер - это правильно настроить этот стандарт в веб-интерфейсе wi-fi роутера для бесперебойной работы. Далеко не все роутеры подходят для этих целей.

Внимание! Список роутеров с поддержкой IPTV вы можете узнать, позвонив своему провайдеру или посмотрев на официальном сайте. Или воспользоваться .

Роутеры для работы IPTV: 54 Мбит/с беспроводные маршрутизаторы (серия G), 150 Мбит/с беспроводные маршрутизаторы (серия N), 300 Мбит/с беспроводные маршрутизаторы (серия N) и старше.

Для раздачи IPTV по беспроводному соединению без приставки (возможно использование такого соединения лишь тогда, когда сигнал не закодирован) теоретически можно использовать огромное количество роутеров, но на практике бесперебойной работы от роутера удается добиться лишь с альтернативной прошивкой. Netgear WNR 3500L стабильно работает с IPTV c прошивкой от tomato. Asus WL520g c прошивкой от oleg’а. Обращаю ваше внимание, что IPTV по кабелю и по воздуху - это различные методы реализации IPTV в квартире , IPTV по воздуху должен уметь обрабатывать ваш роутер и чтобы добиться работы IPTV, приходиться вмешиваться в прошивку маршрутизатора.

Также не забывайте о покрытии беспроводной сети, кому-то понадобится оптимизировать сеть, а кто-то столкнется с «лагами» и артефактами изображения при удалении клиента (ПК, ноутбука, ТВ) от роутера. В некоторых случаях появляется необходимость в преобразовании UDP-мультикаст потока IPTV в TCP-юникаст. Данная процедура возможна с помощью специальной утилиты UDP to HTTP , которая будет преобразовывать трафик. Данное приложение должно быть активно на ПК, с подключенным IPTV по витой паре, но для этого необходим постоянно активный компьютер (север или клиент сети), либо выбирайте роутер, умеющий выполнять преобразование трафика (с поддержкой udpxy ). В таком случае конверсия потока будет осуществляться силами маршрутизатора.

UDP-to-HTTP Proxy предназначен для преобразования udp-мультикаст трафика IPTV в tcp-юникаст (конкретно http) трафик. Это полезно для комфортного просмотра IPTV через Wi-Fi , NAT, на КПК, бытовых плеерах и игровых консолях.

IPTV через роутер

Зачастую, для работы IPTV на компьютере через wi-fi роутер , на самом устройстве ничего настраивать не нужно. Обновите версию прошивки вашего устройства и впоследствии поддержка IPTV на роутере будет включена автоматически. Вам необходимо лишь выбрать устройство (маршрутизатор) с поддержкой IPTV (IGMP протокол ).

IGMP (Internet Group Management Protocol) - это протокол управления групповой (multicast — мультикаст) передачей данных в сетях, основанных на протоколе IP. Протокол IGMP используется роутерами для организации сетевых устройств в группы. Тот, кто искал информацию по форумам, не раз сталкивался с понятием мультикаст . IGMP используется для поддержки потокового видео, что эффективно сказывается на реализации потока IPTV. Сразу проверьте, не блокирует файрвол, брандмауэр или антивирус этот протокол. Мультикаст , как правило, активируется опцией Enable multicast routing.

Внимание! Активный мультикаст в некоторых моделях роутеров частенько «забивает» локальную сеть, особенно это касается wi-fi.

IPTV через приставку

Для работы IPTV через приставку рекомендуется использовать функцию «Bridge» . Таким образом мы настраиваем LAN порты на режим свитчинга с WAN. Плюс ко всему, мы получаем возможность подключить кабель провайдера не в WAN, а в тот LAN порт, что объединен с WAN’ом. Сразу замечу, данную функцию поддерживают не все роутеры. Например, в роутерах TP-LINK эта функция присутствует в меню Network — Bridge (Сеть — Мост), в Asus она называется Choose WAN Bridge Port и т.п. Для функционирования IPTV необходимо лишь выбрать LAN порт, который мы будем использовать для подключения IPTV приставки .

Для тех кто хочет использовать большее количество приставок, имеется возможность выбрать два порта (Например, LAN3 и LAN4, если у вас две приставки). Если ваша модель wi-fi роутера не имеет поддержку «Bridge» и для вашего провайдера достаточно поддержки мультикаста (протокол IGMP) , вы сможете смотреть IPTV через приставку.

Для того чтобы не искать проблемы передачи своего IP телевидения там, где ее нет, проверьте, работает ли телевидение без роутера. Для этого подключите компьютер к кабелю провайдера напрямую. Если IPTV не подаст жизненных признаков, то скорее всего проблема у вашего провайдера. Обратитесь в техническую поддержку. А в положительном случае прямого подключения, следует выяснить у тех. поддержки, достаточно ли мультикаста для работы IP телевидения.

Пользователям, чьи модели роутеров не поддерживают функции Bridge , но телевидение работает с перебоями («рассыпается» картинка и «заикается» звук) стоит обратить внимание на загруженность их роутеров. Особенно это касается тех, кто обладает большой скоростью скачивания, чрезмерной нагрузкой (большое количество активных торрент-закачек, работают в DC++ и т.п.). Решить эти проблемы можно ограничением скорости скачивания, лимитировать количество одновременных соединений до 50. Для тех, кто использует модели без поддержки Bridge рекомендуется подключать не более одной приставки IPTV . Если вы используете две (или более приставки), а роутер не поддерживает функции Bridge, то вы можете использовать обычный свитч. Свитч необходимо установить перед роутером. К свитчу будут подключены две приставки IPTV, кабель вашего провайдера, а кабель от роутера в порт WAN.

Как настроить IPTV

Например, настройка IPTV на роутере D-Link DIR-300 и подобных моделей сводится к установке одной лишь галочки в пункте «Enable multicast streams»:

Лично для меня, настройка IP телевидения по проводному соединению сводилась к нескольким шагам (на примере роутера Asus 520GU):

• Необходимо зайти в раздел WAN, предварительно активировав DHCP
• перейти во вкладку Общее
• найти пункт Выбор порта IPTV STB — выбираем из списка тот порт, к которому будет подключена IPTV-приставка .
• Нажимаем Применить и все.

Настройка IPTV на роутере ASUS

Теперь я опишу 2 способа настройки IPTV через роутер RT-G32 B

Внимание! Описанную инструкцию по настройке IPTV можно использовать и на других моделях роутеров Asus для наглядности, и не только Asus в практическом и теоретическом применении.

1 способ . Перейдите в раздел ЛВС —> Маршрут и поставьте галочку “Включить многоадресную маршрутизацию” – “Yes”. Сохраняем – “Применить”.

В данном случае в локальную сеть будет транслироваться multicast поток для VLC плеера без изменений.

Преимущества данного способа:
1. Никаких дополнительных настроек VLC плеера производить не надо.

Недостатки:
1. Возможность подключения компьютера для просмотра IPTV только через витую пару (Ethernet-кабель).
2. Падение скорости интернет соединения на других компьютерах в локальной сети, в момент воспроизведения IPTV.
3. Сильная нагрузка на маршрутизатор.
4. Излишний multicast трафик внутри сети.

2 способ . Необходимо настроить функцию ”IPTV UDP Multicast to HTTP Proxy”. Перейдите в раздел ЛВС —> Маршруты и поставьте галочку “Включить многоадресную маршрутизацию” – “Yes”, и в поле ”IPTV UDP
Multicast to HTTP Proxy” выберите произвольный порт. Например, 2323. Сохраните изменения – “Применить”.

Преимущества данного способа:

1. Возможность смотреть IPTV на компьютере по WiFi соединению.
2. Остальные компьютеры в локальной сети не испытывают падения скорости при интернет-соединения.
3. Роутер не перегружается.
4. Multicast трафик во внутреннюю сеть не транслируется, а VLC плеер захватывает поток видео с wifi роутера.

Недостатки:

1. Необходимо изменить плейлист для используемого мультимедиа плеера.

Правки, которые необходимо внести в VLC плей-листом при использовании функции «IPTV UDP Multicast to HTTP Proxy»:

Откройте плей-лист в текстовом редакторе.
Найдите строки вида — udp://@ 239.23.0.200:1234/ и удалите часть, которую я выделил жирным. Изменять необходимо все.
На место удаленной части udp://@ вставьте — http://192.168.1.1:2323/udp/ , где 192.168.1.1 — IP адрес вашего wi-fi роутера, а 2323 – прокси порт, который вы выбрали.
Результатом будет строка — http://192.168.1.1:2323/udp/239.23.0.200:1234/

На что стоит обратить внимание при подключении IPTV:

Использование IPTV приставки:

Активация опции Choose WAN Bridge Port и выбор одного или нескольких LAN портов роутера для подключения IPTV приставки.

Использование для просмотра IPTV ПК (проводное и беспроводное подключение)

Активация опции « Enable multicast routing», которая отключит фильтрацию multicast трафика и станет активным перенаправление его во внутреннюю подсеть на LAN интерфейсы в случае необходимости. Не забывайте разрешить активность программы для просмотра IPTV в файрволе.

Для пользователей IPTV, использующих беспроводной вариант подключения, чтобы избежать «лагов» и «артефактов» понадобится опция Multicast Rate (Mbps), с помощью которой вы можете ограничить ширину полосы multicast трафика , передаваемого на беспроводной интерфейс. Рекомендуется устанавливать максимальное значение, во избежание разрывов Wi-Fi соединения на остальных беспроводных клиентах при просмотре.