Включить igmp что это: что это в роутере и как включить?

Содержание

что это в роутере и как включить?

И так, чтобы раскрыть тему 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 протокол, использующийся только в отрезке между клиентом и ближайшим маршрутизатором, который к нему подключен.

Так вот, пользовательская программа отправляет запрос на просмотр канала 224.2.2.4 ближайшему маршрутизатору.
Если в маршрутизаторе уже есть поток и через него идёт дерево канала, который запросил клиент – то пакеты сразу же отправляются пользователю, и он видит изображение.
Как только клиент выключит программу на маршрутизатор отправляется сигнал, о выходе из группы и сигнал более туда не идёт.
Но также маршрутизатор постоянно отправляет сигнал на ближайших включенных клиентов, чтобы удостовериться, что они ещё принимают трафик. Происходит это каждые 60 секунд. Клиент, который получил такой запрос, обязан отправить ответ или его отключат. Все это происходит в автономном режиме.

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

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

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

что это в роутере и как его включить

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

Немного подробнее о проблемах, из-за которых вы могли заинтересоваться IGMP snooping:

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

И при этом у вас значительно снижается скорость на всех устройствах, которые подключены к роутеру. Например, вы смотрите IPTV на телевизоре, но у вас начинает «тупить» ПК или хуже работать интернет на телефоне. Возможна и другая проблема – IPTV, сетевые игры или службы, перечисленные выше, вовсе не запускаются и не работают. Во всех этих случаях решению поможет настройка IGMP snooping.

Что такое IGMP и зачем он нужен

Когда данные передаются по сети – по глобальному интернету, или от провайдера, или между вашими устройствами – это происходит по чётким правилам: протоколам. Каждый протокол определяет, как распознавать нули и единицы, как собирать их в пакеты данных, как проверять их «правильность» при получении и собирать в картинку на экране. Всего существует семь уровней – от электрических сигналов до вашего браузера.

Internet Group Management Protocol, по первым буквам которого и образована аббревиатура – один из таких протоколов на канальном уровне. Вы бы не знали о его существовании, если бы не возникали описанные выше «неполадки». Как видно из названия, это протокол для управления группами вещания. То есть когда к вам на роутер от провайдера приходит сигнал интернет-телевидения IPTV, он начинает транслировать его на все устройства. Это удобно, смотреть одну и ту же передачу на смартфоне и телевизоре. Но при этом любой другой девайс – к примеру, ваш компьютер – «не спрашивают», нужен ли ему сигнал. Поэтому он его всё равно получает, что снижает скорость интернета и расходует его ресурсы.

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

Виды IGMP snooping

Поддержка роутера этого протокола уже означает, что у вас не будет проблем с получением сигнала от IPTV и от других служб. Но если маршрутизатор или модем более старый, то он может не принимать широковещательную передачу данных, либо просто ему не хватит мощности и он будет «подвисать». Но когда всё в порядке, то IGMP snooping может различаться по видам:

Пассивный. Это базовая поддержка технологии, общее отслеживание и передача широковещательных данных. Всё работает, нагрузка на роутер минимальна. Однако на сеть и на девайсы в ней нагрузка увеличивается.
Активный. Такой протокол максимально оптимизирует сеть. Он отсеивает «лишние» запросы к маршрутизатору, которые ему не нужны, освобождая ресурс передачи данных. Однако он увеличивает нагрузку на процессор и на память девайса. Устройства среднего и высокого ценового сегментов справляются с этим без проблем. Для девайсов подешевле это зависит от объёма данных.

Как настроить функцию в роутере

Разберу IGMP в роутере, что это за настройка – на примере IPTV. Обычно всё включается автоматически. Но если вы читаете эту статью, то что-то явно пошло не так. Поэтому проделайте такие шаги:

Зайдите в веб-интерфейс маршрутизатора: введите в адресной строке браузера 192.168.1.1 или 192.168.0.1 или адрес, который указан на наклейке снизу.
Введите логин и пароль – обычно это логин «admin» и пароль «admin», если вы их не сменили вручную. Или проверьте ту же наклейку на маршрутизаторе.

Перейдите к пункту «Сеть», «Настройки сети» или подобному. В ASUS она называется «Локальная сеть». Вам нужно найти вкладку «IPTV».

Опция «прокси» включает широковещание, фактически запускает функцию IPTV. Вот что это, IGMP proxy в роутере. Включите его.
Не на всех моделях есть пункт «IGMP Snooping», но если он присутствует, то включите и его. Snooping улучшит работу всех девайсов.
Нажмите «Применить».
Всё готово.

Возможные проблемы

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

Если для IPTV используется отдельное оборудование-ресивер (зачем нужна ТВ приставка, это тема отдельного разговора), то в настройках маршрутизатора может потребоваться разрешить опцию «Мост». Она может называться «Choose WAN Bridge Port» или «Network-Bridge» – это зависит от девайса.

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

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

Сети для самых маленьких. Часть девятая. Мультикаст / Хабр

Наш умозрительный провайдер linkmeup взрослеет и обрастает по-тихоньку всеми услугами обычных операторов связи. Теперь мы доросли до IPTV.
Отсюда вытекает необходимость настройки мультикастовой маршрутизации и в первую очередь понимание того, что вообще такое мультикаст.
Это первое отклонение от привычных нам принципов работы IP-сетей. Всё-таки парадигма многоадресной рассылки в корне отличается от тёплого лампового юникаста.
Можно даже сказать, это в некоторой степени бросает вызов гибкости вашего разума в понимании новых подходов.

В этой статье сосредоточимся на следующем:

Традиционный видеоурок:

На заре моего становления, как инженера, тема мультикаста меня неимоверно пугала, и я связываю это с психотравмой моего первого опыта с ним.

«Так, Марат, срочно, до полудня нужно пробросить видеопоток до нашего нового здания в центре города — провайдер отдаст его нам тут на втором этаже» — услышал я одним чудесным утром. Всё, что я тогда знал о мультикасте, так это то, что отправитель один, получателей много, ну и, кажется, протокол IGMP там как-то задействован.
В итоге до полудня мы пытались всё это дело запустить — я пробросил самый обычный VLAN от точки входа до точки выхода. Но сигнал был нестабильным — картинка замерзала, разваливалась, прерывалась. Я в панике пытался разобраться, что вообще можно сделать с IGMP, тыркался, тыркался, включал мультикаст роутинг, IGMP-snooping, проверял по тысяче раз задержки и потери — ничего не помогало. А потом вдруг всё заработало. Само собой, стабильно, безотказно.
Это послужило мне прививкой против мультикаста, и долгое время я не проявлял к нему никакого интереса.
Уже гораздо позже я пришёл в к следующему правилу:

И теперь с высоты оттраблшученных кейсов я понимаю, что там не могло быть никаких проблем с настройкой сетевой части — глючило конечное оборудование.

Сохраняйте спокойствие и доверьтесь мне. После этой статьи такие вещи вас пугать не будут.
Как известно, существуют следующие типы трафика:
Unicast — одноадресная рассылка — один отправитель, один получатель. (Пример: запрос HTTP-странички у WEB-сервера).
Broadcast — широковещательная рассылка — один отправитель, получатели — все устройства в широковещательном сегменте. (Пример: ARP-запрос).
Multicast — многоадресная рассылка — один отправитель, много получателей. (Пример: IPTV).
Anycast — одноадресная рассылка ближайшему узлу — один отправитель, вообще получателей много, но фактически данные отправляются только одному. (Пример: Anycast DNS).

Раз уж мы решили поговорить о мультикасте, то, пожалуй, начнём этот параграф с вопроса, где и как он используется.

Первое, что приходит на ум, — это телевидение (IPTV) — один сервер-источник отправляет трафик, который хочет получать сразу много клиентов. Это и определяет сам термин — multicast — многоадресное вещание. То есть, если уже известный вам Broadcast означает вещание всем, мультикаст означает вещание определённой группе.

Второе применение — это, например, репликация операционной системы на множество компьютеров разом. Это подразумевает загрузку больших объёмов данных с одного сервера.

Возможные сценарии: аудио и видеоконференции (один говорит — все слушают), электронная коммерция, аукционы, биржи. Но это в теории, а на практике редко тут всё-таки используется мультикаст.

Ещё одно применение — это служебные сообщения протоколов. Например, OSPF в своём широковещательном домене рассылает свои сообщения на адреса 224.0.0.5 и 224.0.0.6. И обрабатывать их будут только те узлы, на которых запущен OSPF.

Сформулируем два основных принципа мультикастовой рассылки:

Отправитель посылает только одну копию трафика, независимо от количества получателей.

Трафик получают только те, кто действительно заинтересован в нём.

В данной статье для практики мы возьмём IPTV, как наиболее наглядный пример.

Пример I

Начнём с самого простого случая:

На сервере-источнике настроено вещание в группу 224. 2.2.4 — это означает, что сервер отправляет трафик на IP-адрес 224.2.2.4. На клиенте видеоплеер настроен принимать поток группы 224.2.2.4.

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

Мультикастовый поток просто льётся с сервера, а клиент его просто принимает. Вы можете попробовать это прямо у себя на рабочем месте, соединив патчкордом два компьютера и запустив, например, VLC.

Надо заметить, что в мультикасте нет никакой сигнализации от источника, мол, «Здрасьте, я Источник, не надо немного мультикаста?».

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

Если на этом линке отловить пакеты, то вы увидите, что мультикастовый трафик — это ни что иное, как море UDP-пакетов.

Мультикаст не привязан к какому-то конкретному протоколу. По сути, всё, что его определяет — адреса. Однако, если говорить о его применении, то в абсолютном большинстве случаев используется именно UDP. Это легко объясняется тем, что обычно с помощью многоадресной рассылки передаются данные, которые нужны здесь и сейчас. Например, видео. Если кусочек кадра потеряется, и отправитель будет пытаться его послать повторно, как это происходит в TCP, то, скорее всего, этот кусочек опоздает, и где его тогда показывать? Поезд ушёл. Ровно то же самое со звуком.

Соответственно не нужно и устанавливать соединение, поэтому TCP здесь ни к чему.

Чем же так разительно отличается мультикаст от юникаста? Думаю, у вас есть уже предположение. И вы, наверняка, правы.

В обычной ситуации у нас 1 получатель и 1 отправитель — у каждого из них один уникальный IP-адрес. Отправитель точно знает, куда надо слать пакет и ставит этот адрес в заголовок IP. Каждый промежуточный узел благодаря своей таблице маршрутизации точно знает, куда переслать пакет. Юникастовый трафик между двумя узлами беспрепятственно проходит сквозь сеть. Но проблема в том, что в обычном пакете указывается только один IP-адрес получателя.

