Протокол igmp что это
Приручаем multicast
Остановимся на анализе мультикаст-трафика через IGMP-протокол. Рассмотрим реализацию работы протокола IGMP, работы протокола PIM, отправки JOIN-запросов. После анализа проблемы была разработана оптимальная конфигурация сетевого оборудования, эффективная настройка QOS. Данная задача появилась после обнаружения проблемы в сети, такой как прерывание сигнала у клиентов, наличие фризов и прерывание звука.
IGMP — Internet Group Management Protocol — это сетевой протокол взаимодействия абонентов мультикаст-трафика и ближайшего к ним сетевого оборудования.
Пользователь имеет подписку на следующую группу IP-адресов: 224.0.0.0 до 239.255.255.255. PIM Protocol реализован в режиме Sparse mode. Это означает, что трафик льется только на ту ветку, в которой есть клиенты, желающие войти в мультикаст-группу. Они отправляют сообщения PIM Join. Если клиенты не отправляют Join, то трафик им отправляться не будет. PIM Sparse Mode включен на двух интерфейсах. В сторону источника мультикаст-трафика и в сторону клиента. На стороне клиента имеет цифровой ресивер или абонентское устройство —IPTV-приставка.
Для справки: dense mode предполагает, что мультикаст-трафик идет до абонента, и неважно, подписывается ли он на определенный канал. Мультикаст идет во все порты, потом, если он не нужен по месту назначения, то отправляется служебный пакет PIM Prune, и трафик перестает идти по этой ветке.
IGMP-протокол реализуется в сторону клиента. PIM-протокол устанавливает соседство с другими маршрутизаторами. Для этого применяются служебные сообщения PIM Hello.
В нашей сети применялась вторая версия протокола IGMP.
Абонентское устройство, которое решает получить multicast-трафик, отправляет запрос в сообщении IGMP Membership Report (так называемый репорт).
Если абонентское устройство больше не желает получать мультикаст-трафик, то оно отправляет сообщение IGMP Leave. Эта функция реализована коммутаторах уровня доступа. IGMP Membership Group-Specific Query — повторное сообщение коммутатором в сеть о том, есть ли клиентские устройства, которые будут запрашивать мультикаст-трафик. Если их нет, то передача трафика прекращается.
IGMP snooping реализуется на сетевом оборудовании, отдельного включения функции недостаточно, необходима дополнительная настройка. После включения данной функции управляемые коммутаторы могут анализировать трафик — мультикаст-поток.
Если коммутатор обнаруживает IGMP-пакет, то он вносит порт в список мультикаст-групп. Если от абонента идет сообщение IGMP Leave, то коммутатор удаляет порт из подписчиков групп.
IGMP snooping позволяет предотвращать мультикаст шторм. Если функция IGMP snooping не включена, то оборудование ретранслирует multicast-трафик во все порты, которые находятся в одном VLAN. Это не эффективно, а также способно вызвать проблемы на сетевых устройствах, вынужденных обрабатывать высокий поток данных. Это может загружать CPU-оборудования. IGMP snooping улучшает работу сети.
Однако для того, чтобы получить мультикаст-трафик, нужно реализовать эту функции на стороне клиента. К примеру, если клиент подключен через роутер, то необходимо позаботиться о включении этой функции на роутере.
Проверить корректность работы мультикаст-вещания можно путем анализа трафика через Wireshark, после включения телевидения через VLC-медиаплеер. В настройках VLC указываем, к примеру, udp:@239.255.0.A:5500. Для передачи потока используется UDP протокол, далее идет мультикаст адрес, далее порт.
При разработке QOS учитывалось, что «красить» трафик желательно ближе к ядру сети. Его необходимо красить ближе к Randezvous Point. (Ну это для нашего случая)
На коммутаторах уровня доступа у нас применялись следующие настройки:
Глубокий анализ проблемы, применение средств диагностики и понимание работы протокола IGMP позволяет выработать эффективную и оптимальную конфигурацию мультикаст-трафика в вашей сети.
Межсетевой протокол управления группами (IGMP)
Протокол IGMP (Internet Group Management Protocol) — это межсетевой протокол управления группами, который играет ключевую роль при организации мультикастовой передачи данных. Он входит в состав стандартного пакета TCP/IP и используется для осуществления многоадресной динамической рассылки. Учитывая широкое применение таких рассылок, для построения и обслуживания сетей важно иметь общее представление об IGMP протоколе: что это, и как он работает. Для этого важно не только осветить сам межсетевой протокол, но и дать понятие многоадресной рассылки и динамической многоадресной рассылке.
Что такое многоадресная рассылка?
Многоадресная рассылка, или Multicast — это способ передачи данных по сетям IPv4, который обеспечивает доставку единого потока информации одновременно тысячам частных или корпоративных пользователей. Работа в режиме Multicast предусматривает, что отправитель передает пакеты данных выбранной группе адресатов. При этом допускается подключение этих адресатов к разным подсетям.
Протокол IPv4 предполагает организацию отправки пакетов тремя способами:
В первом случае трафик передается только на конкретный компьютер. Этот способ позволяет пользователю выполнять значительную часть действий в интернете. Однако передача конкретному устройству потокового видео или других массивных объемов данных приведет к повышенной нагрузке на сеть. Поэтому для решения таких задач целесообразно использовать способы, позволяющие единожды передавать потоки, которые смогут получать многочисленные пользователи.
Широковещательная рассылка предполагает передачу данным от отправителя все подключенным к конкретной сети хостам. Сегодня этот метод используется редко, поскольку создает помехи для передачи других видов трафика.
Оптимальным решением становится многоадресная рассылка, при которой пакеты доставляются каждому подключенному к сети с определенным адресом хосту. Это дает значительную экономию полосы пропускания и снижает нагрузку на сеть.
При многоадресной рассылке сообщения отправляются на адрес группы Multicast, не имеющей географических и физических ограничений — то есть узлы могут быть расположены в разных странах и регионах. Главное, чтобы они были подписаны на рассылку (присоединены к группе). Для присоединения к группе Multicast и используется протокол IGMP.
Динамическая многоадресная рассылка
Чтобы обеспечить создание корректной конфигурации динамической многоадресной рассылки, необходим маршрутизатор или коммутатор, поддерживающий уровень 3. Коммутатор 3 уровня способен выполнять обработку многоадресных групп. Он использует межсетевой протокол IGMP для получения от клиентов сообщений присоединение (join) и исключения (leave). Эти сообщения используются для формирования многоадресных групп — добавления и удаления из них клиентов.
Кроме этого, в сетях, поддерживающих многоадресную рассылку, могут использоваться коммутаторов 2 уровня. Такие коммутаторы поддерживают IGMP Snooping. Благодаря этому обеспечивается возможность «считывать» IGMP трафик, проходящий между маршрутизаторами (запросчиками) и хостами. В результате коммутатор может контролировать присоединение портов к многоадресным группам и исключение их из многоадресных групп, обеспечивать динамическое перенаправление трафика только на те порты, которые входят в состав группы.
Запросчик IGMP регулярно отправляет сообщения IGMP Membership Query (запросы принадлежности IGMP) на адрес многоадресной рассылки 224.0.0.1. Эти запросы с определенным интервалом поступают всем поддерживающим многоадресную рассылку хостам. В результате коммутатор 3 уровня может отслеживать относящиеся к многоадресной группе порты.
Принципы работы IGMP
Функция протокола заключается в поддержании работы многоадресных групп. При отсутствии клиентов передача мультикастового трафика в соответствующий сегмент сети не требуется. Если появляется клиент, который хочет получать мультикастовый трафик, то он уведомляет об этом маршруты именно с помощью протокола IGMP.
Рассмотрим, как работает IGMP по порядку
При запуске клиента и задании на нем группы 224.2.2.4 в сеть направляется запрос IGMP Membership Report, которым узел сообщает о желании получать мультикастовый трафик. Запрос отправляется на адрес группы и указывается в пакете данных. Такие запросы маршрутизаторами никуда не пересылаются и действуют только в пределах своего сегмента.
После получения IGMP Membership Report маршрутизатор определяет наличие клиентов за соответствующим интерфейсом и заносит данные в таблицу.
Мультикастовый трафик передается клиенту. Чтобы не выполнять вещание впустую, маршрутизатор периодически проверяет наличие получателей. Такая проверка выполняется путем отправки запроса IGMP Query во все нисходящие интерфейсы. Запросы IGMP Query направляются на IP 224.0.0.1 с интервалом по умолчанию 60 секунд. После получения запроса IGMP Query, подключенный к группе хост отправляет в ответ сообщение IGMP Report, как и при подключении.
В случае если в ответ на запрос Query поступает хотя бы один Report, значит, в группе еще есть клиенты. Поэтому маршрутизатор продолжает вещание мультикастового трафика в соответствующий интерфейс. Если же интерфейс не отвечает на запросы 3 раза подряд, он удаляется из таблицы многоадресной маршрутизации и перестает получать трафик. Как правило, клиент отправляет Report по своей инициативе только при подключении, а в дальнейшем только отвечает на запросы маршрутизатора.
Принцип работы протокола динамической маршрутизации IGMP предусматривает использование механизма Report Suppression, в соответствии с которым при получении Query клиент не отправляет Report, а берет определенный интервал. Его продолжительность может составлять от 0 до времени Max Response Time, которое указывается в Query. Это необходимо для того, чтобы избежать перегрузки сети многочисленными ответами от клиентов. Кроме того, поскольку Report отправляется на адрес группы, его получают и все клиенты, находящиеся в пределах соответствующего сегмента. При получении Report от другого клиента группы узел не отправляет свой ответ. Благодаря этому Report обычно отправляет только один клиент, чего достаточно маршрутизатору для продолжения вещания на узел.
Когда клиент выходит из группы, например, при отключении пользователем плеера потокового видео, он направляет на адрес группы сообщение IGMP Leave. После получения Leave не может отключить конкретного клиента, поскольку не различает их. Он работает с нисходящим интерфейсом, в котором может находиться несколько клиентов. Поэтому после получения Leave маршрутизатор некоторое время продолжает вещание. При этом он отправляет на адрес группы, из которой поступил Leave, запрос IGMP Query.
Такой запрос называют Group Specific Query, и отвечают на него только клиенты, подключенные к данной группе. Запросы этого типа посылаются дважды. Один из них — обязательный, второй — контрольный. Если в ответ на Group Specific Query приходит Report, маршрутизатор продолжает вещание на группу. Если ответ не поступает, то он удаляет ее из таблицы маршрутизации и прекращает вещание.
При наличии в клиентском сегменте двух или нескольких маршрутизаторов применяется более сложная схема работы протокола IGMP. Это необходимо, чтобы исключить дублирование мультикастового трафика, поскольку при стандартной схеме каждый маршрутизатор будет получать от клиентов Report. Чтобы предотвратить такое дублирование, применяется механизм выбора опрашивателя Querier, в качестве которого назначается один из маршрутизаторов. Именно он реагирует на сообщения Report и Leave, а также транслирует мультикастовый трафик. Остальные маршрутизаторы в сегменте только слушают Report и находятся в резерве.
Сети для самых маленьких. Часть 9.2. Мультикаст. Протокол IGMP
Продолжим изучение мультикаста рассмотрением протокола IGMP (Internet Group Management Protocol), сетевого протокола взаимодействия клиентов мультикастового трафика и ближайшего к ним маршрутизатора.
Содержание серии статей про мультикаст
Протокол IGMP
Снова вернёмся к дампу. Видите вот этот верхний пакет, после которого полился мультикастовый поток?
Сообщение протокола IGMP при подключении
Это сообщение протокола IGMP, которое отправил клиент, когда мы на нём нажали Play. Именно так он сообщает о том, что хочет получать трафик для группы 224.2.2.4.
IGMP — Internet Group Management Protocol — это сетевой протокол взаимодействия клиентов мультикастового трафика и ближайшего к ним маршрутизатора.
В IPv6 используется MLD (Multicast Listener Discovery) вместо IGMP. Принцип работы у них абсолютно одинаковый, поэтому далее везде вы смело можете менять IGMP на MLD, а IP на IPv6.
Как же именно работает IGMP?
Пожалуй, начать нужно с того, что версий у протокола сейчас три: IGMPv1, IGMPv2, IGMPv3. Наиболее используемая — вторая, первая уже практически забыта, поэтому про неё говорить не будем, третья очень похожа на вторую.
Акцентируемся пока на второй, как на самой показательной, и рассмотрим все события от подключения клиента к группе до его выхода из неё. Клиент будет также запрашивать группу 224.2.2.4 через проигрыватель VLC.
Роль IGMP очень проста: если клиентов нет — передавать мультикастовый трафик в сегмент не надо. Если появился клиент, он уведомляет маршрутизаторы с помощью IGMP о том, что хочет получать трафик.
Для того, чтобы понять, как всё происходит, возьмём такую сеть:
Предположим, что маршрутизатор уже настроен на получение и обработку мультикастового трафика.
1. Как только мы запустили приложение на клиенте и задали группу 224.2.2.4, в сеть будет отправлен пакет IGMP Membership Report — узел «рапортует» о том, что хочет получать трафик этой группы.
Отправка IGMP Membership Report
В IGMPv2 Report отправляется на адрес желаемой группы, и параллельно он же указывается в самом пакете. Данные сообщения должны жить только в пределах своего сегмента и не пересылаться никуда маршрутизаторами, поэтому и TTL у них 1.
Часто в литературе вы можете встретить упоминание о IGMP Join. Не пугайтесь — это альтернативное название для IGMP Membership Report.
2. Маршрутизатор получает IGMP-Report и, понимая, что за данным интерфейсом теперь есть клиенты, заносит информацию в свои таблицы
Это вывод информации по IGMP. Первая группа запрошена клиентом. Третья и четвёртая — это служебные группы протокола SSDP, встроенного в Windows. Вторая — специальная группа, которая всегда присутствует на маршрутизаторах Cisco — она используется для протокола Auto-RP, который по умолчанию активирован на маршрутизаторах.
Интерфейс FE0/0 становится нисходящим для трафика группы 224.2.2.4 — в него нужно будет отправлять полученный трафик.
Наряду с обычной юникастовой таблицей маршрутизации существует ещё и мультикастовая:
О наличии клиентов говорит первая запись (*, 224.2.2.4). А запись (172.16.0.5, 224.2.2.4) означает, что маршрутизатор знает об источнике мультикастового потока для этой группы.
Из вывода видно, что трафик для группы 224.2.2.4 приходит через FE0/1, а передавать его надо на порт FE0/0.
Интерфейсы, в которые нужно передавать трафик, входят в список нисходящих интерфейсов — OIL — Outbound Interface List.
Более подробно вывод команды show ip mroute мы разберём позже.
Выше на дампе вы видите, что как только клиент отправил IGMP-Report, сразу после него полетели UDP — это видеопоток.
3. Клиент начал получать трафик. Теперь маршрутизатор должен иногда проверять, что получатели до сих пор у него есть, чтобы зазря не вещать, если вдруг клиентов не осталось. Для этого он периодически отправляет во все свои нисходящие интерфейсы запрос IGMP Query.
Получение запроса IGMP Query (Дамп отфильтрован по IGMP).
По умолчанию это происходит каждые 60 секунд. TTL таких пакетов тоже равен 1. Они отправляются на адрес 224.0.0.1 — все узлы в этом сегменте — без указания конкретной группы. Такие сообщений Query называются General Query — общие. Таким образом маршрутизатор спрашивает: «Ребят, а кто и что ещё хочет получать?».
Получив IGMP General Query, любой хост, который слушает любую группу, должен отправить IGMP Report, как он это делал при подключении. В Report, естественно, должен быть указан адрес интересующей его группы.
Ответ компьютера на IGMP General Query (Дамп отфильтрован по IGMP)
Если в ответ на Query на маршрутизатор пришёл хотя бы один Report для группы, значит есть ещё клиенты, он продолжает вещать в тот интерфейс, откуда пришёл этот Report, трафик этой самой группы.
Если на 3 подряд Query не было с интерфейса ответа для какой-то группы, маршрутизатор удаляет этот интерфейс из своей таблицы мультикастовой маршрутизации для данной группы — перестаёт туда посылать трафик.
По своей инициативе клиент обычно посылает Report только при подключении, потом — просто отвечает на Query от маршрутизатора.
Интересная деталь в поведении клиента: получив Query, он не торопится сразу же ответить Report’ом. Узел берёт тайм-аут длиной от 0 до Max Response Time, который указан в пришедшем Query:
При отладке или в дампе, кстати, можно видеть, что между получением различных Report может пройти несколько секунд.
Сделано это для того, чтобы сотни клиентов все скопом не наводнили сеть своими пакетам Report, получив General Query. Более того, только один клиент обычно отправляет Report.
Дело в том, что Report отсылается на адрес группы, а следовательно доходит и до всех клиентов. Получив Report от другого клиента для этой же группы, узел не будет отправлять свой. Логика простая: маршрутизатор и так уже получил этот самый Report и знает, что клиенты есть, больше ему не надо.
Этот механизм называется Report Suppression.
Далее в статье мы расскажем о том, почему этот механизм на деле очень редко реально работает.
4. Так продолжается веками, пока клиент не захочет выйти из группы (например, выключит плеер/телевизор). В этом случае он отправляет IGMP Leave на адрес группы.
Отправка клиентом IGMP Leave
Маршрутизатор получает его и по идее должен отключить. Но он ведь не может отключить одного конкретного клиента — маршрутизатор их не различает — у него просто есть нисходящий интерфейс. А за интерфейсом может быть несколько клиентов. То есть, если маршрутизатор удалит этот интерфейс из своего списка OIL (Outgoing Interface List) для этой группы, видео выключится у всех. Но и не удалять его совсем тоже нельзя — вдруг это был последний клиент — зачем тогда впустую вещать?
Если вы посмотрите в дамп, то увидите, что после получения Leave маршрутизатор ещё некоторое время продолжает слать поток. Дело в том, что маршрутизатор в ответ на Leave высылает IGMP Query на адрес группы, для которой этот Leave пришёл в тот интерфейс, откуда он пришёл. Такой пакет называется Group Specific Query. На него отвечают только те клиенты, которые подключены к данной конкретной группе.
Отправка маршрутизатором запроса Group Specific Query в ответ на IGMP Leave
Если маршрутизатор получил ответный Report для группы, он продолжает вещать в интерфейс, если не получил — удаляет по истечении таймера.
Всего после получения Leave отправляется два Group Specific Query — один обязательный, второй контрольный.
Два Group Specific Query — один обязательный, второй контрольный
Далее маршрутизатор останавливает поток.
Querier
Рассмотрим чуть более сложный случай:
В клиентский сегмент подключено два (или больше) маршрутизатора, которые могут вещать трафик. Если ничего не сделать, мультикастовый трафик будет дублироваться — оба маршрутизатора ведь будут получать Report от клиентов. Во избежание этого существует механизм выбора Querier — опрашивателя. Тот кто победит, будет посылать Query, мониторить Report и реагировать на Leave, ну и, соответственно, он будет отправлять и трафик в сегмент. Проигравший же будет только слушать Report и держать руку на пульсе.
Выборы происходят довольно просто и интуитивно понятно.
Рассмотрим ситуацию с момента включения маршрутизаторов R1 и R2.
Тот редкий случай, когда меряются, у кого меньше.
Выборы Querier очень важная процедура в мультикасте, но некоторые коварные производители, не придерживающиеся RFC, могут вставить крепкую палку в колёса. Я сейчас говорю о IGMP Query с адресом источника 0.0.0.0, которые могут генерироваться коммутатором. Такие сообщения не должны участвовать в выборе Querier, но надо быть готовыми ко всему. Вот пример весьма сложной долгоиграющей проблемы.
Ещё пара слов о других версиях IGMP
Версия 1 отличается по сути только тем, что в ней нет сообщения Leave. Если клиент не хочет больше получать трафик данной группы, он просто перестаёт посылать Report в ответ на Query. Когда не останется ни одного клиента, маршрутизатор по таймауту перестанет слать трафик.
Кроме того, не поддерживаются выборы Querier. За избежание дублирования трафика отвечает вышестоящий протокол, например, PIM, о котором мы будем говорить далее.
Версия 3 поддерживает всё то, что поддерживает IGMPv2, но есть и ряд изменений. Во-первых, Report отправляется уже не на адрес группы, а на мультикастовый служебный адрес 224.0.0.22. А адрес запрашиваемой группы указан только внутри пакета. Делается это для упрощения работы IGMP Snooping, о котором мы поговорим дальше.
Во-вторых, что более важно, IGMPv3 стал поддерживать SSM в чистом виде. Это так называемый Source Specific Multicast. В этом случае клиент может не просто запросить группу, но также указать список источников, от которых он хотел бы получать трафик или наоборот не хотел бы. В IGMPv2 клиент просто запрашивает и получает трафик группы, не заботясь об источнике.
Содержимое IGMP Membership Report в IGMPv3
Итак, IGMP предназначен для взаимодействия клиентов и маршрутизатора. Поэтому, возвращаясь к Примеру 2, где нет маршрутизатора, мы можем авторитетно заявить — IGMP там — не более, чем формальность. Маршрутизатора нет, и клиенту не у кого запрашивать мультикастовый поток. А заработает видео по той простой причине, что поток и так льётся от коммутатора — надо только подхватить его.
Напомним, что IGMP не работает для IPv6. Там существует протокол MLD.
Повторим ещё раз
1. Первым делом маршрутизатор отправил свой IGMP General Query после включения IGMP на его интерфейсе, чтобы узнать, есть ли получатели и заявить о своём желании быть Querier. На тот момент никого не было в этой группе.
2. Далее появился клиент, который захотел получать трафик группы 224.2.2.4 и он отправил свой IGMP Report. После этого пошёл трафик на него, но он отфильтрован из дампа.
3. Потом маршрутизатор решил зачем-то проверить — а нет ли ещё клиентов и отправил IGMP General Query ещё раз, на который клиент вынужден ответить (4).
5. Периодически (раз в минуту) маршрутизатор проверяет, что получатели по-прежнему есть, с помощью IGMP General Query, а узел подтверждает это с помощью IGMP Report.
6. Потом он передумал и отказался от группы, отправив IGMP Leave.
7. Маршрутизатор получил Leave и, желая убедиться, что больше никаких других получателей нет, посылает IGMP Group Specific Query… дважды. И по истечении таймера перестаёт передавать трафик сюда.
8. Однако передавать IGMP Query в сеть он по-прежнему продолжает. Например, на тот случай, если вы плеер не отключали, а просто где-то со связью проблемы. Потом связь восстанавливается, но клиент-то Report не посылает сам по себе. А вот на Query отвечает. Таким образом поток может восстановиться без участия человека.