что такое igmp в роутере

Что такое igmp в роутере

Чтобы доставить мультикаст от источника до получателя существует много протоколов — IGMP, PIM, MSDP, MBGP, MOSPF, DVMRP. В настоящее время из выше перечисленных протоколов используются в основном: PIM и IGMP.

Рисунок 6.8

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

Протокол IGMP(Internet Group Management Protocol) – gротокол группового управления в Интернете, был разработан в 1989 году. IGMP—это сетевой протокол взаимодействия клиентов мультикастового трафика и ближайшего к ним маршрутизатора. С помощью этого протокола маршрутизатор узнаёт о наличии получателей мультикастового трафика и об их отключении. Роль IGMP очень проста: если клиентов нет, то передавать мультикастовый трафик в сегмент не надо. Если появился клиент, он уведомляет маршрутизатор с помощью IGMP о том, что хочет получать трафик.

Источник программ IPTV не нуждается в протоколе IGMP. Любой компьютер, подключенный к Интернету, может стать источником группового вещания, при этом ему не требуется никакого дополнительного программного обеспечения, кроме того, которое включено в состав обычной реализации стека TCP/IP.

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

При вещании ТВ программ в режиме multicast видеосервер рассылает только один видеопоток (для каждой из ТВ-программ), независимо от числа абонентов.

На участке соединения видеосервер — шлюз доступа (Ethernet-коммутатор, DSLAM) происходит трансляция всех ТВ-программ (рисунок 6.6). На участке соединения коммутатор — STB транслируется только та программа, которую выбрал абонент для просмотра. Это происходит посредством протокола IGMP.

Рисунок 6.6

В IGMP определено три типа сообщений:

1) Запрос о членстве. С помощью этого сообщения маршрутизатор пытается узнать, в каких группах состоят хосты в локальной сети, присоединенной к какому-либо его интерфейсу. Запрос о членстве существует в двух вариантах: в одном из них маршрутизатор делает общий запрос обо всех группах «IGMP General Query»(общий запрос), в другом его интересует информация только о некоторой конкретной группе, адрес которой указывается в запросе«IGMP Group Sepcific Query».

2) Отчет о членстве (IGMP Report). Этим сообщением хосты отвечают маршрутизатору, который послал в сеть запрос о членстве. В сообщении содержится информация об IP-адресе группы, в которой они состоят. Маршрутизатор, являясь членом всех групп, получает сообщения, направленные на любой групповой адрес. Для маршрутизатора, получающего ответные сообщения, важен только факт наличия членов той или иной группы, а не принадлежность конкретных хостов конкретным группам. Отчет о членстве хост может послать не только в ответ на запрос маршрутизатора, но и по собственной инициативе, когда он пытается присоединиться к определенной группе. После такого сообщения хост может рассчитывать на то, что трафик для этой группы действительно будет доставляться в сеть, к которой этот хост принадлежит.

3) Покинуть группу (IGMP Leave). Это сообщение хост может использовать, чтобы сигнализировать «своему» маршрутизатору о желании покинуть некоторую группу, в которой он до этого состоял. Получив это сообщение, маршрутизатор посылает специфический запрос о членстве членам только этой конкретной группы «IGMP Group Sepcific Query», и если не получает на него ответ (то есть это был последний хост в группе), то перестает передавать трафик группового вещания для этой группы.

Сообщения с запросами о членстве посылаются маршрутизатором регулярно с некоторой частотой. На каждом из интерфейсов с установленными средствами IGMP маршрутизаторами поддерживаются кэш-таблицы групп. Кэш-таблица содержит список всех групп, в составе которых есть хотя бы один член. Для каждой строки таблицы установлен таймаут. Маршрутизатор регулярно посылает запросы «IGMP General Query» (по умолчанию — каждые 60 секунд), чтобы проверить, что в каждой группе еще имеются члены. Если для некоторой группы ответ не поступает в течение установленного для нее тайм-аута, то соответствующая строка удаляется из кэш-таблицы, и маршрутизатор считает, что членов этой группы в сети больше нет.

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

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

Чтобы стало понятнее, как работает IPTV, рассмотрим небольшой пример (рисунок 6.9). Для работы IPTV необходим роутер, поддерживающий multicast (далее MR). Он будет отслеживать членство того или иного клиента в определенной группе, т.е. постоянно следить, какому клиенту какой отправлять TV-канал. В сети есть сервер (Мulticast источник), подключённый к роутеру MR. Этот сервер вещает TV-каналы, например:

Предположим, что клиент включает канал News, тем самым, сам не подозревая, он отправляет запрос на MR для подключения к группе 224.12.0.1. С точки зрения протокола IGMP это сообщение«IGMP Report224.12.0.1”. После получения Multicast Router’ом данного сообщения, MR регистрирует его, и Ethernet коммутатор (SW) приступает к копированию широковещательных пакетов, предназначенных для данной группы, в порт, к которому подключен клиент. Клиент начинает получать трафик.