Что делать, если у одного и того же трафика несколько получателей? В принципе можно расширить одноадресный подход и на такую ситуацию — отправлять каждому клиенту свой экземпляр пакета. Клиенты не заметят разницы — хоть он один, хоть их тысяча, но разница будет отчётливо различима на ваших каналах передачи данных.

Предположим у нас идёт передача одного SD-канала с мультикаст-сервера. Пусть, он использует 2 Мб/с. Всего таких каналов 30, а смотрит каждый канал по 20 человек одновременно. Итого получается 2 Мб/с * 30 каналов * 20 человек = 1200 Мб/с или 1,2 Гб/с только на телевидение в случае одноадресной рассылки. А есть ведь ещё HD каналы, где можно смело умножать эту цифру на 2. И где тут место для торрентов?

Вот почему в IPv4 был заложен блок адресов класса D: 224.0.0.0/4 (224.0.0.0-239. 255.255.255). Адреса этого диапазона определяют мультикастовую группу. Один адрес — это одна группа, обычно она обозначается буквой «G».

То есть, говоря, что клиент подключен к группе 224.2.2.4, мы имеем ввиду, что он получает мультикастовый трафик с адресом назначения 224.2.2.4.

Пример II

Добавим в схему коммутатор и ещё несколько клиентов:

Мультикастовый сервер по-прежнему вещает для группы 224.2.2.4. На коммутаторе все 4 порта должны быть в одном VLAN. Трафик приходит на коммутатор и по умолчанию рассылается во все порты одного VLAN’а. Значит все клиенты получают этот трафик. На них на всех в видеопроигрывателе так же указан групповой адрес 224.2.2.4.

Собственно, все эти устройства становятся членами данной мультикастовой группы. Членство в ней динамическое: кто угодно, в любой момент может войти и выйти из неё.

В данной ситуаци трафик будут получать даже те, кто этого в общем-то и не хотел, то есть на нём не запущен ни плеер, ни что бы то ни было другое. Но только, если он в том же VLAN’е. Позже мы разберёмся, как с этим бороться.

Обратите внимание, что в данном случае от сервера-источника приходит только одна копия трафика на коммутатор, а не по отдельной копии на каждого клиента. И в нашем примере с SD каналами загрузка порта между источником и коммутатором будет не 1,2 Гб/с, а всего 60 Мб/с (2Мб/с * 30 каналов).

Собственно говоря, весь этот огромный диапазон (224.0.0.0-239.255.255.255) можно использовать.

Ну, почти весь — первые адреса (диапазон 224.0.0.0/23) всё-таки зарезервированы под известные протоколы.

Список зарезервированных IP-адресов

Адрес	Значение
224.0.0.0	Не используется
224.0.0.1	Все узлы данного сегмента
224.0.0.2	Все мультикастовые узлы данного сегмента
224.0.0.4	Данный адрес выделялся для покойного протокола DVMRP
224. 0.0.5	Все OSPF-маршрутизаторы сегмента
224.0.0.6	Все DR маршрутизаторы сегмента
224.0.0.9	Все RIPv2-маршрутизаторы сегмента
224.0.0.10	Все EIGRP-маршрутизаторы сегмента
224.0.0.13	Все PIM-маршрутизаторы сегмента
224.0.0.18	Все VRRP-маршрутизаторы сегмента
224.0.0.19-21	Все IS-IS-маршрутизаторы сегмента
224.0.0.22	Все IGMP-маршрутизаторы сегмента (v2 и v3)
224.0.0.102	Все HSRPv2/GLBP-маршрутизаторы сегмента
224.0.0.107	PTPv2 — Precision Time Protocol
224.0.0.251	mDNS
224.0.0.252	LLMNR
224.0.0.253	Teredo
224.0.1.1	NTP
224. 0.1.39	Cisco Auto-RP-Announce
224.0.1.40	Cisco Auto-RP-Discovery
224.0.1.41	H.323 Gatekeeper
224.0.1.129-132	PTPv1/PTPv2
239.255.255.250	SSDP

Диапазон 224.0.0.0/24 зарезервирован под link-local коммуникации. Мультикастовые пакеты с такими адресами назначения не могут выходить за пределы одного широковещательного сегмента.
Диапазон 224.0.1.0/24 зарезервирован под протоколы, которым необходимо передавать мультикаст по всей сети, то есть проходить через маршрутизаторы.

Вот, собственно, самые базисные вещи касательно мультикаста.

Мы рассмотрели простую ситуацию, когда источник и получатель находятся в одном сегменте сети. Трафик, полученный коммутатором, просто рассылается им во все порты — никакой магии.

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

Вообще, чтобы доставить мультикаст от источника до получателя на данный момент существует много протоколов — IGMP/MLD, PIM, MSDP, MBGP, MOSPF, DVMRP.

Мы остановимся на двух из них, которые используются в настоящее время: PIM и IGMP.

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

Снова вернёмся к дампу. Видите вот этот верхний пакет, после которого полился мультикастовый поток?

Это сообщение протокола 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 — узел «рапортует» о том, что хочет получать трафик этой группы.

В 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*.

По умолчанию это происходит каждые 60 секунд. TTL таких пакетов тоже равен 1. Они отправляются на адрес 224.0.0.1 — все узлы в этом сегменте — без указания конкретной группы. Такие сообщений Query называются General Query — общие. Таким образом маршрутизатор спрашивает: «Ребят, а кто и что ещё хочет получать?».

Получив IGMP General Query, любой хост, который слушает любую группу, должен отправить IGMP Report, как он это делал при подключении. В Report, естественно, должен быть указан адрес интересующей его группы.

*Дамп отфильтрован по 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 на адрес группы.

Маршрутизатор получает его и по идее должен отключить. Но он ведь не может отключить одного конкретного клиента — маршрутизатор их не различает — у него просто есть нисходящий интерфейс. А за интерфейсом может быть несколько клиентов. То есть, если маршрутизатор удалит этот интерфейс из своего списка OIL (Outgoing Interface List) для этой группы, видео выключится у всех.

Но и не удалять его совсем тоже нельзя — вдруг это был последний клиент — зачем тогда впустую вещать?

Если вы посмотрите в дамп, то увидите, что после получения Leave маршрутизатор ещё некоторое время продолжает слать поток. Дело в том, что маршрутизатор в ответ на Leave высылает IGMP Query на адрес группы, для которой этот Leave пришёл в тот интерфейс, откуда он пришёл. Такой пакет называется Group Specific Query. На него отвечают только те клиенты, которые подключены к данной конкретной группе.

Если маршрутизатор получил ответный Report для группы, он продолжает вещать в интерфейс, если не получил — удаляет по истечении таймера.

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

*Дамп отфильтрован по IGMP*.

Далее маршрутизатор останавливает поток.

Querier

Рассмотрим чуть более сложный случай:

В клиентский сегмент подключено два (или больше) маршрутизатора, которые могут вещать трафик. Если ничего не сделать, мультикастовый трафик будет дублироваться — оба маршрутизатора ведь будут получать Report от клиентов. Во избежание этого существует механизм выбора Querier — опрашивателя. Тот кто победит, будет посылать Query, мониторить Report и реагировать на Leave, ну и, соответственно, он будет отправлять и трафик в сегмент. Проигравший же будет только слушать Report и держать руку на пульсе.

Выборы происходят довольно просто и интуитивно понятно.

Рассмотрим ситуацию с момента включения маршрутизаторов R1 и R2.
1) Активировали IGMP на интерфейсах.
2) Сначала по умолчанию каждый из них считает себя Querier.
3) Каждый отправляет IGMP General Query в сеть. Главная цель — узнать, есть ли клиенты, а параллельно — заявить другим маршрутизаторам в сегменте, если они есть, о своём желании участвовать в выборах.
4) General Query получают все устройства в сегменте, в том числе и другие IGMP-маршрутизаторы.
5) Получив такое сообщение от соседа, каждый маршрутизатор оценивает, кто достойнее.
6) Побеждает маршрутизатор с меньшим IP (указан в поле Source IP пакета IGMP Query). Он становится Querier, все другие — Non-Querier.
7) Non-Querier запускает таймер, который обнуляется каждый раз, как приходит Query с меньшим IP-адресом. Если до истечения таймера (больше 100 секунд: 105-107) маршрутизатор не получит Query с меньшим адресом, он объявляет себя Querier и берёт на себя все соответствующие функции.
8) Если Querier получает Query с меньшим адресом, он складывает с себя эти обязанности. Querier’ом становится другой маршрутизатор, у которого IP меньше.

Тот редкий случай, когда меряются, у кого меньше.

Выборы 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 предназначен для взаимодействия клиентов и маршрутизатора. Поэтому, возвращаясь к Примеру II, где нет маршрутизатора, мы можем авторитетно заявить — IGMP там — не более, чем формальность. Маршрутизатора нет, и клиенту не у кого запрашивать мультикастовый поток. А заработает видео по той простой причине, что поток и так льётся от коммутатора — надо только подхватить его.

Напомним, что IGMP не работает для IPv6. Там существует протокол MLD.

Повторим ещё раз

*Дамп отфильтрован по IGMP*.

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 Report — посылается клиентом при подключении и в ответ на IGMP Query. Означает, что клиент хочет получать трафик конкретной группы.
IGMP General Query — посылается маршрутизатором периодически, чтобы проверить какие группы сейчас нужны. В качестве адреса получателя указывается 224.0.0.1.
IGMP Group Sepcific Query — посылается маршрутизатором в ответ на сообщение Leave, чтобы узнать есть ли другие получатели в этой группе. В качестве адреса получателя указывается адрес мультикастовой группы.
IGMP Leave — посылается клиентом, когда тот хочет покинуть группу.
Querier — если в одном широковещательном сегменте несколько маршрутизаторов, который могут вещать, среди них выбирается один главный — Querier. Он и будет периодически рассылать Query и передавать трафик.

Подробное описание всех терминов IGMP.

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

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

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

Как в такой ситуации доставить трафик?

Существует несколько протоколов маршрутизации мультикастового трафика: DVMRP, MOSPF, CBT — все они по-разному решают такую задачу. Но стандартом де факто стал PIM — Protocol Independent Multicast.

Другие подходы настолько нежизнеспособны, что порой даже их разработчики практически признают это. Вот, например, выдержка из RFC по протоколу CBT:
CBT version 2 is not, and was not, intended to be backwards compatible with version 1; we do not expect this to cause extensive compatibility problems because we do not believe CBT is at all widely deployed at this stage.

PIM имеет две версии, которые можно даже назвать двумя различными протоколами в принципе, уж сильно они разные:

PIM Dense Mode (DM)

PIM Sparse Mode (SM)

Independent он потому, что не привязан к какому-то конкретному протоколу маршрутизации юникастового трафика, и позже вы увидите почему.

PIM Dense Mode

