что такое igmp прокси
Сети для самых маленьких. Часть 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 отвечает. Таким образом поток может восстановиться без участия человека.
Русские Блоги
Основы IGMP
Введение в IGMP
Как работает IGMPv1
Сообщение ICMPv1:
IGMPv1 включает два типа сообщений:
Рис.: Формат сообщения IGMPv1
Пример захвата пакета IGMPv1:
Рис.: Пример сообщения IGMPv1
Механизм работы IGMPv1:
Протокол IGMPv1 в основном основан на механизме запросов и ответов для полного управления группами многоадресной рассылки. Когда в сегменте сети имеется несколько маршрутизаторов многоадресной рассылки, поскольку все они могут получать сообщение с отчетом о членстве, отправленное хостом, достаточно выбрать один из маршрутизаторов многоадресной рассылки для отправки сообщения запроса. Маршрутизатор многоадресной рассылки сообщает Это запросчик IGMP (Querier).В IGMPv1 единственный сервер пересылки многоадресной информации выбирается протоколом многоадресной маршрутизации PIM.(Assert Winner или DR) Как запрашивающий IGMPv1, он отвечает за запрос членства в группе сетевого сегмента.
Рабочий механизм IGMPv1 можно разделить на три аспекта: общий механизм группового запроса и ответа, механизм присоединения нового члена и механизм выхода члена группы.
Общий механизм группового запроса и ответа:
Посредством общего группового запроса и ответа запросчик IGMP может узнать, какие группы многоадресной рассылки имеют участников в сегменте сети.
Рис.: Диаграмма запросов и ответов IGMPv1
Как показано на рисунке выше, общий процесс группового запроса и ответа выглядит следующим образом:
Инициатор запросов IGMP отправляет сообщение общего запроса с адресом назначения 224.0.0.1 (представляющим все хосты и маршрутизаторы в одном сегменте сети); член группы, который получает сообщение запроса, запускает таймер.
Изображение: сообщение общего запроса IGMPv1
Первый член группы, у которого истекает таймер, отправляет отчетное сообщение для группы.
Предполагая, что таймер Timer-G1 на HostA истекает первым, HostA отправляет отчетное сообщение с адресом назначения G1 в этот сегмент сети. HostB, который также хочет присоединиться к группе G1, получает это отчетное сообщение, поэтому он останавливает таймер Timer-G1 и больше не отправляет отчетные сообщения для G1. Таким образом, сообщение отчета подавляется, что может снизить трафик в сегменте сети.
Рис.: Пример захвата пакета отчета IGMPv1
После получения сообщения-отчета от HostA, запросчик IGMP знает, что в этом сегменте сети есть члены группы многоадресной рассылки G1, и оно создается протоколом многоадресной маршрутизации (, G1) Запись многоадресной пересылки, « «Представляет любой источник многоадресной рассылки. Как только данные группы многоадресной рассылки G1 в сети достигают маршрутизатора, они будут перенаправлены в этот сегмент сети.
Механизм присоединения нового члена группы:
Рис.: Схематическая диаграмма присоединения новых членов группы
Как показано на рисунке выше, процесс присоединения хоста HostC к группе многоадресной рассылки G2 выглядит следующим образом:
Механизм выхода члена группы:
IGMPv1 конкретно не определяет сообщения, покидающие группу. После того, как хост покинет группу многоадресной рассылки, он больше не будет отвечать на общие сообщения группового запроса.
Предположим, HostA хочет выйти из группы многоадресной рассылки G1.
Когда HostA получает сообщение с общим запросом, отправленное запросчиком IGMP, он больше не отправляет сообщения отчета для G1. Поскольку HostB, член группы G1, все еще существует в сегменте сети, HostB отправит сообщение-отчет для G1 запрашивающей IGMP, поэтому запрашивающая IGMP не заметит ухода HostA.
Предположим, HostC хочет покинуть группу многоадресной рассылки G2.
Как работает IGMPv2
Сообщение IGMPv2:
По сравнению с IGMPv1, IGMPv2 имеет следующие изменения:
Рис.: Формат сообщения IGMPv2
Тип: Тип пакета. Поле имеет следующие четыре значения:
Максимальное время отклика: максимальное время отклика.
После получения сообщения общего запроса, отправленного запросчиком IGMP, узел-член должен ответить в течение максимального времени ответа. Это поле действительно только в сообщениях запроса IGMP.
Адрес группы: адрес группы многоадресной рассылки.
Пример захвата пакета IGMPv2:
Рис.: Сообщение запроса IGMPv2
Механизм работы IGMPv2:
С точки зрения рабочего механизма, по сравнению с IGMPv1, IGMPv2 добавляет механизм выбора и выхода из группы запросов.
Механизм выбора Querier:
IGMPv2 использует независимый механизм выбора запрашивающего. Когда в общем сегменте сети имеется несколько многоадресных маршрутизаторов,Маршрутизатор с наименьшим IP-адресом становится запрашивающим.。
Рис.: Механизм выбора запрашивающего
Как показано на рисунке выше, в IGMPv2 процесс выбора запрашивающего осуществляется следующим образом:
Первоначально все маршрутизаторы многоадресной рассылки (RouterA и RouterB), работающие с IGMPv2, считают себя запрашивающими и отправляют общие сообщения запроса всем хостам и маршрутизаторам многоадресной рассылки в сегменте сети.
После того, как RouterA и RouterB получают сообщение с общим запросом, отправленное другой стороной, они сравнивают исходный IP-адрес сообщения со своим собственным адресом интерфейса. Для сравнения, многоадресный маршрутизатор с наименьшим IP-адресом станет запрашивающим, а другие многоадресные маршрутизаторы станут не запрашивающим (Non-Querier).
Рис.: Пример сообщения запроса V2
Рис.: Отчетное сообщение IGMPv2
После этого запросчик IGMP (RouterA) будет отправлять общие сообщения запроса на все хосты и другие многоадресные маршрутизаторы в сегменте сети, в то время как не запрашивающий (RouterB) больше не будет отправлять общие сообщения запроса.
Таймер (Таймер присутствия другого запрашивающего) запускается на не запрашивающем (RouterB). До истечения таймера, если получено сообщение запроса от запрашивающего, таймер сбрасывается; в противном случае исходный запросчик считается недействительным и инициируется новый процесс выбора запрашивающего.
Механизм выхода группы:
Рис.: Схема выхода из группы
Как показано на рисунке выше, в IGMPv2 процесс выхода HostA из группы многоадресной рассылки G1 выглядит следующим образом:
Когда запрашивающий получит сообщение о выходе, он отправит сообщение с запросом для группы G1. Интервал отправки и количество отправок можно настроить с помощью команд.По умолчанию отправка отправляется один раз в 1 секунду, всего дважды. В то же время запрашивающий запускает таймер членства в группе (Timer-Membership = интервал отправки x количество отправлений).
В этом сегменте сети есть и другие члены группы G1, и эти члены немедленно отправят отчетное сообщение для группы G1 после получения сообщения с запросом конкретной группы, отправленного запрашивающим. После получения отчетного сообщения для группы G1 запрашивающий продолжит поддерживать членство в группе.
Если в этом сегменте сети нет других членов группы G1, запрашивающий не будет получать сообщения отчета для группы G1. По истечении времени членства в таймере запрашивающий удалит запись группы IGMP, соответствующую (*, G1). Когда многоадресные данные группы G1 достигают запрашивающей стороны, запрашивающая сторона не пересылает их вниз по потоку.
Принцип работы IGMPv3:
Сообщение IGMPv3:
По сравнению с IGMPv2, сообщения IGMPv3 следующие:
Формат сообщения запроса IGMPv3:
Рис.: Формат сообщения запроса IGMPv3
Описание поля сообщения запроса IGMPv3:
| поле | Описание |
|---|---|
| Type | Тип пакета, значение 0x11. |
| Max Response Code | Максимальное время отклика. После получения сообщения общего запроса, отправленного запросчиком IGMP, узел-член должен ответить в течение максимального времени ответа. |
| Checksum | Контрольная сумма сообщений IGMP. |
| Group Address | Адрес группы многоадресной рассылки. В обычных сообщениях группового запроса это поле установлено в 0; в определенных сообщениях запроса группы и сообщениях запроса конкретной исходной группы это поле является запрашиваемым адресом группы многоадресной рассылки. |
| Resv | зарезервированный текст. При отправке сообщения это поле устанавливается в 0, при получении сообщения это поле не обрабатывается. |
| S | Когда этот бит равен 1, все остальные маршрутизаторы, которые получают это сообщение запроса, не запускают процесс обновления таймера, но это сообщение запроса не запрещает процесс выбора запрашивающего и процесс обработки маршрутизатора на стороне хоста. |
| QRV | Если поле не равно нулю, оно указывает на переменную устойчивости (переменную устойчивости) запрашивающего. Если это поле равно 0, это означает, что коэффициент устойчивости запрашивающего больше 7. Когда маршрутизатор получает сообщение запроса, если он обнаруживает, что это поле не равно 0, он корректирует свой собственный коэффициент устойчивости к значению этого поля; если он обнаруживает, что это поле равно 0, он не будет его обрабатывать. |
| QQIC | Интервал запроса IGMP Querier в секундах. Когда не запрашивающий получает сообщение с запросом, если он обнаруживает, что это поле не равно 0, он корректирует свой параметр интервала запроса на значение этого поля; если он обнаруживает, что это поле равно 0, он не будет его обрабатывать. |
| Number of Sources | Количество источников многоадресной рассылки, содержащихся в сообщении. Для сообщений общего запроса группы и сообщений запроса конкретной группы это поле равно 0; для сообщений запроса конкретной исходной группы это поле не равно нулю. Размер этого параметра ограничен размером MTU сети. |
| Source Address | Количество адресов источников многоадресной рассылки ограничено значением поля Number of Sources. |
Формат сообщения отчета о членстве IGMPv3:
Рис.: Формат сообщения отчета о членстве IGMPv3
| поле | Описание |
|---|---|
| Type | Тип пакета, значение 0x22. |
| Reserved | зарезервированный текст. |
| Checksum | Контрольная сумма сообщений IGMP. |
| Number of Group Records | Количество групповых записей, содержащихся в сообщении. |
| Group Record | Групповые записи. |
Рис.: Формат поля Grounp Record
Объяснение поля:
Пример захвата пакета IGMPv3:
Рис.: Пример сообщения отчета IGMPv3
Рис.: Сообщение запроса IGMPv3
Механизм работы IGMPv3:
С точки зрения рабочего механизма, по сравнению с IGMPv2, IGMPv3 увеличивает возможность хоста выбирать источники многоадресной рассылки.
Присоединение к определенной группе:
Если IGMPv1 или IGMPv2 работает между Хостом и многоадресным маршрутизатором, Хост не может выбрать источник многоадресной рассылки, когда он присоединяется к группе многоадресной рассылки G, и будет получать данные от источников многоадресной рассылки S1 и S2 одновременно, независимо от того, нужны ли они ему. Если используется IGMPv3, узлы-участники могут выбрать получение только многоадресных данных S1.
Конкретный групповой запрос:
При получении отчета (такого как CHANGE_TO_INCLUDE_MODE, CHANGE_TO_EXCLUDE_MODE), который изменяет соответствие между группой многоадресной рассылки и исходным списком, отправленным членом группы, запросчик IGMP отправит конкретное сообщение запроса исходной группы. Если члены группы хотят получать данные многоадресной рассылки из любого из этих источников, они ответят сообщением с отчетом. Запросчик IGMP обновляет список источников, соответствующий группе, в соответствии с обратной связью отчета о членстве в группе.
Сравнение версий IGMP
IGMPv1 определяет базовый процесс запроса и отчета о членах группы. IGMPv2 добавляет механизм выбора запрашивающего и выхода из группы. Основная функция, добавленная в IGMPv3, заключается в том, что участники могут указывать получение или запрет на получение определенных источников многоадресной рассылки. Сообщение. В процессе эволюции эти три версии имеют прямую совместимость с обработкой протокольных сообщений.Поэтому, хотя форматы протокольных сообщений каждой версии различаются, маршрутизаторы, использующие более высокие версии IGMP, могут распознавать сообщения IGMP более низких версий.
Все версии IGMP поддерживают модель ASM (Any-Source Multicast). IGMPv3 можно напрямую применять к модели SSM (многоадресная рассылка с учетом источника), в то время как IGMPv1 и IGMPv2 требуют поддержки технологии сопоставления IGMP SSM для применения к модели SSM.
| проект | IGMPv1 | IGMPv2 | IGMPv3 |
|---|---|---|---|
| Метод выбора запросчика | Положитесь на выбор протокола многоадресной маршрутизации PIM | Конкурс на выборах между многоадресными маршрутизаторами в одном сегменте сети | Соревнование по выборам между многоадресными маршрутизаторами в одном сегменте сети |
| Сообщение общего запроса | ожидание | ожидание | ожидание |
| Сообщение об отчете участника | ожидание | ожидание | ожидание |
| Сообщение с запросом конкретной группы | не поддерживается | ожидание | ожидание |
| Оставить сообщение участника | не поддерживается | ожидание | Специальное сообщение об уходе участника не определено, а сообщение об уходе участника передается с помощью определенного типа сообщения-отчета. |
| Сообщение запроса конкретной исходной группы | не поддерживается | не поддерживается | ожидание |
| Укажите источник многоадресной рассылки | не поддерживается | не поддерживается | ожидание |
| Идентифицируемая версия протокола сообщений | IGMPv1 | IGMPv1、IGMPv2 | IGMPv1、IGMPv2、IGMPv3 |
| Модель ASM | ожидание | ожидание | ожидание |
| Модель SSM | Требуется техническая поддержка IGMP SSM Mapping | Требуется техническая поддержка IGMP SSM Mapping | ожидание |
IGMP SSM Mapping
SSM (многоадресная рассылка, зависящая от источника) называется многоадресной рассылкой от назначенного источника, которая требует, чтобы маршрутизаторы знали источник многоадресной рассылки, указанный при присоединении узла-члена к группе многоадресной рассылки. Если IGMPv3 работает на узлах-членах, адрес источника многоадресной рассылки можно напрямую указать в сообщении отчета IGMPv3. Однако в некоторых случаях узлы-участники могут запускать только IGMPv1 или IGMPv2. Чтобы они могли использовать службу SSM, маршрутизатору необходимо обеспечить отображение IGMP SSM.
IGMP Proxy
Прокси-сервер IGMP, также называемый прокси-сервером IGMP, обычно развертывается на устройстве уровня 3 между устройством доступа (RouterA) и узлами-участниками. Устройство прокси-сервера IGMP может собирать отчеты IGMP / оставлять сообщения от нижележащих узлов-членов и сообщать / оставлять После того, как сообщения агрегированы, подчиненные узлы-участники отправляются на устройство доступа унифицированным способом; с другой стороны, устройство прокси-сервера IGMP также может прокси-сервер IGMP-запросчика для отправки сообщений запроса на нижележащие узлы-члены, поддерживать членство в группе и выполнять многоадресную рассылку на основе членства в группе. Вперед. С точки зрения устройства доступа RouterA, RouterB является хостом; с точки зрения нисходящих узлов-участников RouterB является запросчиком IGMP.
Механизм работы IGMP Proxy:
Функции, реализуемые прокси-устройством IGMP, в основном делятся на два типа: поведение хоста и поведение маршрутизатора.
Поведение хозяина
Поведение хоста означает, что когда восходящий интерфейс прокси-устройства IGMP получает сообщение запроса, он отвечает на сообщение запроса в соответствии с текущим статусом таблицы многоадресной пересылки, или восходящий интерфейс активно отправляет отчет на устройство доступа при изменении таблицы многоадресной пересылки /Оставить сообщение. Рабочий механизм поведения хоста следующий:
После того как прокси-устройство IGMP получит отчетное сообщение определенной группы многоадресной рассылки, оно будет искать группу многоадресной рассылки в таблице многоадресной пересылки:
После того, как прокси-устройство IGMP получит сообщение о выходе определенной группы многоадресной рассылки G, оно отправит конкретное сообщение группового запроса на интерфейс, который получил сообщение о выходе, чтобы проверить, есть ли другие члены группы многоадресной рассылки G под интерфейсом:
Поведение роутера
Поведение маршрутизатора означает, что нисходящий интерфейс прокси-устройства IGMP генерирует записи многоадресной пересылки на основе информации о членских узлах, присоединяющихся к группе многоадресной рассылки или покидающих ее, принимает данные многоадресной рассылки, отправленные устройством доступа, и отправляет информацию о пересылке на основе информации об исходящем интерфейсе записи многоадресной пересылки. Конкретный интерфейс пересылает данные многоадресной рассылки.
Механизм резервного копирования IGMP Proxy:
Чтобы повысить надежность соединения, после настройки функции прокси-сервера IGMP на восходящем интерфейсе прокси-устройства IGMP вы можете настроить прокси-устройство IGMP на прокси-устройстве IGMP.
Интерфейс резервного копирования прокси в качестве резервного интерфейса восходящего интерфейса, как показано на рисунке ниже. Таким образом, когда канал, на котором расположен восходящий интерфейс, выходит из строя, резервный канал автоматически берет на себя прокси-службу IGMP, так что служба может быть автоматически восстановлена.
Рис.: Механизм резервного копирования прокси-сервера IGMP
Сам IGMP Proxy не имеет механизма обнаружения. В случае сбоя многоадресного канала он не может гарантировать своевременное переключение основного и резервного каналов, что может привести к длительному прерыванию службы многоадресной рассылки. Эту проблему можно решить с помощью связи между IGMP Proxy и NQA. Связь между IGMP Proxy и тестовыми примерами NQA заключается в использовании тестовых примеров NQA для определения статуса сквозного канала и переключения между основным и резервным каналами на основе результатов тестового примера NQA, тем самым избегая длительных прерываний связи.
Часто используемые командные строки IGMP
Примечания к исследованию IGMP
Роль вопрошающего:
Запросчик может пересылать многоадресный трафик, что позволяет избежать дублирования многоадресного трафика. Чтобы обеспечить надежность многоадресной рассылки, маршрутизаторы, не выполняющие запросы, также будут создавать и поддерживать группы многоадресной рассылки. В то же время, не запрашивающие запросы должны отслеживать существование запрашивающей стороны. Если запрашивающая сторона не отправляет запрос в таймере удержания, не запрашивающая сторона будет Считается, что дознаватель потерпел неудачу, и расследование необходимо переизбрать. Инициатор запросов будет пересылать многоадресный трафик и в то же время отправлять запросы с каждым интервалом (60 секунд).