Рисунок 6.9 – Принцип работы IGMP

Если клиент переключается на другой канал, то он сначала отправляет уведомление MR, что он отключает канал News, т.е. покидает эту группу. Для IGMP это сообщение “LEAVE 224.12.0.1” (ВЫЙТИ из группы 224.12.0.1). А затем опять шлёт сообщение «IGMP Report» для нужного канала.

Маршрутизатор MR получив сообщение “LEAVE” для какой-либо группы, должен убедиться, что больше никаких других получателей этого канала нет, посылает сообщение «IGMP Group Specific Query» дважды. И если ни один STB не откликнется, то MR перестаёт передавать трафик этой группы.

Кроме того, MR периодически (каждые 60 секунд) опрашивает всех: «к какой группе кто подключен?», для выяснения состава групп в текущей момент времени, чтобы отключать тех клиентов, с которыми оборвалась связь. При этом MR использует запрос «IGMP General Query»(Общий запрос). Если на 3 подряд «Query» не было с интерфейсов MR ответа «IGMP Report» для какой-то группы, MR удаляет этот канал из своей таблицы мультикастовой маршрутизации — перестаёт посылать трафик этого канала до тех пор, пока к этой группе не подключится, хотя бы один клиент.

После присоединения к необходимой группе, клиентское оборудование начинает принимать поток данных по протоколу UDP на порт 1234.

Таким образом, переключение каналов с дистанционного пульта-«ленивчика», столь привычное и простое для пользователей традиционного те­левидения, представляет сложность для сети IPTV. Всякий раз, когда пользо­ватель IPTV переключает канал, в сети начинает кипеть работа:

1) Во-первых, пользователя следует отключить от группы Multicast.

2) Во-вторых, подключить его к новой группе Multicast.

3) В-третьих, если канал вещания вообще отсутствует в данный момент, так как его никто не смотрит, значит, нужно инициировать вещание и создать новую группу Multicast.

Итак, повторим ещё раз:

IGMP Report — посылается клиентом при подключении, если клиент хочет получать трафик конкретной группы или в ответ на запрос маршрутизатора о членствеIGMP Query.

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

IGMP Group Sepcific Query — посылается маршрутизатором в ответ на сообщение Leave, чтобы узнать есть ли другие получатели в этой группе. В качестве адреса получателя указывается адрес мультикастовой группы.

IGMP Leave — посылается клиентом, когда тот хочет покинуть группу.

7 Пассивные оптические сети (PON) – переворот в широкополосном доступе

Оптоволокно на последней

миле: это надо PONять

Технология PON используется для реализации структур FTTH «волокно до жилища». Возможности технологии GPON удивляют в первую очередь тем, что доступ к ресурсам сети Интернет возможен на скорости до 1 Гб/с, что в двести раз выше, чем по медным линиям.

Сеть строится с помощью пассивных делителей оптической мощности (сплиттеров), не требующих питания и обслуживания. Особенностью технологии является 100% оптический канал от АТС до квартиры или офиса клиента, что позволяет повысить качество передачи сигнала (голоса, данных, видео) и в десятки раз увеличить скорость передачи данных.

Инфраструктура GPON отличается крайней неприхотливостью и безопасностью: не требует электропитания и может быть смонтирована в любом, даже неприспособленном помещении

Основные преимущества PON:

1 Простота и перспективность реализации распределительной инфраструктуры;

2 Отсутствие промежуточных активных узлов;

3 Быстрое развёртывание сети;

4 Простота сопряжения с любым внешним оборудованием;

5 Высокая гибкость при развитии и наращивании сети;

6 Независимое использование любых протоколов работы и технологий связи;

7 Повышенная надёжность;

8 Простота подключения новых абонентов и удобство обслуживания (подключение, отключение или выход из строя одного или нескольких абонентских узлов никак не сказывается на работе остальных);

9 Невысокая стоимость создания сети и т. д.

Дата добавления: 2016-02-09; просмотров: 779;

Источник

IGMP Proxy и Мультикаст: что это в роутере и как включить?

И так, чтобы раскрыть тему IGMP Proxy, PIM и мультикаста полностью – давайте начнём с самого начала. Вы, наверное, уже знаете, как передаётся эфирное телевидение. То есть у нас есть телевизионная вышка, которая путём радиоволн передаёт закодированный сигнал. А клиент в свою очередь принимает этот сигнал с антенны и видит картинку на телевизоре. Аналогично все происходит и путём кабельного ТВ. Только разница в том, что в кабельном идёт сигнал непосредственно по проложенному проводу к каждому приёмнику.

Но общее все же есть – сигнал одновременно поступает к всем клиентам. Когда вы включите телевизор, то вы увидите сигнал, который отправляется всем. Но если вы включите, например тот же самый YouTube, то там все по-другому. Каждому пользователю предоставляется свой пакет трафика.