PIM DM пытается решить проблему доставки мультиакста в лоб. Он заведомо предполагает, что получатели есть везде, во всех уголках сети. Поэтому изначально он наводняет всю сеть мультикастовым трафиком, то есть рассылает его во все порты, кроме того, откуда он пришёл. Если потом оказывается, что где-то он не нужен, то эта ветка «отрезается» с помощью специального сообщения PIM Prune — трафик туда больше не отправляется.

Но через некоторое время в эту же ветку маршрутизатор снова пытается отправить мультикаст — вдруг там появились получатели. Если не появились, ветка снова отрезается на определённый период. Если клиент на маршрутизаторе появился в промежутке между этими двумя событиями, отправляется сообщение Graft — маршрутизатор запрашивает отрезанную ветку обратно, чтобы не ждать, пока ему что-то перепадёт.

Как видите, здесь не стоит вопрос определения пути к получателям — трафик достигнет их просто потому, что он везде.

После «обрезания» ненужных ветвей остаётся дерево, вдоль которого передаётся мультикастовый трафик. Это дерево называется SPT — Shortest Path Tree.

Оно лишено петель и использует кратчайший путь от получателя до источника. По сути оно очень похоже на Spanning Tree в STP, где корнем является источник.

SPT — это конкретный вид дерева — дерево кратчайшего пути. А вообще любое мультикастовое дерево называется MDT — Multicast Distribution Tree.

Предполагается, что PIM DM должен использоваться в сетях с высокой плотностью мультикастовых клиентов, что и объясняет его название (Dense). Но реальность такова, что эта ситуация — скорее, исключение, и зачастую PIM DM нецелесообразен.

Что нам действительно важно сейчас — это механизм избежания петель.

Представим такую сеть:

Один источник, один получатель и простейшая IP-сеть между ними. На всех маршрутизаторах запущен PIM DM.

Что произошло бы, если бы не было специального механизма избежани

Сети для самых маленьких. Часть 9.4. Мультикаст. Мультикаст на канальном уровне

Добавлено 3 апреля 2019 в 13:13

Сохранить или поделиться

Последняя статья из серии про мультикаст. Рассмотрим особенности мультикастовых MAC адресов, IGMP Snooping и Multicast VLAN Replication.

Содержание серии статей про мультикаст

Мультикаст на канальном уровне

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

Пятница — не самый плохой день, чтобы обозреть творение и позволить себе приятный отдых.

Но ваш послеобеденный сон вдруг потревожил звонок техподдержки, потом ещё один и ещё — ничего не работает, всё сломалось. Проверяете — идут потери, разрывы. Всё сходится на одном сегменте из нескольких коммутаторов.

Расчехлили SSH, проверили CPU, проверили утилизацию интерфейсов и волосы дыбом — загрузка почти под 100% на всех интерфейсах одного VLAN’а. Петля! Но откуда ей взяться, если никаких работ не проводилось? Минут 10 проверки и вы заметили, что на восходящем интерфейсе к ядру у вас много входящего трафика, а на всех нисходящих к клиентам — исходящего. Для петли это тоже характерно, но как-то подозрительно: внедрили мультикаст, никаких работ по переключению не делали и скачок только в одном направлении.

Проверили список мультикастовых групп на маршрутизаторе — а там подписка на все возможные каналы и все на один порт — естественно, тот, который ведёт в этот сегмент.

Дотошное расследование показало, что компьютер клиента заражён и рассылает IGMP Query на все мультикастовые адреса подряд.

Потери пакетов начались, потому что коммутаторам пришлось пропускать через себя огромный объём трафика. Это вызвало переполнение буферов интерфейсов.

Главный вопрос — почему трафик одного клиента начал копироваться во все порты?

Причина этого кроется в природе мультикастовых MAC-адресов. Дело в том, пространство мультикастовых IP-адресов специальным образом отображается в пространство мультикастовых MAC-адресов. И загвоздка в том, что они никогда не будут использоваться в качестве MAC-адреса источника, а следовательно, не будут изучены коммутатором и занесены в таблицу MAC-адресов. 5=32 IP-адреса. Например, группы 224.0.0.1, 224.128.0.1, 225.0.0.1 и так до 239.128.0.1 все будут отображаться в один MAC-адрес 0100:5e00:0001.

Если взять в пример дамп потокового видео, то можно увидеть:

Дамп мультикаста

IP адрес — 224.2.2.4, MAC-адрес: 01:00:5E:02:02:04.

Есть также другие мультикастовые MAC-адреса, которые никак не относятся к IPv4-мультикаст (клик). Все они, кстати, характеризуются тем, что последний бит первого октета равен 1.

Естественно, ни на одной сетевой карте, не может быть настроен такой MAC-адрес, поэтому он никогда не будет в поле Source MAC Ethernet-кадра и никогда не попадёт в таблицу MAC-адресов. Значит такие кадры должны рассылаться как любой Unknown Unicast во все порты VLAN’а.

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

Вовсе нет. Специально для перфекционистов придуман механизм IGMP Snooping.

IGMP Snooping

Идея очень простая — коммутатор «слушает» проходящие через него IGMP-пакеты.

Для каждой группы отдельно он ведёт таблицу восходящих и нисходящих портов.

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

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

Таким образом формируется таблица передачи мультикастового трафика на канальном уровне.

В итоге, когда сверху приходит мультикастовый поток, он копируется только в нисходящие интерфейсы. Если на 16-портовом коммутаторе только два клиента, только им и будет доставлен трафик.

IGMP Snooping

Гениальность этой идеи заканчивается тогда, когда мы задумываемся о её природе. Механизм предполагает, что коммутатор должен прослушивать трафик на 3-м уровне.

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

Задача № 3

Сервер 172.16.0.5 передает мультикаст трафик на группы 239.1.1.1, 239.2.2.2 и 239.0.0.x.

Настроить сеть таким образом, чтобы:

клиент 1 не мог присоединиться к группе 239.2.2.2. Но при этом мог присоединиться к группе 239.0.0.x.
клиент 2 не мог присоединиться к группе 239.1.1.1. Но при этом мог присоединиться к группе 239.0.0.x.

Начальная конфигурация (скрыть)

ip multicast-routing
!
interface Loopback0
 ip address 1.1.1.1 255.255.255.255
 ip router isis
!
interface FastEthernet0/0
 ip address 172.16.0.1 255.255.255.0
 ip pim sparse-mode
 ip router isis
!
interface FastEthernet1/0
 ip address 10.0.12.1 255.255.255.0
 ip pim sparse-mode
 ip router isis
!
interface FastEthernet1/1
 ip address 10. 0.13.1 255.255.255.0
 ip pim sparse-mode
 ip router isis
!
router isis
 net 10.0000.0000.0001.00
!
ip pim rp-address 2.2.2.2

ip multicast-routing
interface Loopback0
 ip address 2.2.2.2 255.255.255.255
 ip pim sparse-mode
 ip router isis
!
interface FastEthernet0/0
 description to R4
 ip address 10.0.24.2 255.255.255.0
 ip pim sparse-mode
 ip router isis
!
interface FastEthernet1/0
 description to R3
 ip address 10.0.23.2 255.255.255.0
 ip pim sparse-mode
 ip router isis
!
interface FastEthernet1/1
 description to R1
 ip address 10.0.12.2 255.255.255.0
 ip pim sparse-mode
 ip router isis
!
router isis
 net 10.0000.0000.0002.00
!
ip pim rp-address 2.2.2.2

ip multicast-routing
!
interface Loopback0
 ip address 3.3.3.3 255.255.255.255
 ip router isis
!
interface FastEthernet0/0
 description to R5
 ip address 10.0.35.3 255.255.255.0
 ip pim sparse-mode
 ip router isis
!
interface FastEthernet1/0
 description to R1
 ip address 10.0.13.3 255.255.255.0
 ip pim sparse-mode
 ip router isis
!
interface FastEthernet1/1
 ip address 10.0.23.3 255.255.255.0
 ip pim sparse-mode
 ip router isis
!
router isis
 net 10.0000.0000.0003.00
!
ip pim rp-address 2.2.2.2

ip multicast-routing
!
interface Loopback0
 ip address 4.4.4.4 255.255.255.255
 ip router isis
!
interface FastEthernet0/0
 description to Client1
 ip address 192.168.4.1 255.255.255.0
 ip pim sparse-mode
 ip router isis
!
interface FastEthernet0/1
 description to R2
 ip address 10.0.24.4 255.255.255.0
 ip pim sparse-mode
 ip router isis
!
router isis
 net 10.0000.0000.0004.00
!
ip pim rp-address 2.2.2.2

ip multicast-routing
!
interface Loopback0
 ip address 5.5.5.5 255.255.255.255
 ip router isis
!
interface FastEthernet0/0
 description to Client2
 ip address 192.168.5.1 255.255.255.0
 ip pim sparse-mode
 ip router isis
!
interface FastEthernet0/1
 description to R3
 ip address 10.0.35.5 255.255.255.0
 ip pim sparse-mode
 ip router isis
!
router isis
 net 10.0000.0000.0005.00
!
ip pim rp-address 2.2.2.2

IGMP Snooping Proxy

У пытливого читателя может возникнуть вопрос по тому, как IGMP Snooping узнаёт все клиентские порты, учитывая, что на IGMP Query отвечает только один самый быстрый клиент, как мы говорили выше. А очень просто: IGMP Snooping не позволяет сообщениям Report ходить между клиентами. Они отправляются только в восходящие порты к маршрутизаторам. Не видя Report от других получателей этой группы, клиент обязан ответить на Query в течение Max Response Time, указанном в этом Query.

В итоге в сети на 1000 узлов на один IGMP Query в течение секунд 10 (обычное значение Max Response Time) придёт 1000 Report’ов маршрутизатору. Хотя ему достаточно было бы и одного для каждой группы.

И происходит это каждую минуту.

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

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

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

А дальше, в зависимости от настроек и производителя, либо этот же самый Query рассылается во все клиентские порты, либо коммутатор блокирует запрос от маршрутизатора и сам выступает в роли Querier, периодически опрашивая всех получателей.

Таким образом снижается и доля лишнего служебного трафика в сети и нагрузка на маршрутизатор.

Multicast VLAN Replication

Сокращённо MVR. Это механизм для тех провайдеров, кто практикует VLAN-per-user, например.

Вот типичный пример сети, где MVR жизненно необходим:

MVR

5 клиентов в разных VLAN’ах, и все хотят получать мультикастовый трафик одной группы 224.2.2.4. При этом клиенты должны оставаться изолированными друг от друга.

IGMP Snooping учитывает, разумеется и VLAN’ы. Если пять клиентов в разных VLAN’ах запрашивают одну группу — это будет пять разных таблиц. Соответственно и к маршрутизатору идут 5 запросов на подключение к группе. И каждый сабинтерфейс из этих пяти на маршрутизаторе будет добавлен отдельно в OIL. То есть получив 1 поток для группы 224.2.2.4 он отправит 5 копий, несмотря на то, что все они идут в один сегмент.

