Igmp трафик. Технология Multicast: рациональная передача мегапиксельного видеотрафика. Прогрессивное применение Multicast
Относительно недавно мне посчастливилось познакомить и даже поконфигурять multicast routing для IPTV. Изначально, я с этой темой была совершенно не знакома, и это заставило меня вылакать горлышко от цистерны водки перекопать огромное количество документации, чтобы войти в курс дела.
И вот незадача. Обычно в документации выкладывают все и сразу и для человека, впервые столкнувшегося с этой темой, не понятно с чего начать. Во время чтения pdf’ок я ловила себя на мысли, что было бы неплохо наткнуться где-нибудь на статью, которая могла бы коротким путем провести от теории к практике, чтобы понять с чего стоит начать и где заострить внимание.
Посмотрим, что будет происходить после настройки роутеров
Чтобы настроить протокол управления группами, настройте это на интерфейсе маршрутизатора, обращенного к коммутатору. Затем настройте это на коммутаторе. Монитор многоадресной маршрутизации облегчает автоматическое обнаружение ошибок в большой инфраструктуре маршрутизации многоадресной передачи.
Начните тест с показанной здесь команды. Менеджер тестов отправляет управляющие сообщения отправителю теста и тестовому приемнику в соответствии с параметрами тестирования. Тестовый приемник присоединяется к группе и контролирует тестовые пакеты, отправленные от тестирующего отправителя.
Мне не удалось обнаружить такую статью. Это побудило меня написать эту статейку для тех, кто также как и я столкнется с вопросом, что это за зверь IPTV и как с ним бороться.
Введение
Это моя самая первая статья (но не последняя! есть еще много зверей), постараюсь изложить все как можно доступнее.Первым делом озвучим несколько понятий, чтоб исключить дальнейшие недопонимания. Существует три вида трафика:
Чтобы отобразить отчет о состоянии для менеджера тестов, введите следующую команду. На выходе показано, что приемник отправил два отчета о состоянии на заданную метку времени. Каждый отчет содержит одну потерю пакета во время окна интервала. Чтобы остановить тест, введите следующую команду.
Приемник контролирует одни и те же пакеты с одинаковым интервалом по умолчанию. Обратитесь к подробному обсуждению этих и других распространенных проблем, симптомов и разрешений. Эти адреса назначаются интерфейсам, а не сетевым узлам. Поскольку данный интерфейс принадлежит к одному узлу, любой из одноадресных адресов этого интерфейса может использоваться как идентификатор узла.
- unicast - одноадресный, один источник потока один получатель
- broadcast - широковещательный, один источник, получатели все клиенты в сети
- multicast - многоадресный, один отправитель, получатели некоторая группа клиентов
Какой вид трафика использовать для IPTV?
Очевидно, что для вещания каналов наибольшее предпочтение отдается multicast.
Любой TV-канал, который мы хотим вещать в сеть, характеризуется адресом группы, который выбирается из диапазона, зарезервированного для этих целей: 224.0.0.0 – 239.255.255.255
.
Многоадресная рассылка: идентифицирует группу интерфейсов, так что пакет, отправленный на многоадресный адрес, доставляется на все интерфейсы в группе. Поле переменной длины, содержащее эти начальные биты, называется форматированным префиксом. Первоначальное распределение этих префиксов показано в следующей таблице.
Чтобы разобраться с тем, что такое PIM, обратимся к сети гораздо более сложной
Новые типы одноадресных адресов могут быть определены в будущем. Некоторые из этих типов одноадресных адресов приведены ниже, в качестве примера. Это адрес, который имеет локальную область маршрутизации. то есть внутри подсети или в сети абонента. В конце концов, он может также иметь глобальный объем коммуникации.
Для работы IPTV необходим роутер, поддерживающий multicast (далее MR). Он будет отслеживать членство того или иного клиента в определенной группе, т.е. постоянно следить какому клиенту какой отправлять TV-канал.
Для того чтобы клиент смог зарегистрироваться в одной из этих групп и смотреть TV-канал используется протокол IGMP (Internet Group Management Protocol).
Локальное использование сайта, используемое на одном веб-сайте. Адрес многоадресной рассылки является идентификатором группы интерфейсов. Интерфейс может принадлежать любому количеству групп многоадресной передачи. Автоматическое переадресация: маршрутизация на новый адрес. . Эта опция используется исходным устройством для отображения одного или нескольких промежуточных узлов, которые должны быть посещены на пути назначения пакета протокола.
Это ключ, позволяющий им взаимодействовать с хостами, которые содержат новые функции, такие как выбор поставщика или расширенные адреса. Три примера показывают, как использовать последовательности адресов. В этих примерах последовательности адресов показаны в списке отдельных адресов, разделенных запятыми, которые.
Немного о том, как работает IGMP.
Есть сервер, который включен в роутер MR. Этот сервер вещает несколько TV-мультиков, например:Клиент включает канал 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 ".
Они могут быть постоянно отмечены и известны, как в приведенных выше примерах, или они могут использоваться временно для определенной цели. Пакет, отправленный на многоадресный адрес, доставляется на все интерфейсы, идентифицированные этим адресом. Обычно это адреса, включенные в группу многоадресной рассылки.
Запрос многоадресного прослушивателя; Версия 2 для многоадресного прослушивателя. То, как маршрутизаторы фактически реализуют многоадресную рассылку, зависит от сетевых технологий, используемых в слое. Его использование в одноранговых ссылках довольно тривиально, в отличие от использования в многоточечных ссылках. Он должен быть реализован из конфигурации вашей ссылки в беспорядочном режиме по ссылкам с возможностями вещания; или для этого требуются логические протоколы уровня 2 или каналы не-широковещательного уровня.
Про режимы протокола 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 ".
Следующие восемь бит в многоадресном адресе определяют флаги и область действия. Область действия состоит из группы узлов, в которой пакеты предназначены в соответствии с их происхождением. Их значения показаны в таблице, показанной на рисунке ниже. Флаги изначально указывают, где известен многоадресный адрес, адрес по умолчанию или он состоит из временно заданного значения. Этот одноадресный префикс устраняет необходимость в дополнительном протоколе для выделения уникального многоадресного адреса.
Требования к ресурсам системы
Затем трафик из этих источников сначала направляется в точку встречи, а затем направляется в группу принимающих членов или получателей. Для известных многоадресных адресов 4 бита индикации должны состоять из нулей. Первый бит индикатора флага зарезервирован и должен быть.
(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-каналы. Рассылка начнется только тогда, когда от клиента придет на нее запрос.
Он предоставляет простой способ распределения многоадресных адресов, принадлежащих или распределенных сетевым префиксом, в следующем образованном, без добавления любого адреса протокола для нового распределения многоадресных адресов. Восемь битов, следующих за метками и областью, должны быть равны нулю. Следующие восемь бит должны указывать длину для префикса, расширенную до 64, за которой следует префикс, выравнивается по левому краю и заполняется нулем.
Multicast и Unicast: ключевые различия
Обратите внимание, что объем этих многоадресных адресов не может превышать объем встроенных префиксов. Раздел структурирован в подтемах, расположенных следующим образом. Хотя эта версия имеет те же функции, что и ее предшественник, например, сообщения об ошибках в обработке пакетов, диагностике и отправке сообщений о характеристиках сети, оба они несовместимы и имеют существенные отличия.
Т.е. в PIM-DM MR отправляет всем, а потом убирает ненужное, а в PIM-SM MR начинает вещание только по запросу.
Если члены группы разбросаны по множеству сегментов сети, что характерно для IPTV, PIM-DM будет использовать большую часть полосы пропускания. А это может привести к снижению производительности. В этом случае лучше использовать PIM-SM.
Такое изменение разработано с простой целью сокращения множественности протоколов, что является пагубным, поскольку оно ухудшает согласованность и увеличивает размер реализаций. Ниже перечислены ваши идентификационные данные, местоположение, формат ваших пакетов и их классы.
Зачем отслеживать сетевой трафик?
Примером его использования является значение 2, которое представляет сообщение «Слишком большое количество пакетов». В поле 8-битного кода: отображается дополнительная информация о причине сообщения. В следующих двух таблицах показаны типы сообщений, принадлежащие каждому из этих классов.
Между PIM-DM и PIM-SM существуют еще отличия.
PIM-DM строит дерево отдельно для каждого источника определенной multicast группы, т.е. multicast маршрут будет характеризоваться адресом источника и адресом группы. В multicast таблице маршрутизации будут записи вида (S,G), где S - source, G - group.
Протокол обнаружения окрестности был разработан с целью решения проблем взаимодействия между соседними узлами в сети. В случае автоконфигурации узлов протокол обеспечивает поддержку реализации трех функциональных возможностей. Обнаружение параметров: действует на обнаружение узлом информации о ссылке и в Интернете. В случае передачи пакетов между узлами предоставляется поддержка для реализации шести функциональных возможностей.
Для этого было зарезервировано 5 типов сообщений. Маршрутизатор Запрос, Маршрутизатор Тип объявления, Соседний Тип запроса, Соседства Тип объявления, Тип перенаправления, тип. Каждое из этих сообщений с их соответствующей информацией будет подробно описано ниже.
У 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):
Все остальные роутеры должны знать маршрут до 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
(10.0.0.2, 224.12.0.1), 00:03:52/00:02:50, flags: PT
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:
(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 таблице маршрутизации маршрут до источника и выбирает тот интерфейс, через который идет маршрут до этого источника. Эта проверка необходима для того чтобы избежать образования петель.
В предыдущих двух статьях мы построили головную станцию (стример) и научились транслировать услугу IPTV Unicast-ом при помощи relaying. По большому счету, многим небольшим провайдерам этого достаточно, особенно если представить, что услуга IPTV носит некоммерческий, а маркетинговый характер. Однако для того, чтобы предложить своим клиентам качественный, легко управляемый, коммерческий продукт, с большим выбором пакетов телепрограмм, изложенный ранее метод не подходит. На помощь таким провайдерам приходит трансляция IPTV при помощи multicast рассылок.
Multicast
На вопрос, что же такое Multicast легко найти ответ, так, например, Википедия считает, что это специальная форма широковещания, при которой сетевой пакет одновременно направляется определённому подмножеству адресатов - не одному (unicast), и не всем (broadcast). С данной формулировкой трудно не согласиться. Технология IP Multicast очень выгодна в использовании, когда один и тот же набор данных должны получать сотни и тысячи подписчиков на эти данные, без увеличения нагрузки на сеть. Довольно трудно себе представить сервер, способный выдать хотя бы пятимегабитный поток данных тысячам потребителей. Так как обслуживание двухсторонних соединений процесс довольно ресурсоемкий, да еще и дублирование одних и тех же данных явное свидетельство нерациональной расточительности.
IP Multicast - это диапазон IP адресов с 224.0.0.0 до 239.255.255.255. Для того, чтоб использовать Multicast рассылки в Вашей сети необходимо выполнить ряд условий:
Сегмент сети, в котором планируется использование Multicast, должен быть построен на управляемых коммутаторах;
Управляемые коммутаторы должны поддерживать протокол IGMP, при помощи которого определяется членство в Multicast группе порта.
Подходы к реализации Multicast вещания
На сегодняшний день существует несколько технологий доставки Multicast трафика подписчикам, основные из них это:
- PIM-DM в связке с IGMP-snooping;
- PIM-SM в связке с IGMP-snooping;
Попробуем коротко разобраться с этими подходами. Для маршрутизации multicast трафика существует специальный протокол - PIM. В свою очередь PIM имеет два режима работы:
PIM-SM (sparse mode) или режим, при котором рассылка начинается только тогда, когда появляется запрос на членство в группе.
Разница в этих режимах работы заключается в том, что при использовании режима PIM-DM multicast роутер рассылает все зарегистрированные на нем multicast группы и только потом отсекает те, в которые никто не подписался. Напротив, режим PIM-SM рассылает multicast потоки только после того, когда на него придет IGMP запрос на членство в группе multicast рассылки. Также существует еще одно существенное отличие между режимами PIM-DM и PIM-SM, заключается оно в том, что для режима PIM-SM необходима так называемая точка рандеву - RENDEZVOUS POINT (RP) . Точка рандеву - это место, где регистрируются все источники Multicast потоков. Таким образом, все Multicast потоки собираются в этой точке и из нее выдаются членам группы. В итоге, потребители Multicast потоков абсолютно ничего не знают об источнике потока.
Также существует еще один способ доставки IPTV потребителям - это MVR или, если перевести аббревиатуру, Регистрация Мультикастовых VLAN’ов . Суть данного способа заключается в том, что multicast трафик бежит по сети в отдельном VLAN, а вот уже MVR подмешивает этот трафик в порты, запросивших определенную Multicast группу клиентов.
Поскольку в рамки статьи не входит рассмотрение каждого из описанных выше подходов, то остановимся только на одном из них.
Реализация трансляции с использованием PIM-SM.
Для данной реализации использовался коммутатор BD-COM S3928GX, который вполне сгодиться для ядра довольно таки не маленькой сети, так как это полноценный L3 свитч на борту которого можно установить 4*10G порта XFP, а при условии, что цена очень гуманна, альтернатив сегодня не так уж и много.
На рисунке представлена примерная схема реализации:
Настройка коммутатора сводиться к следующим шагам:
1. Создадим VLAN 111 и включим в него наш стример порт 23.
2. Включим потребителя IPTV в уже существующий дефолтный VLAN 1 порт 21
3. Определим в каком режиме будет работать маршрутизация Multicast
router pim-sm4. Включим в VLAN 1 поддержку IGMP
ip igmp enable5. На VLAN 111 настроим поддержку PIM
Собственно, на этом настройка коммутатора заканчивается, а ниже я приведу полный конфиг свитча.
Switch#show conf!version 2.1.0B build 7185
service timestamps log date
service timestamps debug date
!
no spanning-tree
!
aaa authentication login default local
aaa authentication enable default none
!
username XXXX password 0 XXXX
!
ip multicast-routing
!
interface Null0
!
interface GigaEthernet0/1
!
.
.
.
interface GigaEthernet0/20
!
interface GigaEthernet0/21
!
interface GigaEthernet0/22
!
interface GigaEthernet0/23
switchport pvid 111
!
interface GigaEthernet0/24
!
interface TGigaEthernet1/1
!
interface TGigaEthernet1/2
!
interface TGigaEthernet2/1
!
interface TGigaEthernet2/2
!
interface VLAN1
ip address 192.168.2.168 255.255.255.0
no ip directed-broadcast
ip igmp enable
!
interface VLAN111
ip address 10.10.10.1 255.255.255.0
no ip directed-broadcast
ip igmp enable
!
!
!
vlan 1,111
!
!
ip igmp-snooping
no ip igmp-proxy enable
!
ip route default 192.168.2.10
ip exf
!
router pim-sm
reg-rate-limit 1
!
Switch#
Теперь пришло время проверить, а все ли работает так, как нам хотелось. Потребителем IPTV будет выступать компьютер с установленным Linux и программой VLC Player (www.videolan.org). Для удобства просмотра я подготовил маленький плэйлист с двумя ранее настроенными каналами:
#EXTM3U
#EXTINF:5, Первый
udp://@239.255.1.90:1234
#EXTINF:5, Euronews
udp://@239.255.1.91:1234
Загрузив плэйлись в плэйер, на экране появился «Первый» канал. Теперь осталось убедиться в том, что мы все правильно настроили и в наш порт прилетает единственная multicast группа. Для это запустим tcpdump и посмотрим, а что же твориться на нашем сетевом интерфейсе.
# tcpdump -ni eth0
17:43:24.413102 IP 10.10.10.2.39109 > 239.255.1.90
.1234: UDP, length 1316
17:43:24.413147 IP 10.10.10.2.39109 > 239.255.1.90
.1234: UDP, length 1316
17:43:24.418339 IP 10.10.10.2.39109 > 239.255.1.90
.1234: UDP, length 1316
17:43:24.418384 IP 10.10.10.2.39109 > 239.255.1.90
.1234: UDP, length 1316
Теперь переключим канал и опять глянем в tcpdump
# tcpdump -ni eth0
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
17:42:46.130451 IP 10.10.10.2.47782 > 239.255.1.91
.1234: UDP, length 1316
17:42:46.130495 IP 10.10.10.2.47782 > 239.255.1.91
.1234: UDP, length 1316
17:42:46.135728 IP 10.10.10.2.47782 > 239.255.1.91
.1234: UDP, length 1316
17:42:46.135782 IP 10.10.10.2.47782 > 239.255.1.91
.1234: UDP, length 1316
Как видим, при переключении телеканала IGMP отключается от одной группы и подключается к другой.