И вот мы подошли к вопросу – что же такое мультикаст? Это технология, которая объединяет два этих подхода передачи трафикав. На первом уровне, пакет отправляется только в одном экземпляре, но только тому клиенту, который сделал на него запрос. Приёмников на самом деле может быть несколько.

Самый яркий пример мультикаста — это использования IPTV. Не все провайдеры предоставляют данную возможность, но щас она набирает обороты и возможно, кто-то уже пользуется этой услугой. Представим, что у нас есть два пользователя: Вася и Петя, который подключены к одному провайдеру. Так вот сервер IPTV, отправляет сигналы не всем пользователям, а только тем, кто в данный момент подключен.

Но самое главное, что Вася и Петя будут получать сигнал и пакеты только того канала, который в данный момент включен. Например, Вася смотрит «Первый канал», а Петя «СТС». Сервер четко отправляет пакеты информации только по тому каналу, который активен. Ещё один пример — это онлайн конференция, которой часто пользуются крупные компании. Ведь нет смысла раскидываться трафиком и отправлять всем, можно просто от одного разливать информацию к каждому клиенту.

Реализация

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

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

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

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

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

Куда идёт пакет

Рассмотрим на примере. Вообще данная технология использует IP адреса 224.0.0.0-239.255.255.255 диапазона. Например, сервер отправляет один канал с адресом 224.2.2.4. Это канал «СТС». IGMP протокол, использующийся только в отрезке между клиентом и ближайшим маршрутизатором, который к нему подключен.

Как включить на роутере

В роутере данная функция чаще всего нужна для нормального просмотра IPTV. По умолчанию эта функция уже включена, но можно проверить. Теперь я покажу как включить эту функцию на примере модели TP-Link.

Заходим в «Сеть» – «IPTV» и включаем «IGMP Прокси». Также не забываем поставить галочку «IGMP Snooping» – функция, исключающая получение трафика от группы, к которой не принадлежит клиент. На новых прошивках данный пункт находится там же, только изначально надо нажать на вкладку «Дополнительные настройки». Обязательно нажмите на кнопку «Сохранить» в само конце.

Источник

Протокол IGMP proxy: описание, включение, настройка, устранение проблем

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

Как и для чего включают IGMP?

У пользователей, пожелавших воспользоваться преимуществами IPTV через свой домашний маршрутизатор, иногда возникают сложности с подключением к интерактивному телевидению.

Некоторые модемы несовместимы для работы с этой технологией, а на отдельных просто требуется включить через web-конфигуратор igmp. Интерактивное ТВ функционирует посредством широковещательной передачи данных.

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

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

Процедура включения

На современном оборудовании обычно, чтобы просматривать IPTV, ручное подключение этого протокола осуществлять нет необходимости.

Достаточно произвести апгрейт программного обеспечения и после этого функция активируется в автоматическом режиме. Главное, чтобы роутер поддерживал этот протокол.

Чтобы включить поддержку IPTV вручную, следует запустить web-конфигуратор роутера и осуществить небольшую настройку. Например, на приборах ASUS потребуется исполнить следующие действия:

Примечание: На старых моделях маршрутизаторов пункт под номером «4» выполнять не требуется, так как в них достаточно активировать графу «IGMP прокси» и все заработает.

Устранение сопутствующих проблем

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

Следует их временно отключить для диагностирования источника неполадок. Затем, к примеру, в файрволле разрешить активность протокола для просмотра интерактивного телевидения.

Если для просмотра интерактивного ТВ применяется приставка, то необходимо включить функцию «Мост».

В роутерах разных производителей она называется по-разному, например, в Asus «Choose WAN Bridge Port», а в TP Link «Network-Bridge». Лучше свериться с инструкцией конкретной модели аппарата.

Если трансляция сопровождается частыми перебоями (изображение зависает, звук затормаживается и т.п.), то это вызывается перегрузкой маршрутизатора.

Рекомендуется ограничить скорости скачивания для других клиентов сети или сократить число кабельных подключений, а также лимитировать количество соединений по Wi-Fi.

Источник

Приручаем 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 позволяет выработать эффективную и оптимальную конфигурацию мультикаст-трафика в вашей сети.

Источник

Оптимизация передачи multicast-трафика в локальной сети с помощью IGMP snooping

Всем привет! Сегодня хотел бы затронуть тему передачи multicast-трафика в локальной корпоративной сети, а именно работу технологии IGMP snooping на коммутаторах. Так получилось, что за последнюю неделю ко мне обратилось несколько человек с вопросами по этой технологии. И я решил подготовить небольшую статью с описанием данной технологии. Но в процессе подготовки, выяснилось, что краткостью здесь не отделаешься, так как есть о чём написать. Кому интересен вопрос работы IGMP snooping, добро пожаловать под кат.