Multicast VLAN Replication

Для решения этой проблемы и был разработан механизм Multicast VLAN Replication.

Вводится дополнительный VLAN — Multicast VLAN — в нём, соответственно, будет передаваться мультикастовый поток. Он «проброшен» непосредственно до последнего коммутатора, где трафик из него копируется во все клиентские интерфейсы, которые хотят получать этот трафик — это и есть репликация.

В зависимости от реализации репликация из Multicast VLAN может производиться в User-VLAN или в определённые физические интерфейсы.

Multicast VLAN Replication

А что с IGMP-сообщениями? Query от маршрутизатора, естественно, приходит по мультикастовому VLAN’у. Коммутатор их рассылает в клиентские порты. Когда Report или Leave приходит от клиента, коммутатор проверяет откуда именно (VLAN, интерфейс) и, если необходимо, перенаправляет в мультикастовый VLAN.

Таким образом обычный трафик изолирован и по-прежнему ходит до маршрутизатора в пользовательском VLAN’е. А мультикастовый трафик и IGMP-пакеты передаются в Multicast VLAN.

На оборудовании Cisco MVR и IGMP Snooping настраиваются независимо. То есть можно отключить один и второй будет работать. Вообще же MVR основан на IGMP Snooping и на коммутаторах других производителей для работы MVR может быть обязательным включение IGMP Snooping.

Кроме того, IGMP Snooping позволяет осуществлять на коммутаторах фильтрацию трафика, ограничивать количество групп, доступных пользователю, включение IGMP Querier, статическую настройку восходящих портов, перманентное подключение к какой-либо группе (этот сценарий есть в сопутствующем видео), быструю реакцию на изменение топологии путём рассылки дополнительных Query, SSM-Mapping для IGMPv2 и т.д.

Заканчивая разговор об IGMP Snooping, хочется повторить — это необязательный функционал — всё и без него будет работать. Но это сделает сеть более предсказуемой, а жизнь инженера спокойнее.

Однако все плюсы IGMP Snooping можно обернуть и против себя. Один такой выдающийся случай можно почитать по ссылке.

К слову у той же Cisco есть протокол CGMP — аналог IGMP, который не нарушает принципы работы коммутатора, но он проприетарный и не сказать, что широко распространённый.

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

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

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

Оба эти способа дают возможность смотреть потоковое видео только на компьютере.

Третий же вариант позволяет использовать телевизор, причём как правило, любой. Для этого в доме клиента ставит так называемый Set-Top-Box (STB) — коробочка, устанавливаемая на телевизор. Это шелезяка, которая включается в абонентскую линию и разделяет трафик: обычный юникаст она отдаёт в Ethernet или WiFi, чтобы клиенты имели доступ в Интернет, а мультикастовый поток передаётся на телевизор через кабель (DVI, RGB, антенный итд.).

Часто вы, кстати, можете увидеть рекламу, где провайдер предлагает свои приставки для подключения телевидения — это и есть те самые STB

Задача 4

Напоследок нетривиальная задачка по мультикасту (авторы не мы, в ответах будет ссылка на оригинал).

Самая простая схема:

Схема сети

С одной стороны сервер-источник, с другой — компьютер, который готов принимать трафик.

Адрес мультикастового потока вы можете устанавливать сами.

И соответственно, два вопроса:

Что нужно сделать, чтобы компьютер мог получать поток и при этом не прибегать к мультикастовой маршрутизации?
Допустим, вы вообще не знаете, что такое мультикаст и не можете его настраивать, как передать поток от сервера к компьютеру?

Задача легко ищется в поисковике, но попробуйте решить её сами.

Незатронутыми в статье остались междоменная маршрутизация мультикастового трафика (MSDP, MBGP, BGMP), балансировка нагрузки между RP (Anycast RP), PGM, проприетарные протоколы. Но, я думаю, имея как точку старта эту статью, разобраться в остальном не составит труда.

Источник:

Сети для самых маленьких. Часть 9.1. Мультикаст. Общее понимание Multicast

Добавлено 1 апреля 2019 в 06:10

Сохранить или поделиться

Наш умозрительный провайдер linkmeup взрослеет и обрастает по-тихоньку всеми услугами обычных операторов связи. Теперь мы доросли до IPTV.

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

Это первое отклонение от привычных нам принципов работы IP-сетей. Всё-таки парадигма многоадресной рассылки в корне отличается от тёплого лампового юникаста.

Можно даже сказать, это в некоторой степени бросает вызов гибкости вашего разума в понимании новых подходов.

В этой серии статей сосредоточимся на следующем:

Содержание серии статей про мультикаст

На заре моего становления, как инженера, тема мультикаста меня неимоверно пугала, и я связываю это с психотравмой моего первого опыта с ним.

«Так, Марат, срочно, до полудня нужно пробросить видеопоток до нашего нового здания в центре города — провайдер отдаст его нам тут на втором этаже» — услышал я одним чудесным утром. Всё, что я тогда знал о мультикасте, так это то, что отправитель один, получателей много, ну и, кажется, протокол IGMP там как-то задействован.

В итоге до полудня мы пытались всё это дело запустить — я пробросил самый обычный VLAN от точки входа до точки выхода. Но сигнал был нестабильным — картинка замерзала, разваливалась, прерывалась. Я в панике пытался разобраться, что вообще можно сделать с IGMP, тыркался, тыркался, включал мультикаст роутинг, IGMP Snooping, проверял по тысяче раз задержки и потери — ничего не помогало. А потом вдруг всё заработало. Само собой, стабильно, безотказно.

Это послужило мне прививкой против мультикаста, и долгое время я не проявлял к нему никакого интереса.

Уже гораздо позже я пришёл в к следующему правилу:

И теперь с высоты оттраблшученных кейсов я понимаю, что там не могло быть никаких проблем с настройкой сетевой части — глючило конечное оборудование.

Сохраняйте спокойствие и доверьтесь мне. После этой статьи такие вещи вас пугать не будут.

Общее понимание Multicast

Как известно, существуют следующие типы трафика:

Unicast: Одноадресная рассылка — один отправитель, один получатель. (пример: запрос HTTP-странички у WEB-сервера).
Broadcast: Широковещательная рассылка — один отправитель, получатели — все устройства в широковещательном сегменте. (пример: ARP-запрос).
Multicast: Многоадресная рассылка — один отправитель, много получателей. (пример: IPTV).
Anycast: Одноадресная рассылка ближайшему узлу — один отправитель, вообще получателей много, но фактически данные отправляются только одному. (пример: Anycast DNS).

Первое, что приходит на ум, — это телевидение (IPTV) — один сервер-источник отправляет трафик, который хочет получать сразу много клиентов. Это и определяет сам термин — multicast — многоадресное вещание. То есть, если уже известный вам Broadcast означает вещание всем, мультикаст означает вещание определённой группе.

Сформулируем два основных принципа мультикастовой рассылки:

отправитель посылает только одну копию трафика, независимо от количества получателей;
трафик получают только те, кто действительно заинтересован в нём.

В данной статье для практики мы возьмём IPTV, как наиболее наглядный пример.

Пример 1

Начнём с самого простого случая:

Пример 1

На сервере-источнике настроено вещание в группу 224.2.2.4 — это означает, что сервер отправляет трафик на IP-адрес 224.2.2.4. На клиенте видеоплеер настроен принимать поток группы 224.2.2.4.

При этом, заметьте, клиент и сервер не обязательно должны иметь адреса из одной подсети и пинговать друг друга — достаточно, чтобы они были в одном широковещательном домене. Мультикастовый поток просто льётся с сервера, а клиент его просто принимает. Вы можете попробовать это прямо у себя на рабочем месте, соединив патчкордом два компьютера и запустив, например, VLC.

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

Если на этом линке отловить пакеты, то вы увидите, что мультикастовый трафик — это ни что иное, как море UDP-пакетов.

Содержимое мультикастового трафика

Соответственно не нужно и устанавливать соединение, поэтому TCP здесь ни к чему.

Что делать, если у одного и того же трафика несколько получателей? В принципе можно расширить одноадресный подход и на такую ситуацию — отправлять каждому клиенту свой экземпляр пакета. Клиенты не заметят разницы — хоть он один, хоть их тысяча, но разница будет отчётливо различима на ваших каналах передачи данных.

Зависимость нагрузки на сеть от количества пользователей при передаче юникаст и мультикаст трафика

Вот почему в IPv4 был заложен блок адресов класса D: 224.0.0.0/4 (224.0.0.0-239.255.255.255). Адреса этого диапазона определяют мультикастовую группу. Один адрес — это одна группа, обычно она обозначается буквой «G».

То есть, говоря, что клиент подключен к группе 224.2.2.4, мы имеем ввиду, что он получает мультикастовый трафик с адресом назначения 224.2.2.4.

Пример 2

Добавим в схему коммутатор и ещё несколько клиентов:

Пример 2

Собственно, все эти устройства становятся членами данной мультикастовой группы. Членство в ней динамическое: кто угодно, в любой момент может войти и выйти из неё.

В данной ситуаци трафик будут получать даже те, кто этого в общем-то и не хотел, то есть на нём не запущен ни плеер, ни что бы то ни было другое. Но только, если он в том же VLAN’е. Позже мы разберёмся, как с этим бороться.

Собственно говоря, весь этот огромный диапазон (224.0.0.0-239.255.255.255) можно использовать. Ну, почти весь — первые адреса (диапазон 224.0.0.0/23) всё-таки зарезервированы под известные протоколы.

Список зарезервированных IP-адресов
Адрес	Значение
224.0.0.0	Не используется
224.0.0.1	Все узлы данного сегмента
224.0.0.2	Все мультикастовые узлы данного сегмента
224.0.0.4	Данный адрес выделялся для покойного протокола DVMRP
224.0.0.5	Все OSPF-маршрутизаторы сегмента
224.0.0.6	Все DR маршрутизаторы сегмента
224.0.0.9	Все RIPv2-маршрутизаторы сегмента
224.0.0.10	Все EIGRP-маршрутизаторы сегмента
224.0.0.13	Все PIM-маршрутизаторы сегмента
224.0.0.18	Все VRRP-маршрутизаторы сегмента
224.0.0.19-21	Все IS-IS-маршрутизаторы сегмента
224.0.0.22	Все IGMP-маршрутизаторы сегмента (v2 и v3)
224.0.0.102	Все HSRPv2/GLBP-маршрутизаторы сегмента
224.0.0.107	PTPv2 — Precision Time Protocol
224.0.0.251	mDNS
224.0.0.252	LLMNR
224.0.0.253	Teredo
224.0.1.1	NTP
224.0.1.39	Cisco Auto-RP-Announce
224.0.1.40	Cisco Auto-RP-Discovery
224.0.1.41	H.323 Gatekeeper
224.0.1.129-132	PTPv1/PTPv2
239.255.255.250	SSDP

