Multicast routing для IPTV
Один очень близкий мне человек, поклонник Хабра, захотел внести вклад в развитие блога Cisco. Являясь яростным поклонником того, что создает эта корпорация, он захотел поделиться опытом. =) Надеемся росчерк пера удался.
Относительно недавно мне посчастливилось познакомить и даже поконфигурять multicast routing для IPTV. Изначально, я с этой темой была совершенно не знакома, и это заставило меня вылакать горлышко от цистерны водки перекопать огромное количество документации, чтобы войти в курс дела.
И вот незадача. Обычно в документации выкладывают все и сразу и для человека, впервые столкнувшегося с этой темой, не понятно с чего начать. Во время чтения pdf’ок я ловила себя на мысли, что было бы неплохо наткнуться где-нибудь на статью, которая могла бы коротким путем провести от теории к практике, чтобы понять с чего стоит начать и где заострить внимание.
Мне не удалось обнаружить такую статью. Это побудило меня написать эту статейку для тех, кто также как и я столкнется с вопросом, что это за зверь IPTV и как с ним бороться.
Введение
Это моя самая первая статья (но не последняя! есть еще много зверей), постараюсь изложить все как можно доступнее.
- unicast — одноадресный, один источник потока один получатель
- broadcast — широковещательный, один источник, получатели все клиенты в сети
- multicast — многоадресный, один отправитель, получатели некоторая группа клиентов
Какой вид трафика использовать для IPTV?
| — | unicast | broadcast | multicast |
| Особенности применительно к IPTV | получаем дублирование трафика, для каждого абонента создается свой поток | клиентское оборудование вынуждено обрабатывать весь поток каналов, который может быть совсем не несколько килобит | абонент получает только тот поток, который запрашивает |
Очевидно, что для вещания каналов наибольшее предпочтение отдается multicast.
Любой TV-канал, который мы хотим вещать в сеть, характеризуется адресом группы, который выбирается из диапазона, зарезервированного для этих целей: 224.0.0.0 – 239.255.255.255.
Для работы IPTV необходим роутер, поддерживающий multicast (далее MR). Он будет отслеживать членство того или иного клиента в определенной группе, т.е. постоянно следить какому клиенту какой отправлять TV-канал.
Для того чтобы клиент смог зарегистрироваться в одной из этих групп и смотреть TV-канал используется протокол IGMP (Internet Group Management Protocol).
Немного о том, как работает IGMP.
Есть сервер, который включен в роутер MR. Этот сервер вещает несколько TV-мультиков, например:
| 224.12.0.1 | канал 1 | News |
| 224.12.0.2 | канал 2 | History |
| 224.12.0.3 | канал 3 | Animals |
Клиент включает канал News, тем самым, сам не подозревая, он отправляет запрос на MR для подключения к группе 224.12.0.1. С точки зрения протокола IGMP это запрос “JOIN 224.12.0.1”.
Если пользователь переключается на другой канал, то он сначала отправляет уведомление MR, что он отключает канал News или покидает эту группу. Для IGMP это “LEAVE 224.12.0.1”. А затем повторяет аналогичный запрос JOIN для нужного канала.
MR иногда спрашивает всех: “а какой группе кто подключен?”, чтобы отключать тех клиентов, с которыми оборвалась связь и они не успели отправить уведомление LEAVE. Для этого MR использует запрос QUERY.
Ответ абонента на этот запрос это MEMBERSHIP REPORT, который содержит список всех групп, в которых состоит клиент.
Настройка multicast routing.
Предположим, что клиенты одной группы смотрят один и тот же мультик, но находятся они в разных сегментах сети (network A и network B). Для того, чтобы они получили свой мультик и придуман multicast routing.
Пример настройки роутеров MR1 и MR2.
| Network A | 10.1.0.0/24 |
| Network B | 10.2.0.0/24 |
| Network C | 10.3.0.0/24 |
| MR1 | MR2 |
| MR1#sh run |
Команда «ip multicast-routing» включает соответствующий routing, если же он выключен, то роутер не пересылает multicast пакеты, т.е. они не дойдут до недоумевающего зрителя мультиков.
Остановимся чуть поподробнее на команде «ip pim sparse-mode«.
Про режимы протокола PIM и сам протокол.
PIM (Protocol Independent Multicast) — протокол маршрутизации multicast рассылки. Он заполняет свою таблицу multicast маршрутизации на основе обычной таблицы маршрутизации. Эти таблицы можно просмотреть с помощью команд “sh ip mroute” и “sh ip route” соответственно. Целью протокола PIM является построение дерева маршрутов для рассылки multicast сообщений.
У протокола PIM существует два основных режима: разряженный (sparse mode) и плотный (dense mode). Таблица multicast маршрутизации для них выглядит немного по-разному. Иногда эти режимы рассматривают как отдельные протоколы — PIM-SM и PIM-DM.
В нашей конфигурации на интерфейсах мы указали режим «ip pim sparse-mode«.
(config-if)# ip pim?
dense-mode Enable PIM dense-mode operation
sparse-dense-mode Enable PIM sparse-dense-mode operation
sparse-mode Enable PIM sparse-mode operation
………
В чем же разница?
PIM-DM использует механизм лавинной рассылки и отсечения (flood and prune). Другими словами. Роутер MR отправляет всем все multicast потоки, которые на нем зарегистрированы. Если клиенту не нужен какой-то из этих каналов, то он от него отказывается. Если все клиенты, висящие на роутере, отказались от канала, то роутер пересылает “спасибо, не надо” вышестоящему роутеру.
PIM-SM изначально не рассылает зарегистрированные на нем TV-каналы. Рассылка начнется только тогда, когда от клиента придет на нее запрос.
Т.е. в PIM-DM MR отправляет всем, а потом убирает ненужное, а в PIM-SM MR начинает вещание только по запросу.
Если члены группы разбросаны по множеству сегментов сети, что характерно для IPTV, PIM-DM будет использовать большую часть полосы пропускания. А это может привести к снижению производительности. В этом случае лучше использовать PIM-SM.
Между PIM-DM и PIM-SM существуют еще отличия.
PIM-DM строит дерево отдельно для каждого источника определенной multicast группы, т.е. multicast маршрут будет характеризоваться адресом источника и адресом группы. В multicast таблице маршрутизации будут записи вида (S,G), где S — source, G — group.
У PIM-SM есть некоторая особенность. Этому режиму необходима точка рандеву (RP — rendezvous point) на которой будут регистрироваться источники multicast потоков и создавать маршрут от источника S (себя) до группы G: (S,G).
Таким образом, трафик идет с источника до RP по маршруту (S,G), а далее до клиентов уже по общему для источников определенной группы дереву, которое характеризуется маршрутом (*,G) — «*» символизирует «любой источник». Т.е. источники зарегистрировались на RP, и далее клиенты уже получают поток с RP и для них не имеет значения, кто был первоначальным источником. Корнем этого общего дерева будет RP.
Точкой рандеву является один из multicast роутеров, но все остальные роутеры должны знать “кто здесь точка RP”, и иметь возможность до нее достучаться.
Пример статического определения RP (MR1). Объявим всем multicast роутерам, что точкой рандеву является 10.0.0.1 (MR1):
| ip pim rp-address 10.0.0.1 IPTV override | указываем адрес RP и access-list IPTV access-list определяет какие группы |
| ip access-list standard IPTV | регистрироваться на данной точке рандеву |
| permit 224.11.0.0 0.0.0.3 |
Все остальные роутеры должны знать маршрут до RP:
ip route 10.0.0.0 255.255.255.0 10.10.10.1
Существуют так же и другие способы определения RP, это auto-RP и bootstarp router, но это уже тема для отдельной статьи (если кому-нибудь будет интересно – пожалуйста)?
Посмотрим, что будет происходить после настройки роутеров.
Мы по-прежнему рассматриваем схему с роутерами MR1 (RP) и MR2. Как только включаем линк между роутерами MR1 и MR2, то должны увидеть в логах сообщения
Для MR1:
%PIM-5-NBRCHG: neighbor 10.10.10.2 UP on interface Ethernet3
Для MR2:
%PIM-5-NBRCHG: neighbor 10.10.10.1 UP on interface Ethernet0
Это говорит о том, что роутеры установили отношение соседства по протоколу PIM друг с другом. Проверить это также можно с помощью команды:
MR1#sh ip pim neighbor
PIM Neighbor Table
Mode: B — Bidir Capable, DR — Designated Router, N — Default DR Priority, S — State Refresh Capable
| Neighbor Address | Interface | Uptime/Expires | Ver | DR Prio/Mode |
| 10.10.10.2 | Ethernet3 | 00:03:05/00:01:37 | v2 | 1 / DR S |
Не забываем про TTL.
В качестве тестового сервера мне было удобно использовать плеер VLC. Однако, как позже обнаружилось, даже если выставить через GUI достаточный TTL, он все равно (надеюсь только в использованной мной версией) упорно отправлял multicast пакеты с TTL=1. Запускать упрямого пришлось с опцией «vlc.exe –ttl 3» т.к. у нас на пути будет два роутера, каждый из которых уменьшает TTL пакета на единицу.
Как же все таки обнаружить проблему с TTL? Один из способов. Пусть сервер вещает канал 224.12.0.3 с TTL=2, тогда на роутере MR1 пакеты проходят нормально, а за роутером MR2 клиенты уже не смогут смотреть свой мультик.
Обнаруживается это с помощью команды «sh ip traffic» на MR2. Смотрим на поле “bad hop count” – это число пакетов, которые “умерли”, как им и отмеряно, по TTL=0.
MR2#sh ip traffic
IP statistics:
Rcvd: 36788 total, 433 local destination
0 format errors, 0 checksum errors, 2363 bad hop count
……………………………………
Если этот счетчик быстро увеличивается, значит — проблема в TTL.
Show ip mroute
После включения вещания трех каналов на сервере в таблице multicast маршрутизации наблюдаем следующее:
MR1# sh ip mroute
(*, 224.12.0.1), 00:03:51/stopped, RP 10.0.0.1, flags: SP
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list: Null
(10.0.0.2, 224.12.0.1), 00:03:52/00:02:50, flags: PT
Incoming interface: Ethernet0, RPF nbr 0.0.0.0
Outgoing interface list: Null
(*, 224.12.0.2), 00:00:45/stopped, RP 10.0.0.1, flags: SP
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list: Null
(10.0.0.2, 224.12.0.2), 00:00:45/00:02:50, flags: PT
Incoming interface: Ethernet0, RPF nbr 0.0.0.0
Outgoing interface list: Null
(*, 224.12.0.3), 00:00:09/stopped, RP 10.0.0.1, flags: SP
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list: Null
(10.0.0.2, 224.12.0.3), 00:00:09/00:02:59, flags: PT
Incoming interface: Ethernet0, RPF nbr 0.0.0.0
Outgoing interface list: Null
Видим, что появились маршруты вида (S,G), например (10.0.0.2, 224.12.0.3), т.е. зарегистрировался источник 10.0.0.2, который вещает для группы 224.12.0.3. А так же маршруты с RP до клиента: (*,G), например (*, 224.12.0.3) – которые они будут использовать, так называемое общее для всех дерево.
Как только на интерфейс MR1 (RP) приходит запрос на получение канала 1, в multicast таблице маршрутизации происходят следующие изменения:
MR1#sh ip mroute
…………………
(*, 224.12.0.1), 00:33:16/00:02:54, RP 10.0.0.1, flags: S
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
Ethernet3, Forward/Sparse, 00:02:37/00:02:53
(10.0.0.2, 224.12.0.1), 00:33:17/00:03:25, flags: T
Incoming interface: Ethernet0, RPF nbr 0.0.0.0
Outgoing interface list:
Ethernet3, Forward/Sparse, 00:02:37/00:02:53
Стало видно, что приходят запросы на эту группу с порта Ethernet3.
RPF проверка
Возможна ситуация, когда роутер получает multicast поток на двух интерфейсах. Кого из этих двух интерфейсов роутер будет считать источником?
Для этого он выполняет проверку RPF (Reverse Path Forwarding) — проверяет по обычной unicast таблице маршрутизации маршрут до источника и выбирает тот интерфейс, через который идет маршрут до этого источника. Эта проверка необходима для того чтобы избежать образования петель.
Отследить, как источник проходит проверку RPF можно с помощью команды:
MR2#sh ip rpf ?
Hostname or A.B.C.D IP name or address of multicast source
MR2#sh ip rpf 10.0.0.2
RPF information for? (10.0.0.2)
RPF interface: Ethernet0
RPF neighbor:? (10.10.10.1)
RPF route/mask: 10.0.0.0/24
RPF type: unicast (static)
RPF recursion count: 0
Doing distance-preferred lookups across tables
Ну, вот и появилась та статейка, которую я бы с удовольствием нашла, на начальном этапе изучения multicast routing’а для IPTV. Я не волшебник, я только учусь… Потому, с радостью выслушаю все пожелания, замечания и советы. А так же, очень надеюсь, что для кого-то она окажется полезной. =)
UPD: Разрешите представить ее. Елена Сахно — lena_sakhno
Приручаем multicast
Остановимся на анализе мультикаст-трафика через IGMP-протокол. Рассмотрим реализацию работы протокола IGMP, работы протокола PIM, отправки JOIN-запросов. После анализа проблемы была разработана оптимальная конфигурация сетевого оборудования, эффективная настройка QOS. Данная задача появилась после обнаружения проблемы в сети, такой как прерывание сигнала у клиентов, наличие фризов и прерывание звука.
IGMP — Internet Group Management Protocol — это сетевой протокол взаимодействия абонентов мультикаст-трафика и ближайшего к ним сетевого оборудования.
Пользователь имеет подписку на следующую группу IP-адресов: 224.0.0.0 до 239.255.255.255. PIM Protocol реализован в режиме Sparse mode. Это означает, что трафик льется только на ту ветку, в которой есть клиенты, желающие войти в мультикаст-группу. Они отправляют сообщения PIM Join. Если клиенты не отправляют Join, то трафик им отправляться не будет. PIM Sparse Mode включен на двух интерфейсах. В сторону источника мультикаст-трафика и в сторону клиента. На стороне клиента имеет цифровой ресивер или абонентское устройство —IPTV-приставка.
Для справки: dense mode предполагает, что мультикаст-трафик идет до абонента, и неважно, подписывается ли он на определенный канал. Мультикаст идет во все порты, потом, если он не нужен по месту назначения, то отправляется служебный пакет PIM Prune, и трафик перестает идти по этой ветке.
IGMP-протокол реализуется в сторону клиента. PIM-протокол устанавливает соседство с другими маршрутизаторами. Для этого применяются служебные сообщения PIM Hello.
В нашей сети применялась вторая версия протокола IGMP.
Абонентское устройство, которое решает получить multicast-трафик, отправляет запрос в сообщении IGMP Membership Report (так называемый репорт).
Если абонентское устройство больше не желает получать мультикаст-трафик, то оно отправляет сообщение IGMP Leave. Эта функция реализована коммутаторах уровня доступа. IGMP Membership Group-Specific Query — повторное сообщение коммутатором в сеть о том, есть ли клиентские устройства, которые будут запрашивать мультикаст-трафик. Если их нет, то передача трафика прекращается.
IGMP snooping реализуется на сетевом оборудовании, отдельного включения функции недостаточно, необходима дополнительная настройка. После включения данной функции управляемые коммутаторы могут анализировать трафик — мультикаст-поток.
Если коммутатор обнаруживает IGMP-пакет, то он вносит порт в список мультикаст-групп. Если от абонента идет сообщение IGMP Leave, то коммутатор удаляет порт из подписчиков групп.
IGMP snooping позволяет предотвращать мультикаст шторм. Если функция IGMP snooping не включена, то оборудование ретранслирует multicast-трафик во все порты, которые находятся в одном VLAN. Это не эффективно, а также способно вызвать проблемы на сетевых устройствах, вынужденных обрабатывать высокий поток данных. Это может загружать CPU-оборудования. IGMP snooping улучшает работу сети.
Однако для того, чтобы получить мультикаст-трафик, нужно реализовать эту функции на стороне клиента. К примеру, если клиент подключен через роутер, то необходимо позаботиться о включении этой функции на роутере.
Проверить корректность работы мультикаст-вещания можно путем анализа трафика через Wireshark, после включения телевидения через VLC-медиаплеер. В настройках VLC указываем, к примеру, udp:@239.255.0.A:5500. Для передачи потока используется UDP протокол, далее идет мультикаст адрес, далее порт.
При разработке QOS учитывалось, что «красить» трафик желательно ближе к ядру сети. Его необходимо красить ближе к Randezvous Point. (Ну это для нашего случая)
На коммутаторах уровня доступа у нас применялись следующие настройки:
Глубокий анализ проблемы, применение средств диагностики и понимание работы протокола IGMP позволяет выработать эффективную и оптимальную конфигурацию мультикаст-трафика в вашей сети.
Протоколы IGMP и UPnP. Качество обслуживания и Технология SharePort
IGMP (Internet Group Management Protocol – межсетевой протокол управления группами) – протокол управления групповой (multicast) передачей данных в сетях, основанных на протоколе IP. IGMP используется маршрутизирующими устройствами и IP-узлами для организации сетевых устройств в группы.
Этот протокол является частью спецификации групповой передачи пакетов в IP-сетях. IGMP расположен выше сетевого уровня, хотя, по сути, действует не как транспортный протокол. IGMP может использоваться для поддержки потокового видео и онлайн-игр. Для таких типов приложений он позволяет использовать сетевые ресурсы более эффективно. IGMP уязвим к определенным атакам, и, если в нем нет необходимости, брандмауэры обычно позволяют пользователю отключить функцию IGMP.
Протокол IGMP используется для динамической регистрации отдельных узлов в многоадресной группе локальной сети. Узлы сети определяют принадлежность к группе, посылая IGMP-сообщения на свой локальный многоадресный маршрутизатор. По протоколу IGMP маршрутизаторы (коммутаторы L3) получают IGMP-сообщения и периодически посылают запросы, чтобы определить какие группы активны или неактивны в данной сети.
В общем случае протокол IGMP определяет следующие типы сообщений:
- запрос о принадлежности к группе (Membership Query);
- ответ о принадлежности к группе (Membership Report);
- сообщение о выходе из группы (Leave Group Message).
В настоящее время существуют три версии протокола IGMP:
- IGMP версии 1 (IGMP v1, описан в RFC1112);
- IGMP версии 2 (IGMP v2, описан в RFC2236);
- IGMP версии 3 (IGMP v3, описан в RFC3376).
Протокол IGMP используется только в сетях с адресацией IPv4, так как в сетях с адресацией IPv6 групповая передача пакетов реализована по-другому.
Что такое IPTV?
Услугу IPTV (Internet Protocol Television, IP-телевидение) предоставляет провайдер. IPTV напоминает обычное кабельное телевидение. Разница в том, что услуга IPTV предоставляется не по коаксиальному кабелю, а по тому же каналу, что и Интернет (ADSL модем или Ethernet).
Технология IPTV представляет собой трансляцию каналов преимущественно в форматах MPEG2/MPEG4 по транспортной сети провайдера, с последующим просмотром на компьютере.
Межсетевые экраны по умолчанию не обрабатывают пакеты IPTV (мультикаст). Необходимо разрешить в системных правилах протокол IGMP (протокол управления подключениями к мультикаст-группам), создать правила, одно из которых будет отвечать за запрос query от сервера к межсетевому экрану, а от него уже к клиенту, второе будет переправлять ответ report от клиента к межсетевому экрану, затем от него к источнику вещания.
Кроме этого, на управляемом коммутаторе нужно включить функцию IGMP snooping. IGMP Snooping – процесс отслеживания сетевого трафика IGMP, который позволяет сетевым устройствам канального уровня (коммутаторам) отслеживать IGMP-обмен между клиентами и поставщиками (маршрутизаторами) многоадресного (multicast) IP-трафика, формально происходящий на более высоком (сетевом) уровне.
IGMP Snooping – это функция второго уровня модели OSI, которая позволяет коммутаторам изучать членов многоадресных групп, подключенных к его портам, прослушивая IGMP-сообщения (запросы и ответы) передаваемые между узлами-подписчиками и маршрутизаторами (коммутаторами L3) сети.
Рис. 5.1. Передача многоадресного трафика с поддержкой IGMP Snooping.
Когда узел, подключенный к коммутатору, хочет вступить в многоадресную группу или отвечает на IGMP-запрос, полученный от маршрутизатора (коммутатора L3) многоадресной рассылки, он отправляет IGMP-ответ, в котором указан адрес многоадресной группы. Коммутатор просматривает информацию в IGMP-ответе и создает в своей ассоциативной таблице коммутации IGMP Snooping запись для этой группы (если она не существует). Эта запись связывает порт, к которому подключен узел-подписчик, с портом, к которому подключен маршрутизатор (коммутатор L3) многоадресной рассылки и МАС-адрес многоадресной группы.
Если коммутатор получает IGMP-ответ для этой же группы от другого узла данной VLAN, то он добавляет номер порта в уже существующую запись ассоциативной таблицы коммутации IGMP Snooping.
Формируя таблицу коммутации многоадресной рассылки, коммутатор осуществляет передачу многоадресного трафика только тем узлам, которые в нем заинтересованы.
После включения IGMP Snooping, коммутатор начинает анализировать все IGMP-пакеты между подключенными к нему компьютерами-клиентами и маршрутизаторами-поставщиками multicast-трафика. Обнаружив IGMP-запрос (report) клиента на подключение к мультикаст-группе, коммутатор включает порт, к которому тот подключен, в список ее членов (для ретрансляции группового трафика). И наоборот – услышав запрос «IGMP Leave» (покинуть), удаляет соответствующий порт из списка группы.
Направлять сообщения IGMP query клиенту может маршрутизатор IGMP (IGMP Snooping на управляемом коммутаторе) или сервер вещания, поддерживающий функцию генерирования IGMP query (тогда коммутатор не нужен).
Рис. 5.2. Схема подключения оборудования для прохождения мультикастового потока через межсетевой экран NetDefend
Eсли доступ в Интернет осуществляется через Интернет-маршрутизатор, необходимо убедиться, что данное устройство поддерживает IGMP/multicast. Не во всяком маршрутизаторе присутствует эта функция.
Активировать опцию для прохождения мультикастового потока ( рис. 5.3) можно в настройках Интернет-маршрутизатора: Enable Multicast Streams или IGMP (если такого пункта в настройках нет, а модель поддерживает функцию, необходимо обновить прошивку).
увеличить изображение
Рис. 5.3. Активирование функции IGMP/мультикаст для прохождения мультикастового потока на примере Интернет-маршрутизатора DIR-857
Поддержка UPnP
Служба UPnP (Universal Plug and Play) – сетевая архитектура, предоставляющая возможность легко и быстро организовывать обмен данными между любыми устройствами в сети, автоматически определяя, подключая и настраивая эти устройства для работы с локальными сетями. Сетевые продукты, использующие технологию Universal Plug and Play, заработают сразу, как только будут физически подключены к сети. UPnP поддерживает практически все технологии сетевых инфраструктур – как проводные, так и беспроводные.
UPnP – это расширение стандартов Plug-and-Play для упрощения управления устройствами в сети, т.е. автоматическое конфигурирование устройств (программных или аппаратных маршрутизаторов), которые эту службу поддерживают. В частности, программа на компьютере в локальной сети может обратиться к маршрутизатору «на языке» UPnP с указанием перенаправить на себя нужный порт.
Практически все модели Интернет-маршрутизаторов серий DI-xxx и DIR-xxx поддерживают службу Universal Plug and Play.
Активирование UPnP представлено на рис. 5.3 на примере Интернет-маршрутизатора DIR-857.
Протоколы IGMP и UPnP. Качество обслуживания и Технология SharePort
IGMP (Internet Group Management Protocol – межсетевой протокол управления группами) – протокол управления групповой (multicast) передачей данных в сетях, основанных на протоколе IP. IGMP используется маршрутизирующими устройствами и IP-узлами для организации сетевых устройств в группы.
Этот протокол является частью спецификации групповой передачи пакетов в IP-сетях. IGMP расположен выше сетевого уровня, хотя, по сути, действует не как транспортный протокол. IGMP может использоваться для поддержки потокового видео и онлайн-игр. Для таких типов приложений он позволяет использовать сетевые ресурсы более эффективно. IGMP уязвим к определенным атакам, и, если в нем нет необходимости, брандмауэры обычно позволяют пользователю отключить функцию IGMP.
Протокол IGMP используется для динамической регистрации отдельных узлов в многоадресной группе локальной сети. Узлы сети определяют принадлежность к группе, посылая IGMP-сообщения на свой локальный многоадресный маршрутизатор. По протоколу IGMP маршрутизаторы (коммутаторы L3) получают IGMP-сообщения и периодически посылают запросы, чтобы определить какие группы активны или неактивны в данной сети.
В общем случае протокол IGMP определяет следующие типы сообщений:
- запрос о принадлежности к группе (Membership Query);
- ответ о принадлежности к группе (Membership Report);
- сообщение о выходе из группы (Leave Group Message).
В настоящее время существуют три версии протокола IGMP:
- IGMP версии 1 (IGMP v1, описан в RFC1112);
- IGMP версии 2 (IGMP v2, описан в RFC2236);
- IGMP версии 3 (IGMP v3, описан в RFC3376).
Протокол IGMP используется только в сетях с адресацией IPv4, так как в сетях с адресацией IPv6 групповая передача пакетов реализована по-другому.
Что такое IPTV?
Услугу IPTV (Internet Protocol Television, IP-телевидение) предоставляет провайдер. IPTV напоминает обычное кабельное телевидение. Разница в том, что услуга IPTV предоставляется не по коаксиальному кабелю, а по тому же каналу, что и Интернет (ADSL модем или Ethernet).
Технология IPTV представляет собой трансляцию каналов преимущественно в форматах MPEG2/MPEG4 по транспортной сети провайдера, с последующим просмотром на компьютере.
Межсетевые экраны по умолчанию не обрабатывают пакеты IPTV (мультикаст). Необходимо разрешить в системных правилах протокол IGMP (протокол управления подключениями к мультикаст-группам), создать правила, одно из которых будет отвечать за запрос query от сервера к межсетевому экрану, а от него уже к клиенту, второе будет переправлять ответ report от клиента к межсетевому экрану, затем от него к источнику вещания.
Кроме этого, на управляемом коммутаторе нужно включить функцию IGMP snooping. IGMP Snooping – процесс отслеживания сетевого трафика IGMP, который позволяет сетевым устройствам канального уровня (коммутаторам) отслеживать IGMP-обмен между клиентами и поставщиками (маршрутизаторами) многоадресного (multicast) IP-трафика, формально происходящий на более высоком (сетевом) уровне.
IGMP Snooping – это функция второго уровня модели OSI, которая позволяет коммутаторам изучать членов многоадресных групп, подключенных к его портам, прослушивая IGMP-сообщения (запросы и ответы) передаваемые между узлами-подписчиками и маршрутизаторами (коммутаторами L3) сети.
Рис. 5.1. Передача многоадресного трафика с поддержкой IGMP Snooping.
Когда узел, подключенный к коммутатору, хочет вступить в многоадресную группу или отвечает на IGMP-запрос, полученный от маршрутизатора (коммутатора L3) многоадресной рассылки, он отправляет IGMP-ответ, в котором указан адрес многоадресной группы. Коммутатор просматривает информацию в IGMP-ответе и создает в своей ассоциативной таблице коммутации IGMP Snooping запись для этой группы (если она не существует). Эта запись связывает порт, к которому подключен узел-подписчик, с портом, к которому подключен маршрутизатор (коммутатор L3) многоадресной рассылки и МАС-адрес многоадресной группы.
Если коммутатор получает IGMP-ответ для этой же группы от другого узла данной VLAN, то он добавляет номер порта в уже существующую запись ассоциативной таблицы коммутации IGMP Snooping.
Формируя таблицу коммутации многоадресной рассылки, коммутатор осуществляет передачу многоадресного трафика только тем узлам, которые в нем заинтересованы.
После включения IGMP Snooping, коммутатор начинает анализировать все IGMP-пакеты между подключенными к нему компьютерами-клиентами и маршрутизаторами-поставщиками multicast-трафика. Обнаружив IGMP-запрос (report) клиента на подключение к мультикаст-группе, коммутатор включает порт, к которому тот подключен, в список ее членов (для ретрансляции группового трафика). И наоборот – услышав запрос «IGMP Leave» (покинуть), удаляет соответствующий порт из списка группы.
Направлять сообщения IGMP query клиенту может маршрутизатор IGMP (IGMP Snooping на управляемом коммутаторе) или сервер вещания, поддерживающий функцию генерирования IGMP query (тогда коммутатор не нужен).
Рис. 5.2. Схема подключения оборудования для прохождения мультикастового потока через межсетевой экран NetDefend
Eсли доступ в Интернет осуществляется через Интернет-маршрутизатор, необходимо убедиться, что данное устройство поддерживает IGMP/multicast. Не во всяком маршрутизаторе присутствует эта функция.
Активировать опцию для прохождения мультикастового потока ( рис. 5.3) можно в настройках Интернет-маршрутизатора: Enable Multicast Streams или IGMP (если такого пункта в настройках нет, а модель поддерживает функцию, необходимо обновить прошивку).
увеличить изображение
Рис. 5.3. Активирование функции IGMP/мультикаст для прохождения мультикастового потока на примере Интернет-маршрутизатора DIR-857
Поддержка UPnP
Служба UPnP (Universal Plug and Play) – сетевая архитектура, предоставляющая возможность легко и быстро организовывать обмен данными между любыми устройствами в сети, автоматически определяя, подключая и настраивая эти устройства для работы с локальными сетями. Сетевые продукты, использующие технологию Universal Plug and Play, заработают сразу, как только будут физически подключены к сети. UPnP поддерживает практически все технологии сетевых инфраструктур – как проводные, так и беспроводные.
UPnP – это расширение стандартов Plug-and-Play для упрощения управления устройствами в сети, т.е. автоматическое конфигурирование устройств (программных или аппаратных маршрутизаторов), которые эту службу поддерживают. В частности, программа на компьютере в локальной сети может обратиться к маршрутизатору «на языке» UPnP с указанием перенаправить на себя нужный порт.
Практически все модели Интернет-маршрутизаторов серий DI-xxx и DIR-xxx поддерживают службу Universal Plug and Play.
Активирование UPnP представлено на рис. 5.3 на примере Интернет-маршрутизатора DIR-857.