Достаточно часто мы не особенно задумываемся над тем, как передаётся multicast-трафик в пределах нашего L2-домена корпоративной сети. Напомню, multicast-трафик (он же «многоадресный трафик») предназначен для передачи данных определённой группе устройств. По умолчанию коммутатор передаёт multicast-трафик как broadcast (широковещательный), т.е. на все порты без исключения. Это обусловлено тем, что в пакете multicast в качестве MAC-адреса получателя использует специально сформированный адрес, никому не принадлежащий в сети. Если multicast-трафика не много, это не создаёт больших проблем и чаще всего администратор не предпринимает никаких мер по оптимизации его передачи. Если же такого трафика много или хочется просто «причесать» сеть, встаёт задача ограничить его распространение. Тут на помощь приходят различные технологии оптимизации передачи multicast-трафика на канальном уровне (IGMP snooping, CGMP и пр.). Наиболее распространённой и мультивендорной является технология IGMP snooping. IGMP snooping на многих устройствах включён по умолчанию. Например, это справедливо для коммутаторов Cisco. Но как часто бывает, счастье из коробки получить удаётся далеко не во всех случаях. Включённый IGMP snooping не всегда даёт предполагаемый результат и multicast-трафик в ряде случаев почему-то продолжает литься из всех портов. Давайте попробуем со всем этим разобраться.

Начать стоит с аббревиатуры IGMP. Всем нам известно, что когда в сети появляется устройство, которое хочет получать определённый multicast-трафик, это устройство сообщает о своём желании по средствам протокола IGMP (Internet Group Management Protocol). На многих устройствах по умолчанию используется IGMP версии 2. Обмен сообщениями данного протокола в самом простом случае выглядит следующим образом:

Так как все сообщения IGMP проходят через коммутатор, он мог бы их анализировать, чтобы определить за какими портами находятся те или иные получатели multicast-трафика. И далее на основании этой информации передавать трафик только туда, куда это необходимо. Собственно, именно этим и занимается технология IGMP snooping.

Реализация IGMP snooping у разных производителей сетевого оборудования в каких-то нюансах может отличается. Но в целом схема работы похожа. Предлагаю в общих чертах рассмотреть её работу на примере коммутаторов Cisco. Далее мы посмотрим на весь процесс более детально:

Далее коммутатор отправляет в сторону маршрутизатора IGMP Report, содержащий такую же информацию, как была получена от устройства.

Источник и получатель потокового multicast-трафика будет реализован через VLC media player (далее VLC проигрыватель).

IGMP snooping отключён, источник multicast-трафика находится в другой сети

Начнём с того, что рассмотрим передачу multicast-трафика без использования технологии IGMP snooping. Для начала отключим IGMP snooping. Как мы помним, на оборудовании Cisco он включён по умолчанию:

На роутере включаем маршрутизацию multicast-трафика и запускаем протокол маршрутизации multicast-трафика PIM (Protocol Independent Multicast) в режиме dense-mode. Нам не принципиален режим. Главное, чтобы маршрутизатор запустил IGMP на нужном нам интерфейсе и обеспечил передачу через себя multicast-трафика.

На источнике включаем VLC проигрыватель в режиме передачи потокового трафика. Это и будет наш источник multicast-трафика. В качестве адреса группы будем использовать 230.255.0.1. Передавать по сети будем только аудио. В качестве передаваемой композиции выбираем Adele Rolling in the Deep. Момент важный, так как именно она лучше всего передаётся по сети (факт проверен).

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

Я установил VLC проигрыватель, настроил передачу потокового аудио и… ничего не увидел в дампе Wireshark на внешнем интерфейсе данного компьютера.

Заглянув в таблицу маршрутизации, я увидел два маршрута в сеть 224.0.0.0/4 с абсолютно одинаковой метрикой 276. Причем первым в списке шёл маршрут через некий интерфейс с адресом 169.254.55.11. И только вторым шёл маршрут через нормальный интерфейс данного компьютера (172.17.16.11).

В связи с этим все multicast-пакеты заворачивались на непонятный интерфейс. Заглянув в сетевые подключения, я обнаружил активированный интерфейс Cisco Systems VPN Adapter. Данный интерфейс появляется в системе, когда на компьютер устанавливается Cisco VPN client. Это достаточно старое решение для подключения по VPN и, видимо, его просто забыли удалить.

Отключение данного интерфейса решило проблему.

Далее на клиенте включаем VLC проигрыватель в режиме получения потокового аудио для группы 230.255.0.1.

Когда я перешёл к настройке получателя потокового аудио, у меня сходу не заработало. Тут я нисколечко не удивился, а сразу полез в таблицу маршрутизации. На этом компьютере симптомы были идентичные: multicast-пакеты не появлялись на проводном интерфейсе.

И опять я обнаружил два маршрута в сеть 224.0.0.0/4 с абсолютно одинаковой метрикой 306. Но теперь первым был стандартный маршрут loopback интерфейса. Обычно метрика маршрута для этого интерфейса больше, метрики через другие интересы. По какой-то причине в моём случае они были равны.

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