Диапазон 224.0.1.0/24 зарезервирован под протоколы, которым необходимо передавать мультикаст по всей сети, то есть проходить через маршрутизаторы.

Вот, собственно, самые базисные вещи касательно мультикаста.

Мы рассмотрели простую ситуацию, когда источник и получатель находятся в одном сегменте сети. Трафик, полученный коммутатором, просто рассылается им во все порты — никакой магии.

Вообще, чтобы доставить мультикаст от источника до получателя на данный момент существует много протоколов — IGMP/MLD, PIM, MSDP, MBGP, MOSPF, DVMRP.

Мы остановимся на двух из них, которые используются в настоящее время: PIM и IGMP.

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

Использование протоколов PIM и IGMP на участках сети

Источник:

Базовое включение IGMP-snooping на коммутаторах QTech

IGMP snooping — процесс отслеживания сетевого трафика IGMP, который позволяет сетевым устройствам канального уровня (свитчам) отслеживать IGMP-обмен между потребителями и поставщиками (маршрутизаторами) многоадресного (multicast) IP-трафика, формально происходящий на более высоком (сетевом) уровне. Эта функциональность доступна во многих управляемых коммутаторах для сети Ethernet(по крайней мере среднего и верхнего ценовых уровней), но всегда требует отдельного включения и настройки. Ниже представлены базовые настройки IGMP snooping для коммутаторов доступа

2800v2/2870

igmp-snooping start    - глобальное включение на коммутаторе
igmp-snooping mvlan 56 – переход в конфигурацию влана
igmp-snooping multicast-vlan enable – включение мультикаст вещание во влане
igmp-snooping multicast user-vlan 72,999 – указание пользовательких вланов в котором будут осуществляться запросы на подписку
igmp-snooping uplink-port gigaethernet 1/0/28 – аплинк порт, откуда будет идти вещание
interface fastethernet 1/0/1-24
igmp-snooping enable – включение igmp на абонентском порту
igmp-snooping drop query  - отбрасывать квери сообщения со стороны абонентов
igmp-snooping mvlan 56 user-vlan 72 – указание вланов в котором будет идти трафик
interface gigaethernet 1/0/28 
igmp-snooping enable   - включение igmp на аплинк порту
igmp-snooping drop report  - отбрасывать репорт сообщения со стороны аплинка

2800/2850/3450/3470/8200/8300/8370

vlan 901   - создание влана 
multicast-vlan – указание что влан является мультикастовым
Interface Ethernet1/1-24
switchport association multicast-vlan 901 – ассоциировать мультикаст запросы с вланом 901
igmp snooping drop query - отбрасывать квери сообщения со стороны абонентов
Interface Ethernet1/25
igmp snooping drop report - отбрасывать репорт сообщения со стороны аплинка
ip igmp snooping – глобальное включение igmp-snooping
ip igmp snooping vlan 901 – указание в каком влане будет работать igmp-snooping 
ip igmp snooping vlan 901 mrouter-port interface Ethernet1/25  - указание аплинк порта

2900/2910/3900

igmp-snooping - глобальное включение igmp-snooping
interface ethernet 0/0/1-24
igmp-snooping drop query - отбрасывать квери сообщения со стороны абонентов 
igmp-snooping multicast vlan 150  - указание влана в котором будут igmp пакеты
exit
interface ethernet 0/1/1
igmp-snooping drop report - отбрасывать репорт сообщения со стороны аплинка
igmp-snooping multicast vlan 150 указание влана в котором будут igmp пакеты.

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

Source Specific Multicast (SSM) и фильтрация IGMP — Daniels Networking Blog

Обычная многоадресная передача известна как многоадресная передача от любого источника (ASM). Он основан на модели
«многие ко многим», где источником может быть кто угодно, и известна только группа. Для некоторых приложений
, таких как биржа фондовой торговли, это хороший выбор, но для использования IPTV имеет смысл использовать SSM, так как он будет лучше масштабироваться, когда нет необходимости в RP.

ASM

строит совместно используемое дерево (RPT) от получателя к RP и дерево кратчайшего пути
(SPT) от отправителя к RP.Все должно проходить через RP
до переключения на SPT, строящий дерево напрямую от получателя к отправителю.
RPT использует запись (*, G), а SPT использует запись (S, G) в MRIB.

SSM не использует RP, вместо этого он использует IGMP версии 3, чтобы сигнализировать, к какому каналу (источнику)
должен присоединиться для группы. IGMPv3 может использовать сообщения INCLUDE, которые указывают, что разрешены только эти источники
, или они могут использовать EXCLUDE, чтобы разрешить все источники, кроме этих.

SSM имеет диапазон IP 232.Выделено 0.0.0 / 8, и это диапазон по умолчанию в IOS, но мы можем также использовать SSM для других диапазонов IP. Если мы это сделаем, нам нужно указать это с помощью ACL.

SSM

можно включить на всех маршрутизаторах, которые должны работать в режиме SSM, но на маршрутизаторах, к которым подключены приемники, действительно требуется только
, поскольку именно в этом месте
поведение действительно меняется. Вместо отправки соединения (*, G) к RP
маршрутизатор последнего перехода (LHR) отправляет соединение (S, G) непосредственно источнику.

Это топология, которую мы используем.

Это действительно просто. R1 действует как источник многоадресной рассылки, а R2 будет имитировать клиента
и выполнять фильтрацию. R3 будет имитировать конечный хост. R1 будет источником трафика из своей петлевой проверки.
OSPF включен на всех соответствующих интерфейсах.

Мы начнем с включения SSM для диапазона 225.0.0.0/24 на R2.

 R2 # конф т
Введите команды конфигурации, по одной в каждой строке. Закончите CNTL / Z.
R2 (config) # список доступа 1 разрешение 225.0.0.0 0.0.0.255
R2 (config) #ip pim ssm диапазон 1

R2 теперь будет использовать SSM для 225.0,0,0 / 24 диапазона. R2 присоединится к группе 225.0.0.1.
Мы будем отлаживать IGMP и PIM, чтобы следить за всем, что происходит. При использовании igmp join-group
на интерфейсе маршрутизатор имитирует отчет IGMP, поступающий на этот интерфейс. Позже мы увидим
, почему это важно. Итак, сначала мы включаем отладку в буфер.
Также мы должны включить групповую маршрутизацию и включить разреженный режим PIM на соответствующих интерфейсах.

 R1 # conf т
Введите команды конфигурации, по одной в каждой строке. Закончите CNTL / Z.R1 (config) #ip многоадресная маршрутизация
R1 (конфигурация) #int s0 / 0
R1 (config-if) #ip pim sparse-mode
R1 (config-if) # do debug ip pim
Отладка PIM включена
R1 (config-if) #

 R2 (config) #ip многоадресная маршрутизация
