- Настройка IGMP в локальной сети для контроля широковещательных IPTV потоков
- Описание протокола IGMP
- Общая схема сети
- Multicast routing для IPTV
- Введение
- Какой вид трафика использовать для IPTV?
- Немного о том, как работает IGMP.
- Настройка multicast routing.
- Про режимы протокола PIM и сам протокол.
- В чем же разница?
- Посмотрим, что будет происходить после настройки роутеров.
- Не забываем про TTL.
- Show ip mroute
- RPF проверка
Настройка IGMP в локальной сети для контроля широковещательных IPTV потоков
Основным механизмом доставки телевизионных программ до абонентов в локальных сетях является вещание в виде широковещательных IP-пакетов (иногда такой поток называют «мультикаст» от английского «multicast»). Особенностью данной технологии является то, что все мультимедийные потоки всегда направляются в сеть, вне зависимости от количества активных подписчиков в настоящий момент времени. Например, для передачи 20 телевизионных каналов со средним битрейтом 4 Мбит/сек на канал потребует порядка 4*20 = 80 Мбит/сек пропускной способности. Эти 80 Мбит/сек будут направляться в сеть, даже если ни один абонент в данный момент не подключен к сети, а также в случае, если количество активных абонентов гораздо более 1000.
Вещание мультимедийного контента в локальную сеть в виде широковещательных пакетов сопряжено с необходимостью четко контролировать какие пакеты и к какому получателю должны доставляться. Необходимо избегать ситуации, когда все пакеты доставляются всем абонентам. В этом случае абонентские устройства будут тратить ресурсы на обработку «непрошенных» пакетов и в итоге не смогут выполнять свои функции. Абоненту необходимо доставлять пакеты только того потока, который он запросил. Для этого абонентское оборудование сообщает о желании вступить в определенную группу по протоколу IGMP. Далее этот запрос регистрируется на маршрутизаторе, в терминах IGMP это устройство называется «Querier». После успешной регистрации, Ethernet коммутатор приступает к копированию широковещательных пакетов, предназначенных для данной группы, в порт, к которому подключен абонент.
Благодаря протоколу IGMP, Ethernet-коммутаторы могут определить какие широковещательные пакеты копировать в абонентский порт, а какие нет.
В настоящей статье описывается настройка протокола IGMP в локальной сети, построенной на Ethernet-коммутаторе Cisco Catalyst 2950T и DVB-IP стримере производства компании НетАП на базе ОС Linux. В качестве абонентских устройств выступают IP STB AmiNET 110 и персональный компьютер на базе ОС Windows либо Linux с мультимедиа проигрывателем VLC [1].
Описание протокола IGMP
В настоящий момент существует три версии этого протокола — IGMP v1 [2], IGMP v2 [3], IGMP v3 [4]. Наиболее распространена версия 2.
Адрес группы представляет собой широковещательный IP-адрес, на который осуществляется рассылка контента. Например, 224.200.200.205.
В IGMPv2 существуют следующие типы сообщений:
- Запрос о составе группы.
- Отчет о составе группы.
- Сообщение о выходе из группы.
Рассмотрим назначение этих сообщений более детально.
При подключении к IGMP-группе абонентское устройство посылает в сеть IGMP пакет с типом «Отчет о составе группы», тем самым давая понять, что желает получать пакеты для данной группы.
При выходе из группы абонентское устройство посылает в сеть IGMP пакет с типом «Сообщение о выходе из группы».
Маршрутизатор (querier) периодически посылает в сеть IGMP запрос с типом «Запрос о составе группы» для выяснения состава группы на текущий момент времени. Если ответа от абонентских устройств не последовало, то маршрутизатор отключает эту группу и более не пересылает пакеты для данной группы.
Общая схема сети
Рассмотрим работу протокола IGMP на тестовом стенде в компании НетАП. Общая схема сети представлена на рисунке 1.
Рис. 1. Тестовый стенд — общая схема сети.
Абонентское устройство IP STB
В качестве IP STB была использована модель AmiNET 110 (Рис. 2).
Рис. 2. Абонентское устройство IP STB
По умолчанию IP STB после загрузки отображает стартовую страницу WEB-браузера и предлагает ввести URL. Для просмотра медиаконтента передаваемого в широковещательной группе 224.200.200.205 (на тестовом стенде это телевизионный канал «Россия») необходимо ввести следующий адрес:
При этом IP STB отправит в сеть IGMP -запрос о вступлении в группу 224.200.200.205. Если IGMP корректно функционирует в сети, то абонентское устройство сможет «увидеть» этот поток. При нажатии клавиши «Esc» IP STB прекратит отображать поток. При этом в сеть будет отправлен IGMP-запрос о выходе из группы.
Персональный компьютер абонента с установленным медиапроигрывателем VLC
С точки зрения протокола IGMP медиапроигрыватель VLC функционирует аналогично IP STB AmiNET 110.
Ethernet коммутатор Cisco Catalyst 2950T
Поддерживает перехват и анализ IGMP пакетов. Этот функционал называется «igmp snooping». Именно благодаря анализу проходящих IGMP пакетов, коммутатор узнает к каким портам подключены абоненты и в каких группах они состоят.
Для включения этой функции необходимо в настройках коммутатора ввести следующие команды:
Для анализа работы «igmp snooping» на коммутаторе можно ввести следующие команды:
При этом коммутатор будет выводить на консоль информацию о перехваченных IGMP пакетах, а так же информацию о том какие действия были предприняты. Например, прием IGMP-пакета от клиента о вступлении в группу 224.200.200.205 будет выглядеть следующим образом:
Как видно из этих отладочных сообщений коммутатор зафиксировал вступление абонента 10.1.2.16, подключенного к порту Fa0/2 в группу 224.200.200.205. Согласно этой информации в порт Fa0/2 теперь будут поступать пакеты для 224.200.200.205.
При выходе абонента из группы на консоли появятся следующие сообщения:
Как видно из этих сообщений, коммутатор произвел отключение абонента из группы 224.200.200.205, а так же удалил группу т.к. в данной группе больше не осталось активных абонентов.
Стоит отметить, что коммутатор только анализирует проходящие IGMP пакеты. При этом он не выполняет функции маршрутизатора (Querier). Для этих целей необходимо устанавливать маршрутизатор Cisco либо запускать пакет mrouted на сервере с ОС Linux.
Еще одной немаловажной деталью является то, что если не настроен «igmp snooping» коммутатор рассылает все широковещательные пакеты во все порты. При существенном количестве потоков это может вызвать перегрузки абонентских устройств подключенных к этому коммутатору. По наблюдениям специалистов компании НетАП, широковещательный поток порядка 20 Мбит/сек способен «подвесить» некоторые беспроводные точки доступа, что конечно же недопустимо. В связи с этим необходимо опасаться ситуации, когда по каким либо причинам отключается IGMP в сети.
NetUP DVB-IP стример, RCA-in
Данное устройство производится компанией НетАП и представляет собой высокопроизводительный IP-стример. В качестве источника мультимедийных данных могут выступать спутниковые каналы (DVB-S), аналоговые видео-входы (RCA-in) с видео-камер, транспортные потоки (ASI-in) и др. На выходе стример имеет два Gigabit Ethernet порта для отправки сформированных транспортных потоков в IP-cеть. Пакеты отправляются в режиме широковещания.
Стример построен на базе ОС Linux. В связи с этим имеется возможность установить дополнительно необходимые сервисы. Как упоминалось выше, коммутатор не выполняет функции маршрутизатора широковещательных пакетов (Querier), поэтому данный функционал возложим на стример. Для этого необходимо установить пакет mrouted и запустить его. Конфигурационный файл /etc/mrouted.conf можно оставить со значениями по умолчанию. Стоит отметить, что в системе должны быть активированы два сетевых интерфейса, в противном случае процесс mrouted не запустится.
Проконтролировать текущее состояние процесса можно, послав сигнал USR1. Для этого выполните команду:
В результате процесс mrouted сбросит текущее состояние в файл /var/tmp/mrouted.dump. Пример содержимого этого файла:
Как видно из этого файла, на интерфейсе eth2 у нас присутствует широковещательная группа 224.200.200.205, в которую подключен абонент 10.1.2.16.
В случае если в сети находятся два или более IGMP querier, то функции на себя берет тот, у которого меньше IP-адрес. Благодаря такой логике возможно дублирование функций между двумя и более широковещательными маршрутизаторами для большей отказоустойчивости.
Корректность работы IGMP можно проверить на Ethernet коммутаторе Cisco Catalyst. Для этого необходимо выполнить команды:
Согласно выводу этих команд, коммутатор корректно определил маршрутизатор (Querier) и присутствие в сети группы 224.200.200.205. При этом так же указан абонент, подключенный к этой группе и порт, на котором этот абонент находится. Соответственно только в этот порт направляются пакеты для группы 224.200.200.205. При этом пакеты для других широковещательных групп удаляются на коммутаторе и не направляются ни в один из портов т.к. у нас нет больше активных абонентов.
При этом стоит отметить, что стример посылает в сеть все каналы, независимо от количества активных абонентов. Проконтролировать наличие потоков можно, выполнив на стримере команду:
Вывод будет содержать таблицу текущих широковещательных потоков, с указанием битрейта и переданных байт:
Как видно из этой распечатки, стример постоянно передает в сеть 20 потоков (18 телевизионных каналов и 2 радио станции). При этом, как уже отмечалось выше, количество реально работающих абонентов может сильно варьироваться с течением времени. Благодаря работе протокола IGMP каждый абонент получает именно тот поток, который он запросил.
В случае использования маршрутизатора Cisco (на стенде компании НетАП используется модель Cisco 7140-2FE, IOS 12.3), поддержка маршрутизации широковещательных пакетов включается следующими командами:
Проконтролировать широковещательные группы при этом можно командой:
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 | MR2#sh run ip multicast-routing |
Команда «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«.
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