После того, как я установил галочку «Автоматическое изучение метрики», multicast-пакеты стали нормально уходить с данного компьютера.

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

Сразу видим, как пошёл multicast-трафик. В нашем случае это пакеты потокового вещания, на транспортном уровне использующее протокол UDP.

По дампу видно, что получатель запросил трафик (отправил сообщение IGMP Report) и маршрутизатор сразу же начал транслировать в сеть нужный multicast-трафик. Сообщений IGMP Report целых два. Видимо, второе VLC проигрыватель отправляет для верности. Одного сообщения вполне было бы достаточно.

Проверяем таблицу маршрутизации multicast-трафика на маршрутизаторе. В ней появились записи, свидетельствующие о том, откуда и куда передаётся трафик:

Видим, что источником multicast-трафика является хост 172.17.16.11. При этом получатели находятся за интерфейсом GigabitEthernet0/0/1.115. Маршрутизатор запоминает только, куда слать трафик. Базу самих получателей он не ведёт (такая возможность есть в IGMPv3).

Давайте посмотрим на дамп трафика на клиенте, отфильтрованный по сообщениям IGMP:

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

Дамп трафика с компьютера в том же сегменте сети, но не участвующего в получении потокового трафика:

Точно также будут обстоять дела со всеми IGMP сообщениями. Они будут рассылаться на все порты без исключения. Что является абсолютно логичным, так как во всех этих сообщениях в качестве адреса получателя используется multicast-адрес.

IGMP snooping включён, источник multicast-трафика находится в другой сети

Теперь перейдём к рассмотрению ситуации, когда на коммутаторе включен IGMP snooping. Запускаем IGMP snooping на Cisco 2960x:

Для начала проверяем, удалось ли коммутатору обнаружить маршрутизатор. Как мы помним, это первый пункт в списке задач IGMP snooping:

Видим, что за портом Gi1/0/19 спрятался наш маршрутизатор. Как мы ранее обсуждали, коммутатор подсматривает за наличием в сети пакетов, свидетельствующих о присутствии маршрутизатора. В случае 2960x коммутатор ждёт пакеты IGMP General Query, PIM или DVMRP.

Коммутатор увидел сообщение PIMV2 Hello от маршрутизатора на порту Gi1/0/19 и добавил себе об этом информацию.

Снова запускаем нашу трансляцию потокового аудио и смотрим, что мы имеем на маршрутизаторе:

Появился источник трафика — 172.17.16.11. Получателей пока нет, о чём свидетельствует строка: Outgoing interface list: Null.

Запускаем клиент VLC, нажимаем кнопку «Воспроизведение» и наслаждаемся музыкой. Параллельно смотрим Wireshark, где видим, как идут multicast-пакеты потокового вещания:

Теперь самое интересное. Анализируем сообщения IGMP на стыке получатель-коммутатор и коммутатор-маршрутизатор.

Пройдём по основным шагам:

1. После нажатия кнопки «Воспроизведение» в проигрывателе VLC, наш компьютер запрашивает получение multicast-трафика для группы 230.255.0.1, отправив сообщение IGMP Report.

Прим. Пакеты на получателе

Коммутатор, когда получил сообщение IGMP Report, заносит себе информацию, о том, что за его портом (в нашем случае – это порт GE0/0/15) есть получатель трафика для группы с MAC-адресом 01:00:5e:7f:00:01.

Замечание. Найти запись о данном MAC-адресе на коммутаторе не удастся. Он нигде не фигурирует, в том числе в стандартном выводе «show mac address-table».

2. IGMP Report попадает на маршрутизатор. Если мы заглянем в само сообщение, то увидим, что это оригинальное сообщение от нашего ПК. Коммутатор его просто переслал на порт, куда подключен маршрутизатор:

Прим. Пакеты на маршрутизаторе. Подчёркнутый MAC адрес принадлежит ПК

Если бы на коммутаторе уже был клиент, который получал трафик для группы 230.255.0.1, коммутатор бы просто начал трансляцию трафика через наш порт (GE0/0/15) и больше ничего не предпринимал бы. Это логично, так как у коммутатора уже был бы нужный трафик, который следовало просто завернуть на ещё один порт. Но в нашем примере, данный клиент первый.

3. Маршрутизатор начинает трансляцию потокового трафика в локальную сеть.

Прим. Пакеты на маршрутизаторе

4. Коммутатор в свою очередь передаёт трафик на порт GE0/0/15, куда подключен наш ПК.

Прим. Пакеты на получателе

5. Компьютер отправляет повторный запрос на получение multicast-трафика (специфика реализации поддержки IGMP на VLC проигрывателе).

Прим. Пакеты на получателе

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

6. Периодически маршрутизатор рассылает сообщения IGMP General Query.

7. Коммутатор транслирует их без изменений на все свои порты.

Прим. Пакеты на получателе. Подчёркнутый MAC адрес принадлежит маршрутизатору