R2 (конфигурация) #int s0 / 0
R2 (config-if) #ip pim sparse-режим
R2 (конфигурация-если) #int f0 / 0
R2 (config-if) #ip pim sparse-режим
R2 (config-if) #ip igmp версия 3
R2 (конфигурация-если) #
* 1 марта 00: 18: 37.595:% PIM-5-DRCHG: изменение DR с соседнего 0.0.0.0 на 23.23.23.2 на интерфейсе FastEthernet0 / 0
R2 (confi

Страница не найдена

Документы

Моя библиотека

раз

Моя библиотека
«»

×

×
Настройки файлов cookie

Настройка сети Ubiquiti
для использования с mDNS и многоадресной рассылкой

Goal

В этом документе мы рассмотрим самый простой способ правильно настроить вашу сеть Ubiquiti для использования с mDNS и устройствами многоадресной рассылки и получить базовое представление о внесенных изменениях.

Хотя приведенные ниже инструкции относятся к продуктам Ubiquiti на текущий момент, общие концепции должны применяться к большинству управляемых сетей.

Мы расскажем о включении IGMP и mDNS, а затем о том, как настроить маршрутизацию для правильного прохождения mDNS и многоадресного трафика.

Допущения и предупреждения

Мы предполагаем, что вы используете полностью управляемую сеть, и специально для этого документа сеть Ubiquiti (маршрутизатор, коммутаторы и, возможно, точки беспроводного доступа) , которая уже работает со статическими IP-адресами, назначенными для всего оборудования Ubiquiti.

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

Таким образом, настоятельно рекомендуется использовать одно и то же управляемое сетевое оборудование «сверху вниз», чтобы предотвратить разочарование, вызванное несовместимостью.

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

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

Признаки неправильно настроенной сети…

м DNS
Когда вы используете инструмент обнаружения или настройки, он не может обнаружить ваше устройство, подключенное к той же сети
Когда вы используете инструмент обнаружения или настройки, он случайным образом находит устройства, которые также случайным образом исчезают.
Многоадресная передача
При подключении к источнику многоадресной рассылки ваше видео выглядит «размазанным» или «растекшимся».
При подключении к источнику многоадресной рассылки и успешном подключении, но при отсутствии содержимого
При подключении к источнику многоадресной рассылки происходит сбой в сети
При подключении к источнику многоадресной рассылки ваша сеть замедляется до неприемлемой скорости

Обзор проблем и шагов

Если у вас более одного (1) сетевого коммутатора, используемого в ситуации с оборудованием и приложениями, которые используют mDNS для обнаружения, коммутаторам необходимо указать, какой коммутатор будет «держателем» таблиц обнаружения mDNS.

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

Эти таблицы — это то, на что ваша сеть будет ссылаться, когда пытается направить трафик на ваше устройство. Если столы неправильно удерживаются в одном месте, обнаружение будет в лучшем случае прерывистым.

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

Multicast-трафик через вашу сеть Wi-Fi — это решение, которое не следует принимать легкомысленно, поскольку очень легко перегрузить точку беспроводного доступа многоадресным трафиком. Также следует отметить, что не все точки беспроводного доступа способны обрабатывать многоадресный трафик; обратитесь к документации производителя.

Ubiquiti Оборудование, использованное для этой документации

(1) UC-CK «Ключ Unifi Cloud» или «Контроллер»
Версия прошивки 5.7.23-10670
(1) USG «Единый шлюз безопасности»
Версия прошивки 4.4.18.5052172
(1) US-48-750 «48-портовый управляемый коммутатор с PoE + мощностью 750 Вт»
Версия прошивки 3.9.27.8537
(1) US-24-500 «Управляемый коммутатор с 24 портами, 500 Вт, PoE +»
Версия прошивки 3.9.27.8537
(1) US-8-150 «8-портовый управляемый коммутатор с PoE + мощностью 150 Вт»
Версия прошивки 3.9.27.8537
(1) US-8-60 «8-портовый управляемый коммутатор с PoE + мощностью 60 Вт»
Версия прошивки 3.9.27.8537
(1) UAP-AC-PRO-US «Точка доступа 802.11ac Dual Radio Pro»
Версия прошивки 3.9.27.8537

Приступим к настройке!

Включение отслеживания IGMP

Войдите в веб-интерфейс вашей сети Ubiquiti, используя «Unifi Web Login», или напрямую войдя в IP-адрес вашего контроллера / облачного ключа.

После входа в систему вы должны увидеть «Панель мониторинга» с текущей сетевой статистикой и графиками, аналогичными показанным ниже.

Нажмите кнопку «Настройки», которая выглядит как шестеренка в левом нижнем углу «Панели управления», чтобы перейти на главную страницу настроек сети.

На панели навигации слева выберите параметр «Сети».

Найдите вашу сеть в списке. Если это базовая сеть, вы можете увидеть в списке только одну. Выберите опцию «РЕДАКТИРОВАТЬ» справа от сетевого «ИМЯ».

Убедитесь, что установлен флажок «Включить отслеживание IGMP».

Щелкните кнопку «СОХРАНИТЬ» внизу страницы.

Включение WiFi IGMPv3

Теперь, когда мы включили IGMP Snooping для сети, мы продолжим с того места, где остановились, и включим конфигурации беспроводной сети для IGMPv3.

Используя панель навигации слева, выберите «Беспроводные сети»

Теперь вам будет представлен список всех настроенных беспроводных сетей. Пожалуйста, выберите опцию «ИЗМЕНИТЬ» на том устройстве, которое вы собираетесь использовать с mDNS и оборудованием многоадресной передачи.

В нижней части страницы беспроводной сети есть опция под названием «Multicast Enhancement» с флажком «Enable multicast extension (IGMPv3)», просто установите этот флажок.

Теперь нажмите кнопку «СОХРАНИТЬ» внизу страницы.

Блокировка многоадресного трафика из локальной сети в сеть WiFi и параметры

На той же странице мы только что включили IGMPv3, теперь у нас есть несколько вариантов в отношении многоадресного трафика и того, как он обрабатывается между LAN и беспроводной сетью.

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

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

Если мы хотим заблокировать многоадресный трафик из локальной сети в беспроводную сеть, нам просто нужно установить флажок «Блокировать многоадресную и широковещательную передачу из локальной сети в WLAN».

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

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

Если вы собираетесь использовать многоадресную рассылку по беспроводной сети, это настоятельно рекомендуется для реализации.

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

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

Нажмите кнопку «СОХРАНИТЬ» внизу.

Включение mDNS

Теперь, когда мы настроили IGMP и Multicast Filtering, мы продолжим с того места, где остановились, и включим mDNS.

Используя панель навигации слева, выберите «Services»

Теперь вы увидите верхнюю панель с одним из вариантов «MDNS», выберите этот вариант.

Нажмите кнопку-переключатель, чтобы установить «Включить многоадресный DNS» в состояние «ВКЛ.»

Нажмите «ПРИМЕНИТЬ ИЗМЕНЕНИЯ»

Хорошие новости…

Вы настроили ВСЕ Ubiquiti позволяет настраивать через веб-интерфейс для многоадресного трафика и обнаружения mDNS.

И плохие новости…

Если у вас сеть с более чем одним (1) переключателем, этих настроек недостаточно.

И еще несколько хороших новостей…

Следуя приведенным ниже инструкциям, мы войдем в каждый коммутатор в сети и вручную настроим коммутаторы для правильной связи.

Итак, приступим к настройке!

Настройка «Logical Querier» и «Query Interval» для каждого коммутатора

Перед тем, как начать, нужно принять важное решение…

Какой сетевой коммутатор будет размещать записи mDNS?

Самое простое решение — выбрать сетевой коммутатор, который обеспечит наименьшее количество «скачков» между взаимодействующими устройствами многоадресной рассылки.

По сути, мы хотим выбрать сетевой коммутатор, который является САМЫМ центральным для всех других коммутаторов и оборудования многоадресной рассылки, используемого на них.

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

Для начала перейдите на страницу «УСТРОЙСТВА», представленную символом круга внутри круга справа.

Выделите первый переключатель в списке, независимо от того, какой из них, и панель свойств должна открыться.Нажмите на опцию «Инструменты».

Нажмите кнопку «ОТКРЫТЬ ТЕРМИНАЛ» и откройте новый протокол w

IGMP, Internet Group Management Protocol

IGMP, Internet Group Management Protocol.

IGMP, протокол управления интернет-группами

Описание:

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

IGMP версии 0.

RFC 988, страницы 1-3:

Многоадресная IP-рассылка определяется как передача IP-дейтаграммы в «группу хостов», набор из нуля или более хостов, идентифицируемых одним IP-адресом назначения.
Многоадресная дейтаграмма доставляется всем членам целевой группы хостов с одинаковым
надежность «максимальных усилий» как обычные одноадресные IP-дейтаграммы, т.е. дейтаграмма
не гарантируется прибытие ко всем членам группы назначения или в том же порядке относительно других дейтаграмм.
Членство в группе узлов динамическое; то есть хосты могут присоединяться к группам и выходить из них в любое время.
Нет ограничений на расположение или количество членов в группе хозяев,
но членство в группе может быть ограничено только теми хостами, которые имеют закрытый ключ доступа.
Хост может быть членом более чем одной группы одновременно.
Хост не обязательно должен быть членом группы, чтобы отправлять ему дейтаграммы.
Группа узлов сети может быть постоянной или временной.Постоянная группа имеет хорошо известный административно назначенный IP-адрес.
Это адрес, а не членство в группе,
это постоянно; в любое время постоянная группа может иметь любое количество членов, даже ноль.
С другой стороны, временной группе адрес назначается динамически при создании группы по запросу хоста.
Временная группа перестает существовать, и ее адрес становится пригодным для переназначения, когда ее членство падает до нуля.
Создание временных групп и поддержание информации о членстве в группах.
ответственность «многоадресных агентов», объектов, которые находятся в интернет-шлюзах или других узлах специального назначения.К каждой IP-сети или подсети, поддерживающей многоадресную IP-рассылку, напрямую подключен как минимум один агент многоадресной рассылки.
Хост запрашивает создание новых групп и присоединяется к существующим группам или выходит из них, обмениваясь сообщениями с соседним агентом.
Агенты многоадресной рассылки также отвечают за межсетевую доставку многоадресных IP-дейтаграмм.
При отправке многоадресной IP-дейтаграммы хост передает ее на групповой адрес локальной сети, который идентифицирует всех соседних членов целевой группы хостов.Если у группы есть участники в других сетях, агент многоадресной рассылки становится дополнительным
получатель локальной многоадресной рассылки и передает дейтаграмму агентам в каждой из этих сетей через систему интернет-шлюза.
Наконец, каждый из агентов в других сетях передает дейтаграмму как локальную многоадресную рассылку своим собственным соседним членам группы назначения.
Уровень 2: полная поддержка многоадресной IP-рассылки, позволяет хосту создавать, присоединяться и выходить из групп хостов, а также отправлять дейтаграммы IP в группы хостов.Это требует реализации протокола управления группами Интернета (IGMP) и расширения IP-адресов и интерфейсов служб локальной сети внутри хоста.
Все следующие разделы этой памятки применимы к реализациям уровня 2.

RFC 988, стр. 10:

В IP-модуле операции управления членством поддерживаются
Протокол управления группами Интернета (IGMP), указанный в Приложении I.
Помимо сообщений, соответствующих каждой из указанных выше операций, IGMP также определяет
Процедура «таймера аварийного отключения», при которой хосты периодически подтверждают свое членство с многоадресными агентами.
IP-модуль должен поддерживать структуру данных, в которой перечислены IP-адреса всех хостов.
группы, к которым в настоящее время принадлежит хост, а также политика обратной связи каждой группы, ключ доступа и переменные таймера.
Эта структура данных используется службой многоадресной передачи IP, чтобы знать, какие исходящие дейтаграммы нужно возвращать, а также приемом.
service, чтобы знать, какие входящие дейтаграммы принимать.
Цель IGMP и операций интерфейса управления — поддерживать эту структуру данных.

RFC 988, стр. 13:

Протокол управления группами Интернета (IGMP) используется между IP-узлами и их
непосредственные соседние многоадресные агенты для поддержки создания временных групп,
добавление и удаление членов группы, а также периодическое подтверждение членства в группе.
IGMP — это асимметричный протокол, который определяется здесь с точки зрения хоста, а не многоадресного агента.

MAC-заголовок

IP-заголовок

Пакет IGMP

Версия IGMP 0, формат пакета:

00	08	16
Тип	Код	Контрольная сумма IGMP
Идентификатор
Групповой адрес
Ключ доступа :::

Тип.
8 бит.

Тип	Описание
1	Создать групповой запрос.
2	Создать ответ группы.
3	Запрос на присоединение к группе.
4	Присоединиться к ответу группы.
5	Запрос на выход из группы.
6	Оставить ответ группы.
7	Подтвердите групповой запрос.
8	Подтвердить ответ группы.

Код.
8 бит.
В сообщении Create Group Request это поле указывает, должна ли новая группа узлов быть открытой или частной.
Во всех остальных сообщениях запроса это поле установлено в ноль.

Код	Описание
0	Public.
1	Частный.

В ответном сообщении поле Code указывает результат запроса.

Код	Описание
0	Запрос удовлетворен.
1	Запрос отклонен, ресурсов нет.
2	Запрос отклонен, неверный код.
3	Запрос отклонен, неверный групповой адрес.
4	Запрос отклонен, неверный ключ доступа.
5 — 255	Запрос на рассмотрении, повторите попытку через это количество секунд.

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

Идентификатор.
32 бита.
В сообщении подтверждения группового запроса поле идентификатора содержит ноль.
Во всех других сообщениях запроса поле идентификатора содержит значение, позволяющее отличить запрос от других запросов того же хоста.
В ответном сообщении поле идентификатора содержит то же значение, что и в соответствующем сообщении запроса.

Адрес группы.
32 бита.
В сообщении Create Group Request поле адреса группы содержит ноль.Во всех других сообщениях запроса поле адреса группы содержит адрес группы хостов.
В сообщении Create Group Reply поле группового адреса содержит либо вновь назначенный адрес группы хостов (если запрос удовлетворен), либо ноль (если отклонен).
Во всех других ответных сообщениях поле адреса группы содержит тот же адрес группы узлов, что и в соответствующем сообщении запроса.

Ключ доступа.
64 бит.
В сообщении Create Group Request поле ключа доступа содержит ноль.Во всех других сообщениях запроса поле ключа доступа содержит ключ доступа, назначенный группе узлов, указанной в поле адреса группы (ноль для общедоступных групп).
В сообщении Create Group Reply поле ключа доступа содержит либо ненулевое 64-битное число (если запрос для частной группы предоставлен), либо ноль.
Во всех других ответных сообщениях поле ключа доступа содержит тот же ключ доступа, что и в соответствующем запросе.

IGMP версии 1.

RFC 1054, страницы с 10 по 13:

Протокол управления группами в Интернете (IGMP (v0)) используется IP-хостами для сообщения о своем членстве в группе хостов любым соседним маршрутизаторам многоадресной рассылки.
IGMP — это асимметричный протокол, который указывается здесь с точки зрения хоста, а не многоадресного маршрутизатора.
(IGMP также может использоваться симметрично или асимметрично между маршрутизаторами многоадресной рассылки.)
Как и ICMP, IGMP является неотъемлемой частью IP.Он должен быть реализован всеми хостами, соответствующими уровню 2 спецификации IP-многоадресной рассылки.
Сообщения IGMP инкапсулируются в дейтаграммы IP с номером протокола IP 2.
Маршрутизаторы
Multicast отправляют сообщения запроса на членство в хосте (далее называемые запросами), чтобы обнаружить, какие группы хостов имеют участников в своих подключенных локальных сетях.
Запросы адресованы группе всех хостов (адрес 224.0.0.1), и
несут IP-время жизни (TTL) 1.
Хосты
отвечают на запрос, создавая отчеты о членстве в хосте (далее именуемые
Reports), сообщая о каждой группе узлов, к которой они принадлежат, на сетевом интерфейсе, от которого был получен запрос.Чтобы избежать «взрыва» параллельных отчетов и уменьшить общее количество передаваемых отчетов, используются два метода:
1. Когда хост получает запрос, а не сразу отправляет отчеты, он запускает
сообщает таймер задержки для каждого членства в группе на сетевом интерфейсе входящего запроса.
Каждый таймер установлен на различное, случайно выбранное значение от нуля до D секунд.
По истечении таймера создается отчет для соответствующей группы узлов сети.Таким образом, отчеты распределяются по интервалу D секунд, а не все сразу.
2. Отчет отправляется с IP-адресом назначения, равным адресу группы узлов
сообщил, и с IP-временем жизни 1, так что другие члены той же группы в той же сети могли слышать отчет.
Если хост слышит отчет для группы, которой он
принадлежит этой сети, хост останавливает свой собственный таймер для этой группы и не создает отчет для этой группы.Таким образом, в обычном случае будет создан только один отчет для
каждая группа, присутствующая в сети, от узла-члена, чей таймер задержки истекает первым.
Обратите внимание, что маршрутизаторы многоадресной рассылки получают все дейтаграммы многоадресной рассылки IP и, следовательно, не должны
адресоваться явно. Также обратите внимание, что маршрутизаторам не нужно знать, какие хосты принадлежат группе, только то, что по крайней мере один хост принадлежит группе в конкретной сети.
Есть два исключения из поведения, описанного выше.Во-первых, если таймер задержки отчета уже запущен для членства в группе при получении запроса, этот таймер
не сбрасывается до нового случайного значения, а позволяет продолжить работу с текущим значением.
Во-вторых, таймер задержки отчета никогда не устанавливается для членства хоста в группе всех хостов (224.0.0.1), и это членство никогда не сообщается.
Если хост использует генератор псевдослучайных чисел для вычисления задержек отчетов, одно из
собственный индивидуальный IP-адрес хоста должен использоваться как часть начального числа для генератора,
чтобы уменьшить вероятность того, что несколько хостов будут генерировать одну и ту же последовательность задержек.
Хост должен подтвердить, что полученный отчет имеет тот же IP-адрес группы хостов в своем
Поле назначения IP и поле его группового адреса IGMP, чтобы гарантировать, что собственный отчет хоста не будет отменен ошибочно полученным отчетом.
Хост должен незаметно отбросить любое сообщение IGMP, отличное от типа Host Membership Query или Host Membership Report.
Маршрутизаторы
Multicast периодически отправляют запросы, чтобы обновить свои знания о членстве, присутствующем в конкретной сети.Если отчеты не получены для определенной группы после некоторого количества запросов, маршрутизаторы предполагают, что эта группа не имеет локальных членов и что
им не нужно пересылать многоадресные рассылки, отправленные удаленно для этой группы, в локальную сеть.
Запросы обычно отправляются нечасто (не чаще одного раза в минуту), чтобы снизить накладные расходы IGMP на узлы и сети.
Однако, когда многоадресный маршрутизатор запускается, он может выдать несколько близко расположенных запросов, чтобы быстро накопить знания о локальном членстве.
Когда хост присоединяется к новой группе, он должен немедленно передать отчет для этой группы,
вместо ожидания запроса, если он является первым членом этой группы в сети.
Чтобы исключить возможность потери или повреждения первоначального отчета, рекомендуется повторить его один или два раза после коротких задержек.
Простой способ сделать это — действовать так, как если бы запрос был получен только для этой группы, установив таймер задержки случайного отчета для группы.

RFC 1054, страницы 16 и 17:

ПРОБЛЕМЫ АДРЕСА ХОЗЯЙСТВЕННОЙ ГРУППЫ: Привязка адреса группы.
Связывание групповых IP-адресов хостов с физическими хостами можно рассматривать как обобщение привязки IP-адресов одноадресной рассылки.
Одноадресный IP-адрес статически привязан к одному локальному сетевому интерфейсу в одной IP-сети.
Адрес группы IP-хостов динамически привязывается к набору локальных сетевых интерфейсов в наборе IP-сетей.
Важно понимать, что адрес группы IP-узлов НЕ привязан к набору одноадресных IP-адресов.
Маршрутизаторам многоадресной рассылки не нужно вести список отдельных членов каждой группы хостов.
Например, маршрутизатор многоадресной рассылки, подключенный к сети Ethernet, должен
Свяжите только один групповой адрес Ethernet с каждой группой узлов, имеющей локальных членов, а не список индивидуальных IP-адресов или адресов Ethernet участников.
ИЗМЕНЕНИЯ ИЗ RFC-988.Расширения многоадресной IP-рассылки, указанные в этом документе, значительно отличаются от расширений, указанных в RFC-988.
Большинство изменений связано с переносом ответственности с маршрутизаторов многоадресной рассылки (так называемая многоадресная рассылка).
агентов »в RFC-988) и на хосты.
Это новое распределение ответственности согласуется с облегченной архитектурой шлюза с мягким состоянием Интернета, и это
позволяет использовать услуги многоадресной IP-рассылки (таким же образом, как и услуги одноадресной IP-рассылки) между узлами в одной сети, когда в сети нет подключенного маршрутизатора.Таким образом, текущие приложения IP-вещания для одной сети могут быть переведены на использование многоадресной IP-адресации до того, как многоадресные маршрутизаторы станут широко доступными.