8. Компьютер откликается на данное сообщение, отправляя в обратную сторону IGMP Report для группы 230.255.0.1.

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

Прим. Пакеты на маршрутизаторе. Подчёркнутый MAC адрес принадлежит получателю

Коммутатор, получив первое сообщение IGMP Report пересылает его только в сторону маршрутизатора. Другим получателям данное сообщение не передаётся, в отличии от обычной схемы работы без IGMP snooping. Т.е. механизм Report Suppression нарушается. Таким образом каждый получатель вынужден будет отправить своё сообщение IGMP Report в ответ на IGMP General Query. Получив такие сообщения, коммутатор актуализирует свою базу соответствия получателей multicast-трафика и внутренних портов.

10. Наживаем кнопку «Остановить» в проигрывателе VLC. Компьютер отправляет сообщение IGMP Leave, о том, что он больше не хочет получать multicast-трафик для группы 230.255.0.1.

Прим. Пакеты на получателе

11. На компьютер приходит сообщение IGMP Group-Specific Query для группы 230.255.0.1. Если мы его развернём, мы увидим, что данное сообщение отправил коммутатор:

Прим. Пакеты на получателе. Подчёркнутый MAC адрес принадлежит коммутатору. При этом IP-адрес отправителя коммутатор использовал 172.17.15.1 (это адрес маршрутизатора)

Т.е. коммутатор, получив сообщение IGMP Leave, выполняет проверку, нет ли других устройств за данным портом, желающих получать multicast-трафика для группы 230.255.0.1.

В сторону маршрутизатора коммутатор ничего не отправляет. Пока коммутатор никак не тревожит маршрутизатор, так как он ещё не уверен, что нужно что-то делать с multicast-трафиком.

12. Ровно через одну секунду коммутатор отправляет повторное сообщение IGMP Group-Specific Query.

13. И ещё через одну секунду, не получив в ответ ни одного IGMP Report, прекращает передавать multicast-трафик на данный порт.

Прим. Пакеты на получателе. Трансляция прекратилась в 13:32:58:58

14. После того, как коммутатор понял, что за портом, где было принято сообщение IGMP Leave, больше нет получателей, он проверяет, а есть ли у него получатели за другими портами. Для этого он смотрит у себя в таблице MAC-адресов наличие записей для MAC-адреса 01:00:5e:7f:00:01 (как мы помним, это MAC-адрес группы 230.255.0.1). Если бы к данному коммутатору были подключены другие получатели, коммутатор на этом бы остановился и продолжил передавать multicast-трафик. Но в нашем случае, других получателей нет. Поэтому он отправляет маршрутизатору сообщение IGMP Leave.

Прим. Пакеты на маршрутизаторе. Подчёркнутый MAC адрес принадлежит коммутатору

15. Получив сообщение IGMP Leave, маршрутизатор, начинает проверку наличия других получателей трафика. Он же не знает, что коммутатор уже сам всё проверил. Маршрутизатор отправляет сообщение IGMP Group-Specific Query для группы 230.255.0.1.

16. Это сообщение коммутатор транслирует на все свои порты. В том числе на порт, куда подключён наш компьютер. Как видно из дампа теперь данное сообщение отправлено маршрутизатором:

Прим. Пакеты на получателе. Подчёркнутый MAC адрес принадлежит маршрутизатору

17. Через одну секунду после отправки первого сообщения маршрутизатор отправляет повторное сообщение IGMP Group-Specific Query.

18. И ещё через одну секунду, не получив в ответ ни одного IGMP Report (что ожидаемо, так как мы уже знаем, что коммутатору до этого никто не откликнулся), маршрутизатор прекращает передавать потоковый трафик в данный сегмент локальной сети.

Прим. Пакеты на маршрутизаторе. Трансляция прекратилась в 13:33:00:65

19. Маршрутизатор продолжает раз в минуту рассылать сообщение IGMP General Query.

20. Коммутатор в свою очередь транслирует его на все свои порты.

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

Дамп на получателе (получатель-коммутатор):

Дамп на маршрутизаторе (коммутатор-маршрутизатор):

Резюмируя, можно сказать следующее. Коммутатор перехватывает все сообщения IGMP от клиентов. Анализирует их. И в зависимости от ситуации пересылает эти сообщения на маршрутизатор или же удаляет. Так же коммутатор сам участвует в процессе создания IGMP сообщений. Когда последний клиент решает прекратить получать multicast-трафик, мы имеем две проверки наличия получателей. Первую выполняет коммутатор, а вторую – маршрутизатор. Во всей этой схеме маршрутизатор ведёт себя абсолютно также, как в случае, когда у нас на коммутаторе нет IGMP snooping. Т.е. маршрутизатор никак не догадывается о наличии коммутатора с включенной технологией IGMP snooping.

Давайте ещё посмотрим на дамп трафика компьютера, который не участвует в получении потокового трафика, но находится в той же локальной сети.

Прим. Подчёркнутый MAC адрес принадлежит маршрутизатору