RFC 1112, стр. 3:

АДРЕСА ПРИНИМАЮЩЕЙ ГРУППЫ.
Группы хостов идентифицируются IP-адресами класса D, то есть те, у которых «1110» является их четырьмя старшими битами.
IP-адреса класса E, т. Е. Те, у которых четыре старших бита «1111» зарезервированы для будущих режимов адресации.
В стандартном Интернет-формате «десятичное представление с точками» адреса групп узлов находятся в диапазоне от 224.0.0.0 до 239.255.255.255.
Адрес 224.0.0.0 гарантированно не будет назначен какой-либо группе, а адрес 224.0.0.1 назначен постоянной группе всех IP-хостов (включая шлюзы).
Это используется для адресации всех хостов многоадресной рассылки в напрямую подключенной сети.
Нет многоадресного адреса (или любого другого IP-адреса) для всех хостов в Интернете.
Адреса других известных постоянных групп будут опубликованы в «Присвоенных номерах».

RFC 1112, стр. 11:

Протокол управления группами в Интернете (IGMP (v1)) используется IP-хостами для сообщения о своем членстве в группе хостов любым соседним маршрутизаторам многоадресной рассылки.
IGMP — это асимметричный протокол, который указывается здесь с точки зрения хоста, а не многоадресного маршрутизатора.
(IGMP также может использоваться симметрично или асимметрично между маршрутизаторами многоадресной рассылки.
Такое использование здесь не указано.)
Как и ICMP, IGMP является неотъемлемой частью IP.
Он должен быть реализован всеми хостами, соответствующими уровню 2 спецификации IP-многоадресной рассылки.

RFC 1112, стр. 47:

IGMP используется между хостами и шлюзами в одной сети для установления членства хостов в определенных группах многоадресной рассылки.
Шлюзы используют эту информацию в сочетании с протоколом многоадресной маршрутизации для поддержки многоадресной IP-рассылки через Интернет.
В настоящее время реализация IGMP НЕОБЯЗАТЕЛЬНА.
Без IGMP хост все еще может участвовать в многоадресной рассылке локально для своих подключенных сетей.

RFC 1122, страницы 67 и 68:

Хост ДОЛЖЕН поддерживать локальную многоадресную передачу IP во всех подключенных сетях, для которых
задано отображение IP-адресов класса D на адреса канального уровня (см. ниже).
Поддержка локальной IP-рассылки включает отправку многоадресных датаграмм, присоединение к многоадресной рассылке.
групп и получение дейтаграмм многоадресной рассылки и выход из групп многоадресной рассылки.Это подразумевает поддержку всего [RFC 1112], кроме самого протокола IGMP, который является ДОПОЛНИТЕЛЬНЫМ.
IGMP предоставляет шлюзы, способные к многоадресной маршрутизации с информацией, необходимой для поддержки многоадресной IP-рассылки в нескольких сетях.
В настоящее время шлюзы многоадресной маршрутизации находятся на экспериментальной стадии и не являются широко доступными.
Для хостов, которые не подключены к сетям со шлюзами многоадресной маршрутизации или не подключены
необходимо получать многоадресные дейтаграммы, исходящие из других сетей, протокол IGMP не служит никакой цели и, следовательно, на данный момент является необязательным.Однако остальная часть [RFC 1112] в настоящее время рекомендуется для обеспечения доступа на уровне IP к многоадресной рассылке в локальной сети.
адресация, как предпочтительная альтернатива локальной широковещательной адресации. Ожидается, что IGMP станет рекомендованным в будущем, когда шлюзы многоадресной маршрутизации станут более доступными.
Если IGMP не реализован, хост ДОЛЖЕН по-прежнему присоединяться к группе «все хосты» (224.0.0.1) при инициализации уровня IP и оставаться членом, пока уровень IP активен.
Присоединение к группе «все хосты» будет поддерживать строго локальное использование многоадресной рассылки, например, протокол обнаружения шлюза, даже если IGMP не реализован.
Сопоставление IP-адресов класса D локальным адресам в настоящее время определено для следующих типов сетей:
Ethernet / IEEE 802.3.
Любая сеть, которая поддерживает широковещательную, но не многоадресную рассылку, адресация: все IP класса D
сопоставление адресов с локальным широковещательным адресом.
Любой тип канала связи точка-точка (например, SLIP или HDLC): отображение не требуется.
Все дейтаграммы многоадресной IP-рассылки отправляются как есть внутри локального кадрирования.
Сопоставления для других типов сетей будут указаны в будущем.
Хост ДОЛЖЕН предоставлять протоколам или приложениям более высокого уровня способ определения
какая из подключенных к хосту сетей поддерживает многоадресную IP-адресацию.

RFC 1812, стр. 84:

IGMP — это протокол, используемый между хостами и многоадресными маршрутизаторами в одном
физическая сеть для установления членства хостов в определенных группах многоадресной рассылки.Маршрутизаторы многоадресной рассылки используют эту информацию в сочетании с протоколом многоадресной маршрутизации для поддержки многоадресной IP-пересылки через Интернет.
Маршрутизатору СЛЕДУЕТ реализовать часть IGMP, относящуюся к многоадресному маршрутизатору.

MAC-заголовок

IP-заголовок

Пакет IGMP

IGMP версия 1, формат пакета:

00	01	02	03	04	05	06	07	08	09	10	11	12	13	14	15	16	17	18	19	20	21	22	23	24	25	26	27	28	29	30	31
Версия				Тип				Не используется								Контрольная сумма IGMP
Групповой адрес

Версия.
4 бита.
Установите 1.

Тип. 4 бита.

Тип	Описание
1	Запрос на членство в хосте.
2	Отчет о членстве в хосте.
3	DVMRP.

Не используется.
8 бит.
Сбрасывается в ноль при отправке пакета IGMP и игнорируется при получении.

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

Адрес группы.
32 бита.
В сообщении Host Membership Query поле адреса группы обнуляется при отправке и игнорируется при получении.
В сообщении отчета о членстве в хосте поле адреса группы содержит IP-адрес группы хостов группы, о которой сообщается.

IGMP, версия 2.

RFC 2236, страницы 1 и 2:

IGMPv2 позволяет быстро сообщать маршрутизатору о прекращении членства в группе.
протокол, который важен для групп многоадресной рассылки с высокой пропускной способностью и / или подсетей с очень изменчивым членством в группах.
Как и ICMP, IGMP является неотъемлемой частью IP.
Это должно быть реализовано всеми хостами, желающими принимать многоадресные IP-адреса.
Все сообщения IGMP, описанные в этом документе, отправляются с IP TTL 1 и содержат опцию IP Router Alert в своем IP-заголовке.

RFC 2113, стр. 2:

Опция Router Alert имеет семантику «маршрутизаторам следует более внимательно изучить этот пакет».
Включив опцию Router Alert в IP-заголовок своего протокольного сообщения, RSVP (Resource ReSerVation Protocol) может вызвать сообщение
быть перехваченным, в то же время вызывая незначительное ухудшение производительности при пересылке обычных пакетов данных или не вызывая его вовсе.

RFC 2236, страницы 4 и 5:

Маршрутизаторы
Multicast используют IGMP (v2), чтобы узнать, какие группы имеют участников в каждой из подключенных к ним физических сетей.
Маршрутизатор многоадресной рассылки хранит список членства в группах многоадресной рассылки для каждой подключенной сети и таймер для каждого членства.
«Членство в группе многоадресной рассылки» означает присутствие по крайней мере одного члена группы многоадресной рассылки в данной присоединенной сети, а не список всех членов.
Когда хост получает общий запрос, он устанавливает таймеры задержки для каждой группы (за исключением группы всех систем), членом которой он является, на интерфейсе, от которого он получил запрос.
Когда маршрутизатор получает отчет, он добавляет группу, о которой сообщается, в список
членство в группах многоадресной рассылки в сети, в которой он получил отчет, и устанавливает таймер для членства на [Интервал членства в группе].
Когда хост присоединяется к группе многоадресной рассылки, он должен немедленно передать незапрашиваемый отчет о членстве версии 2 для этой группы, если он является первым членом этой группы в сети
Когда узел покидает группу многоадресной рассылки, если он был последним узлом, ответившим на запрос с отчетом о членстве для этой группы, он ДОЛЖЕН отправить сообщение о выходе из группы многоадресной группе всех маршрутизаторов (224.0.0.2).

MAC-заголовок

IP-заголовок

Пакет IGMP

IGMP версия 2, формат пакета:

00	01	02	03	04	05	06	07	08	09	10	11	12	13	14	15	16	17	18	19	20	21	22	23	24	25	26	27	28	29	30	31
Тип								Максимальное время отклика								Контрольная сумма IGMP
Групповой адрес

Тип.
8 бит.

Тип	Описание
0x0 — 0x10
0x11	Запрос о членстве в группе, общий или групповой. Общий запрос используется, чтобы узнать, какие группы имеют участников в присоединенной сети. Групповой запрос используется, чтобы узнать, есть ли у конкретной группы какие-либо участники в присоединенной сети. Эти два сообщения различаются групповым адресом.
0x12	Отчет о членстве IGMPv1.
0x13	DVMRP.
0x14	PIMv1.
0x15	Сообщения трассировки Cisco.
0x16	Отчет о членстве IGMPv2.
0x17	IGMPv2 Покинуть группу.

0x1E	Multicast Traceroute Response.
0x1F	Multicast Traceroute.

0x22	Отчет о членстве IGMPv3.

0x30	MRD, Объявление многоадресного маршрутизатора.
0x31	MRD, запрос многоадресного маршрутизатора.
0x32	MRD, Завершение многоадресного маршрутизатора.
0xF0 — 0xFF	Экспериментально.

Максимальное время отклика.
8 бит.
Поле «Максимальное время ответа» используется только в сообщениях с запросом о членстве.
Он указывает максимально допустимое время перед отправкой ответного отчета с шагом 1/10 секунды.
Во всех остальных сообщениях отправитель устанавливает нулевое значение, а получатели игнорирует его.

Изменение этого параметра позволяет маршрутизаторам IGMPv2 настраивать «задержку выхода» (
время между моментом, когда последний хост покидает группу, и когда протокол маршрутизации получает уведомление об отсутствии других участников).Это также позволяет настраивать пакетность трафика IGMP в подсети.

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

Адрес группы.
32 бита.
В сообщении с запросом о членстве это поле устанавливается в ноль при отправке
General Query и задайте групповой адрес, который запрашивается при отправке Group-Specific Query.
В отчете о членстве или сообщении о выходе из группы это поле содержит групповой IP-адрес группы, о которой сообщается или остается.

Глоссарий:

RFC:

[RFC 1112]
Расширения хоста для многоадресной IP-рассылки.

[RFC 1122]
Требования к Интернет-хостам — Уровни связи.

[RFC 1812]
Требования к маршрутизаторам IP версии 4.

[RFC 2113]
Опция оповещения IP-маршрутизатора.

Категория: Дорожка стандартов.
Определяет IP-параметр 20 (Предупреждение маршрутизатора).

[RFC 2715]
Правила взаимодействия для протоколов многоадресной маршрутизации.

[RFC 2933]
Протокол управления группами Интернета MIB.

Категория: Дорожка стандартов.
Определяет SNMP MIB iso.org.dod.internet.mgmt.mib-2.igmpStdMIB (1.3.6.1.2.1.85).

[RFC 3228]
Соображения IANA по протоколу IPv4 Internet Group Management Protocol (IGMP).

[RFC 3376]
Протокол управления группами Интернет, версия 3.

Категория: Дорожка стандартов.
Определяет версию IGMP 3.
Устарело:
RFC 2236.

[RFC 4286]
Обнаружение многоадресного маршрутизатора.

Категория: Дорожка стандартов.
Определяет ICMPv6 сообщения 151 (объявление многоадресного маршрутизатора), 152 (запрос многоадресного маршрутизатора) и 153 (завершение многоадресного маршрутизатора).
Определяет сообщения IGMP 0x30 (объявление многоадресного маршрутизатора), 0x31 (запрос многоадресного маршрутизатора) и 0x32 (завершение многоадресного маршрутизатора).
Определяет адреса многоадресной рассылки 224.0.0.106 (All-Snoopers) и FF02: 0: 0: 0: 0: 0: 0: 6A (All-Snoopers).

[RFC 4541]
Соображения по протоколу управления группами Интернета (IGMP) и переключателям отслеживания многоадресного прослушивания (MLD).

[RFC 6636]
Настройка поведения протокола управления группами Интернета (IGMP) и обнаружения многоадресного прослушивателя (MLD) для маршрутизаторов в мобильных и беспроводных сетях.

Публикации:

Устаревшие RFC:

[RFC 966]
Группы узлов: расширение многоадресной рассылки для Интернет-протокола.

Июль 2024
Пн	Вт	Ср	Чт	Пт	Сб	Вс
1	2	3	4	5	6	7
8	9	10	11	12	13	14
15	16	17	18	19	20	21
22	23	24	25	26	27	28
29	30	31

Включить igmp что это: что это в роутере и как включить?

что это в роутере и как включить?

Реализация

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

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

что это в роутере и как его включить

Что такое IGMP и зачем он нужен

Виды IGMP snooping

Как настроить функцию в роутере

Возможные проблемы

Сети для самых маленьких.<img src='/800/600/http/serv.sys-s.ru/wp-content/uploads/screenshot-2020-03-11-001.png' /> Часть девятая. Мультикаст / Хабр

Пример I

Пример II

Querier

Ещё пара слов о других версиях IGMP

Повторим ещё раз

И ещё раз

PIM Dense Mode

Сети для самых маленьких. Часть 9.4. Мультикаст. Мультикаст на канальном уровне

Содержание серии статей про мультикаст

Мультикаст на канальном уровне

IGMP Snooping

Задача № 3

IGMP Snooping Proxy

Multicast VLAN Replication

Задача 4

Теги

Сети для самых маленьких. Часть 9.1. Мультикаст. Общее понимание Multicast

Содержание серии статей про мультикаст

Общее понимание Multicast

Пример 1

Пример 2

Теги

Базовое включение IGMP-snooping на коммутаторах QTech

Source Specific Multicast (SSM) и фильтрация IGMP — Daniels Networking Blog

Страница не найдена

Моя библиотека «»

×

×Настройки файлов cookie

Настройка сети Ubiquiti для использования с mDNS и многоадресной рассылкой

IGMP, Internet Group Management Protocol

Добавить комментарий Отменить ответ

Сети для самых маленьких. Часть девятая. Мультикаст / Хабр

Моя библиотека
«»

×
Настройки файлов cookie

Настройка сети Ubiquiti
для использования с mDNS и многоадресной рассылкой