Из дампа видно, что данный компьютер за всё время получил только два вида сообщений и ни одного multicast-пакета потокового вещания:

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

В-третьих, существенно уменьшает количество IGMP сообщений, которые попадают на все порты коммутатора, не вовлечённые в передачу multicast-трафика. Как мы помним, в случае отсутствия IGMP snooping все пакеты IGMP без исключения рассылаются на все порты.

Осталось посмотреть, что мы увидим на самом коммутаторе:

Мы видим, что получатели multicast-трафика для группы 230.255.0.1 находятся за портами Gi1/0/14, Gi1/0/15 и Gi1/0/19. За портом Gi1/0/19 находится сам маршрутизатор. Коммутатор автоматически добавил порт с маршрутизатором. Для получения более детальной информации на коммутаторе можно запустить отладчик debug ip igmp snooping.

IGMP snooping включён, источник multicast-трафика находится в той же сети

И так, когда источник находится где-то в другом месте нашей сети, всё прекрасно работает. Но давайте теперь перенесём наш источник multicast-трафика в тот же сегмент сети, где находятся получатели. Ситуация вполне себе житейская. Например, мы имеем систему приёма телевизионных каналов со спутника и несколько STB-приставок. Или же используем VLC проигрыватель или, например, камеры-видео наблюдения, передающие данные сразу нескольким потребителям, находящимся в том же сегменте сети. Ещё один кейс – передача multicast-трафика между контроллером беспроводной сети и точками доступа. Как в этой ситуации отработает IGMP snooping?

Для чистоты эксперимента на маршрутизаторе отключаем PIM, так как теперь нам не нужно больше маршрутизировать multicast-трафик.

Рассматривать вариант с отключённым IGMP snooping смысла нет: весь трафик будет просто передаваться как широковещательный. Поэтому проверяем, что IGMP snooping включён, и запускаем потоковую трансляцию на нашем импровизированном сервере. На клиенте пока VLC проигрыватель не запускаем (т.е. клиент никаких IGMP сообщений не отправляет).

Видим, что на наш компьютер, выполняющий роль клиента, стал сразу же сыпаться multicast-трафик:

Странно, ведь IGMP snooping включен. Посмотрим, как изменится ситуация, если на клиенте запустить VLC проигрыватель и подключиться к группе 230.255.0.1 (именно её мы продолжаем использовать для трансляции нашего потокового аудио). Нажимаем кнопку «Воспроизведение», видим, как наш компьютер отправил сообщение IGMP Report, начинаем слышать музыку. Понятное дело, что multicast-трафик на компьютер приходил всё время. Просто теперь клиент VLC стал его обрабатывать:

Теперь нужно убедиться, продолжает ли коммутатор рассылать multicast-трафик через все остальные порты. Или наконец заработал IGMP snooping и коммутатор стал слать трафик только туда, где есть клиенты. Но нет. Ничего не поменялось. На другом компьютере, который никак не участвует в нашем эксперименте, мы видим multicast-трафик (сам дамп приводить не буду, multicast-пакеты мы уже хорошо знаем в лицо). Стоит отметить, в дампе мы не обнаружим ни одного сообщения IGMP Report, которые ранее отправил наш клиент, и которые, по идее, должны были также рассылаться на все порты. Значит IGMP snooping на коммутаторе всё-таки частично работает: как минимум коммутатор перехватывает IGMP сообщения.

Впору заглянуть в консоль коммутатора. Информация о получателях для различных групп пуста:

Запустив отладчик (debug), видим:

Из этих сообщений единственно, что становится ясным, — коммутатор получил сообщение IGMPv3 Report, при этом версия некого Querier не советует IGMPv3 (о Querier поговорим немного позже). А что мы получим, если переключим IGMPv3 на нашем компьютере на IGMPv2 (данная процедура делается через реестр). Вдруг заведётся.

Проверяем. Поведение коммутатора осталось таким же, но вот сообщения в отладчике поменялись:

Из этих сообщений становится понятно, что коммутатор игнорирует информацию в сообщениях IGMP (и более того их удаляет), так как у него нет «mroute». И тут мы начинаем вспоминать, что первым пунктом программы IGMP snooping является определение, где находится маршрутизатор. И не важно собираемся ли мы маршрутизировать multicast-трафик или нет. В предыдущем разделе мы проверяли вывод команды «show ip igmp snooping mrouter». Там был указан номер порта, куда был подключен наш маршрутизатор, рассылающий сообщения IGMP General Query. Так вот, коммутатору с IGMP snooping обязательно нужно знать, где находится маршрутизатор multicast-трафика. Порт на коммутаторе, куда будет подключен такой маршрутизатор, как раз и получает название mrouter-порт (multicast router port). Без mrouter-порта IGMP snooping работать нормально не будет. А у нас такого порта нет, так как мы отключили на маршрутизаторе IGMP.

Включаем обратно IGMP на маршрутизаторе (для этого активируем на интерфейсе протокол PIM). Проверяем, что на коммутаторе появился mrouter-порт:

И снова запускаем наш источник потокового аудио. Пока VLC проигрыватель не включаем. Проверяем, рассылается ли трафик по всем портам коммутатора. Нет. Единственно, куда коммутатор теперь транслирует multicast-трафик – это через mrouter-порт. Делается он это всегда, так как маршрутизатор в нормальных условиях никогда не отсылает сообщений IGMP Report для групп, multicast-трафик которых он будет маршрутизировать. А значит коммутатор никак не сможет узнать, нужен или нет маршрутизатору тот или иной multicast-трафик.

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

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

Взглянем на дамп, полученный с маршрутизатора (часть UDP-пакетов было отфильтровано для большей наглядности):

Из дампа видно, следующее:

И так, мы поняли, что для корректной работы IGMP snooping на коммутаторе Cisco нам нужен маршрутизатор. Но можно ли получить на коммутаторе mrouter-порт без запуска протокола IGMP на маршрутизаторе? Да и вообще, можно ли обойтись совсем без маршрутизатора? Да, для это существует несколько способов. Первый вариант – статически прописать mrouter-порт. Смотреть он может, куда угодно. Главное, чтобы был. Безусловно, это не самый элегантный способ. Второй вариант – запустить на коммутаторе режим IGMP Querier. В этом режиме коммутатор вообразит себя multicast-маршрутизатором и начнёт рассылать и обрабатывать сообщения IGMP. При этом в качестве mrouter-порта будет указывать сам на себя:

Наш коммутатор будет отсылать в том числе от своего имени сообщения IGMP General Query. Это большой плюс. Остальные коммутаторы в сети, получив его, решат, что наш коммутатор – это multicast-маршрутизатор, а значит у них появятся свои mrouter-порты. Таким образом, IGMP snooping будет работать корректно во всей сети.

Замечание. Коммутатор весь multicast-трафик всегда передаёт через mrouter-порт. Если такого трафика будет много, он легко может забить транковые порты между коммутаторами, которые и окажутся в конечном итоге mrouter-портами. Поэтому к дизайну сети стоит подходить аккуратно, правильно выбирая расположение устройств, которые будут выполнять роль IGMP Querier.

Подытожу. Для того чтобы на коммутаторах Cisco корректно работал IGMP snooping, необходимо, чтобы на нём был хотя бы один mrouter-порт. Если на коммутаторе нет ни одного mrouter-порта:

IGMP snooping и 224.0.0.X

Когда я первый раз познакомился с IGMP snooping, первое о чём я подумал, можно ли ограничить с помощью данной технологии multicast-трафик, адресованный группам из диапазона 224.0.0.0-255 (224.0.0.0/24).

Как мы помним, данный диапазон адресов используется только для локальных коммуникаций внутри одного сегмента сети (широковещательного домена). Многие IP-адреса из него зарезервированы под различные служебные протоколы. Например, адрес 224.0.0.5 используется протоколом OSPF, а адрес 224.0.0.10 – протоколом EIGRP. Но так как эти адреса используются сугубо для локально взаимодействия никакие механизмы присоединения/отключения к этим группам не используются. Т.е. для этих адресов не будет сообщений IGMP Report. Поэтому все они полностью исключены из процесса IGMP snooping и коммутатор Cisco будет рассылать трафик для данных групп на все порты.

Бывают исключения в плане отсылки сообщений IGMP Report. Например, мой компьютер пытается присоединиться к группам 224.0.0.251 и 224.0.0.252. Это сервисы Multicast DNS и Link-Local Multicast Name Resolution, которые в своей работе используют механизм присоединения к группе.

Правда коммутатор Cisco считает такое поведение не достойным для сервисов, которые используют адреса, начинающееся с «224.0.0.». В связи с чем игнорирует сообщение IGMP Report.

В заключение

Мы разобрали общие аспекты работы IGMP snooping на примере оборудования Cisco. Причём рассмотренное поведение является поведением «по умолчанию». За кадром остались вопросы, связанные с тюнингом различных параметров данной технологии (например, тайм аутов между посылками сообщений IGMP Group-Specific Query), изменением схемы работы коммутатора в случае получения от клиентов сообщений IGMP Leave (например, мы знаем, что за портом точно нет других устройств), взаимодействием с протоколом STP (точнее, что делать, когда происходит перестройка топологии сети) и пр. Обычно данные элементы являются уже более вендоро зависимыми и хорошо описаны в документации.

Если мы посмотрим на коммутаторы других производителей, на многих из них мы также найдём технологию IGMP snooping. Конечно же, будут отличия в синтаксисе настройки, каких-то терминах (например, вместо mrouter-порта у многих используется просто router-порт), различных дополнениях и параметрах, которые можно подкрутить. Но по большей части общая схема работы IGMP snooping будет сходной с тем, что мы рассмотрели.

Источник