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

IGMP snooping что это в роутере и зачем нужна такая настройка? IGMP — процесс отслеживания сетевого трафика, который является одним из протоколов на канальном уровне.

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

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

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

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

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

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

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

Виды IGMP snooping

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

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

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

Разберу 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 в роутере. Надеюсь, данная информация будет вам полезна, и вы решите возникшие проблемы. Теперь ваши данные будут передаваться максимально оптимально и корректно, а атака на сеть с целью перегрузить все устройства в ней не принесёт результата.

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

Что такое и зачем нужна функция IGMP snooping

Для начала дадим определение IGMP, чтобы понять принцип работы технологии. Internet Group Management Protocol – протокол управления сетью мультивещания, который организует несколько устройств в группы. Он основан на протоколе IP и применяется в интернете повсеместно, эффективно используя ресурсы сети.

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

Таким образом snooping исключает передачу пользователю ненужных данных через multicast каналы. Это делает обмен данными на канальном уровне сети более эффективным и учитывает потребности сетевого уровня, что в особенности важно для поставщиков информации. Пользователи также получат оптимизированный контент, хотя в итоге нагрузка на сеть возрастёт.

Без отслеживания и анализа данных, конечные потребители в виде конкретных IP-адресов, будут вынуждены «переваривать» дополнительную бесполезную для них информацию. IGMP snooping не только избавит пользователей от лишнего трафика, но и сделает обмен информацией более безопасным. Включенный режим отслеживания вовремя пресечёт попытки DDoS-атаки на сеть или конкретные адреса, к которым уязвим протокол Internet Group Management.

Активация функции IGMP snooping

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

Перед использованием коммуникатора в вашей сети убедитесь, что конечный получатель (например, smart-tv) поддерживает режим snooping. Обычно устройства имеют соответствующий пункт в разделе «Настройка сетевого подключения», что заметно упрощает регулировку мультивещания.

Рассмотрим способ подключения функции через командную строку на примере популярных коммутаторов D-Link:

1. Откройте командную строку устройства с помощью CLI-интерфейса.
2. Введите «enable-igmp-snooping». Эта команда включит функцию на коммутаторе и всех подключенных адресах.
3. Введите «config-igmp-snooping-vlan-default-state-enable», что позволит настроить протокол в VLAN.
4. Команда «confog-multicast-vlan-filtering-mode-vlan-default-filter-unregistred-groups» включает на коммуникаторе фильтрацию данных с нескольких адресов сразу.
5. В завершение используйте «config-igmp-snooping-vlan-default-fast-leave-enable» в сети VLAN.

Последняя команда включает функцию IGMP Snooping Fast Leave, которая исключает порт из сети, как только пользователь сделал запрос «leave». Благодаря Fast Leave, потребитель не получит ненужные данные и не будет их обрабатывать. Это уменьшит нагрузку на сеть и позволит коммутатору работать более эффективно.

Виды IGMP snooping

Прослушка и анализ данных делится на два вида:

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

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

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

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

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

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

1. Устройство, когда решает получать multicast-трафик, отправляет свой запрос в сообщении IGMP Membership Report (далее IGMP Report). В нём указывается, что именно устройство желает получать. Адрес запрашиваемой multicast-группы указывается в качестве IP-адреса назначения. Данное сообщение в первую очередь предназначается ближайшему маршрутизатору. Ведь именно он отвечает за передачу трафика между локальным сегментом и остальной сетью.
2. Получив такое сообщение, маршрутизатор начинает транслировать в данный сегмент сети, запрашиваемый multicast-трафик. Конечно, это происходит при условии, что маршрутизатор сам участвует в передаче multicast-трафика и получает нужный трафик.
3. Чтобы быть уверенным, что в сети всё ещё есть получатели multicast-трафика, маршрутизатор периодически рассылает сообщение IGMP General Membership Query (далее IGMP General Query). Ведь если никого уже нет, зачем попусту «засорять» данный сегмент сети никому не нужным трафиком.
4. В ответ на IGMP General Query маршрутизатор получает сообщение IGMP Report. Обычно его отправляет один из получателей multicast-трафика. Остальные услышав это сообщение, просто молчат, так как одного подтверждения для каждой группы достаточно. Выбор того, кто будет отвечать маршрутизатору, реализуется через механизм Report Suppression.

   Report Suppression

   Если у нас в сети много получателей multicast-трафика, их ответы на IGMP General Query могут породить достаточно большое количество сообщений IGMP Report. Так как маршрутизатору достаточно получить всего одно такое сообщение, используется следующий механизм оптимизации. В сообщении IGMP General Query указывается максимальное время (Maximum Response Time — MRT), в течении которого маршрутизатор ждёт ответа. Клиент, получив IGMP General Query, выбирает произвольное значение таймера от 0 до MRT. Как только выбранное время таймера истекает, клиент отправляет сообщение IGMP Report. Это происходит только в том случае, если до этого клиент не получил IGMP Report от какого-то другого получателя.

5. Когда устройство больше не желает получать multicast-трафик для определённой группы, оно шлёт сообщение IGMP Leave.
6. На это маршрутизатор отвечает сообщением IGMP Membership Group-Specific Query (далее IGMP Group-Specific Query), уточняя, есть ли ещё в сети устройства, желающие получать трафик для данной группы. Обычно этих сообщений маршрутизатор отправляет два. Если такие устройства в сети есть, они откликнутся. Если нет, маршрутизатор прекратит трансляцию трафика в локальный сегмент сети.

Более подробно о работе протокола IGMP, да и в целом о multicast-трафике можно почитать, например, в цикле статей сети для самых маленьких.

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

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

1. Первое, что делает коммутатор, определяет, где находится маршрутизатор(ы). Для этого он слушает наличие в сети сообщений IGMP General Query, PIM, DVMRP и пр.
2. Устройство отправляет IGMP Report, когда хочет получать тот или иной multicast-трафик. Данное сообщение перехватывает коммутатор. Из него коммутатор получает следующую информацию: устройство с таким-то MAC-адресом, находящееся за определённым портом, хочет получать трафик такой-то multicast группы. Причём для коммутатора при идентификации multicast группы в первую очередь важен не IP-адрес этой группы (IP-адреса multicast групп лежат в диапазоне 224.0.0.0 – 239.255.255.255), а её MAC-адрес. Коммутатору проще работать именно с адресацией на канальном уровне. Как мы знаем, MAC-адрес формируется по определённому правилу из IP адреса multicast группы. Вся эта информация заносится в таблицу MAC-адресов коммутатора.

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

3. Маршрутизатор, получив сообщение IGMP Report, начинает передавать multicast-трафик. Но так как коммутатор знает, где находится устройство, желающее его получать, он ретранслирует трафик только на определённый порт. Теперь в таблице MAC-адресов есть запись с MAC-адресом multicast-группы, которая смотрит на конкретный порт.
4. Периодически маршрутизатор отправляет в сеть IGMP General Query. Коммутатор рассылает его через все порты.
5. Получив IGMP General Query, устройство отвечает сообщением IGMP Report. Коммутатор перехватывает его и отправляет только в сторону маршрутизатора. Остальные получатели multicast-трафика данное сообщение не получают. А, значит, отвечают своими IGMP Report. Таким образом работа механизма Report Suppression нарушается. Это необходимо для идентификации всех получателей multicast-трафика. Иначе клиент, услышав IGMP Report от другого, решит, что ему отвечать не нужно, и коммутатор не узнает о его присутствии. Получив от всех IGMP Report, коммутатор обновляет свои записи. В сторону маршрутизатора все сообщения IGMP Report отсылать смысла нет, поэтому отправлется только одно — самое первое.
6. Если устройство решает прекратить получать трафик для определённой multicast-группы, оно отправляет сообщение IGMP Leave. Коммутатор, как обычно, перехватывает его.
7. Во-первых, коммутатор проверят, нет ли за этим же портом (откуда пришло сообщение IGMP Leave) других получателей multicast-трафика. Ведь в этот порт может быть подключен другой коммутатор. Для этого он отправляет сообщение IGMP Group-Specific Query. Если ответа на него не последовало, коммутатор просто убирает закрепление MAC-адреса multicast-группы за данным портом. Если ответ пришёл, продолжает передавать трафик через данный порт.
8. Далее коммутатор проверяет, а есть ли на нём другие получатели multicast-трафика для данной группы, но находящиеся за другими портами. Для этого он просто смотрит в свою таблицу MAC-адресов.
   • Если такие получатели есть, больше коммутатор ничего не делает. Посылать сообщение IGMP Leave в сторону маршрутизатора смысла никакого нет.
   • Если это был последний получатель для данной multicast-группы, коммутатор отправляет сообщение IGMP Leave в сторону маршрутизатора.
9. Получив сообщение IGMP Leave, маршрутизатор рассылает сообщения IGMP Group-Specific Query, которые коммутатор в свою очередь рассылает через все свои порты. Конечно же, никто не откликается и маршрутизатор перестаёт передавать трафик для данной группы.

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

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

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

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

cbs-sw-2960x#conf t
cbs-sw-2960x(config)#no ip igmp snooping 
cbs-sw-2960x(config)#exit
cbs-sw-2960x#
cbs-sw-2960x#sh ip igmp snooping 
Global IGMP Snooping configuration:
-------------------------------------------
IGMP snooping                : Disabled

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

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

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

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

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

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

cbs-rtr-4000#sh ip mroute 
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
       L - Local, P - Pruned, R - RP-bit set, F - Register flag,
       T - SPT-bit set, J - Join SPT, M - MSDP created entry, E - Extranet,
       X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,
       U - URD, I - Received Source Specific Host Report, 
       Z - Multicast Tunnel, z - MDT-data group sender, 
       Y - Joined MDT-data group, y - Sending to MDT-data group, 
       G - Received BGP C-Mroute, g - Sent BGP C-Mroute, 
       N - Received BGP Shared-Tree Prune, n - BGP C-Mroute suppressed, 
       Q - Received BGP S-A Route, q - Sent BGP S-A Route, 
       V - RD & Vector, v - Vector, p - PIM Joins on route, 
       x - VxLAN group
Outgoing interface flags: H - Hardware switched, A - Assert winner, p - PIM Join
 Timers: Uptime/Expires
 Interface state: Interface, Next-Hop or VCD, State/Mode

(*, 230.255.0.1), 00:29:20/stopped, RP 0.0.0.0, flags: DC
  Incoming interface: Null, RPF nbr 0.0.0.0
  Outgoing interface list:
    GigabitEthernet0/0/1.115, Forward/Dense, 00:29:20/stopped

(172.17.16.11, 230.255.0.1), 00:03:27/00:02:32, flags: T
  Incoming interface: GigabitEthernet0/0/1.116, RPF nbr 0.0.0.0
  Outgoing interface list:
    GigabitEthernet0/0/1.115, Forward/Dense, 00:03:27/stopped

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

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

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

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

2. Периодически (каждые 60 секунд) маршрутизатор рассылает сообщение IGMP General Query.
3. Наш компьютер откликается на данное сообщение, отправляя в обратную сторону IGMP Report для группы 230.255.0.1.
4. Наживаем кнопку «Остановить» в проигрывателе VLC и наш компьютер отправляет сообщение IGMP Leave, о том, что он больше не хочет получать multicast-трафик для группы 230.255.0.1.
5. Маршрутизатор в ответ на IGMP Leave отправляет сообщение IGMP Group-Specific Query для 230.255.0.1. Он хочет понять, есть ли в данном сегменте сети, другие получатели. Ровно через 1 секунду маршрутизатор отправляет повторное сообщение IGMP Group-Specific Query. И ещё через 1 секунду, не получив в ответ ни одного IGMP Report, прекращает передавать multicast-трафик в данный сегмент сети.
6. Периодически маршрутизатор продолжает рассылать сообщение IGMP General Query. Но так как наш компьютер больше не заинтересован в получении чего-либо, он ничего на это не отвечает.

Так как на коммутаторе у нас выключен IGMP snooping, весь multicast-трафик рассылается (флудится) по всем портам в нашем VLAN’е, пока там есть хотя бы один получатель. Когда получателей больше не будет, маршрутизатор тут же прекратит передачу трафика в данный сегмент сети.

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

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

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

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

cbs-sw-2960x(config)#ip igmp snooping 
cbs-sw-2960x(config)#exit
cbs-sw-2960x#
cbs-sw-2960x#sh ip igmp snooping 
Global IGMP Snooping configuration:
-------------------------------------------
IGMP snooping                : Enabled

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

cbs-sw-2960x#sh ip igmp snooping mrouter 
Vlan    ports
----    -----
 115    Gi1/0/19(dynamic)

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

Sep 17:39:39 MSK: IGMPSN: router: PIMV2 Hello packet received in 115
Sep 17:39:39 MSK: IGMPSN: router: Is not a router port on Vlan 115, port Gi1/0/19
Sep 17:39:39 MSK: IGMPSN: router: Is not a router port on Vlan 115, port Gi1/0/19
Sep 17:39:39 MSK: IGMPQR: vlan_id 115: querier/multicast router detected on port Gi1/0/19 in Disabled state
Sep 17:39:39 MSK: IGMPSN: router: Created router port on Vlan 115, port Gi1/0/19
Sep 17:39:39 MSK: IGMPSN: mgt: Reverting flood mode to only multicast router ports for Vlan 115.
Sep 17:39:39 MSK: IGMPSN: Adding router port Gi1/0/19 to all GCEs in Vlan 115
Sep 17:39:39 MSK: IGMPSN: added rport Gi1/0/19 on Vlan 115
Sep 17:39:39 MSK: IGMPSN: router: Learning port: Gi1/0/19 as rport on Vlan 115

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

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

(*, 230.255.0.1), 00:00:12/stopped, RP 0.0.0.0, flags: DP
  Incoming interface: Null, RPF nbr 0.0.0.0
  Outgoing interface list: Null

(172.17.16.11, 230.255.0.1), 00:00:12/00:02:47, flags: PT
  Incoming interface: GigabitEthernet0/0/1.116, RPF nbr 0.0.0.0
  Outgoing interface list: Null

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1. Сообщение IGMP Group-Specific Query, которое отправил маршрутизатор, когда в сети больше не осталось ни одного получателя multicast-трафика.
2. Сообщение IGMP General Query, которое периодически рассылает маршрутизатор.

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

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

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

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

cbs-sw-2960x#sh ip igmp snooping groups
Vlan      Group                    Type        Version     Port List
-----------------------------------------------------------------------
115       230.255.0.1              igmp        v2          Gi1/0/14, Gi1/0/15, 
                                                           Gi1/0/19

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

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

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

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

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

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

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

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

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

cbs-sw-2960x#sh ip igmp snooping groups 
cbs-sw-2960x#

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

Sep 13:54:01 MSK: IGMPSN: Received IGMPv3 Report for group v3 received on Vlan 115, port Gi1/0/15
Sep 13:54:01 MSK: IGMPSN: Rx IGMPv3 Report on Gi1/0/15 when Querier is not IGMPv3, Vlan 115.

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

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

Sep 15:07:08 MSK: IGMPSN: Received IGMPv2 Report for group 230.255.0.1 received on Vlan 115, port Gi1/0/15
Sep 15:07:08 MSK: IGMPSN: group: Received IGMPv2 report for group 230.255.0.1 received on Vlan 115, port Gi1/0/15
Sep 15:07:08 MSK: IGMPSN: router: Is not a router port on Vlan 115, port Gi1/0/15
Sep 15:07:08 MSK: IGMPSN: group: Skip client info adding - ip 172.17.15.11, port_id Gi1/0/17, on vlan 115
Sep 15:07:08 MSK: IGMPSN: No mroute detected: Drop IGMPv2 report for group 230.255.0.1 received on Vlan 115, port Gi1/0/15

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

обязательно нужно знать, где находится маршрутизатор multicast-трафика

. Порт на коммутаторе, куда будет подключен такой маршрутизатор, как раз и получает название mrouter-порт (multicast router port). Без mrouter-порта IGMP snooping работать нормально не будет. А у нас такого порта нет, так как мы отключили на маршрутизаторе IGMP.

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

cbs-sw-2960x#sh ip igmp snooping mrouter 
Vlan    ports
----    -----
 115    Gi1/0/19(dynamic)

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

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

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

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

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

• На маршрутизатор, как и ожидалось, постоянно поступает multicast-трафик.
• Маршрутизатор продолжает отрабатывать логику работы IGMP для группы 230.255.0.1. На сообщение IGMP Leave, он отсылает сообщения IGMP Specific-Group Query.
• Но в отличии от предыдущего случая, когда маршрутизатор выясняет, что больше нет получателей для группы 230.255.0.1, маршрутизатор не может прекратить передавать multicast-трафик. Его инициатором в данном сегменте сети является совсем другое устройство (это хост с адресом 172.17.15.12).

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

cbs-sw-2960x#sh ip igmp snooping mrouter 
Vlan    ports
----    -----
115    Switch

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

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

Подытожу

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

1. Коммутатор с включённым IGMP snooping (а он, как мы помним, включён по умолчанию) передаёт multicast-трафик, сгенерированный в данном сегменте сети, как широковещательный. При этом не важно есть или нету у нас хотя бы один получатель.
2. Коммутатор перехватывает и удаляет все сообщения IGMP Report.

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

IGMP snooping и 224.0.0.X

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

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

Sep 17:27:36 MSK: IGMPSN: Received IGMPv2 Report for group 224.0.0.251 received on Vlan 115, port Gi1/0/15
Sep 17:27:36 MSK: IGMPSN: 224.0.0.251 is a Reserved MCAST address
Sep 17:27:36 MSK: IGMPSN: group: Received IGMPv2 report for group 224.0.0.251 received on Vlan 115, port Gi1/0/15 with invalid group address

Sep 17:27:37 MSK: IGMPSN: Received IGMPv2 Report for group 224.0.0.252 received on Vlan 115, port Gi1/0/15
Sep 17:27:37 MSK: IGMPSN: 224.0.0.252 is a Reserved MCAST address
Sep 17:27:37 MSK: IGMPSN: group: Received IGMPv2 report for group 224.0.0.252 received on Vlan 115, port Gi1/0/15 with invalid group address

В заключение

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

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

IGMP Snooping – это технология, которая позволяет роутеру оптимизировать передачу мультимедийных данных в сети. Она работает на уровне сетевого устройства и используется для эффективной передачи многоадресных пакетов.IGMP Snooping позволяет роутеру отслеживать информацию о группах многоадресной рассылки в сети и отправлять пакеты только на необходимые порты. Это позволяет снизить нагрузку на сеть и улучшить ее производительность.Технология IGMP Snooping работает на основе протокола IGMP (Internet Group Management Protocol). Он используется для управления многоадресной рассылкой в IP-сетях. Когда устройство присоединяется к группе многоадресной рассылки, оно отправляет сообщение IGMP-запроса на роутер. Роутер записывает информацию о группах многоадресной рассылки и отправляет пакеты только на те порты, где находятся устройства, присоединенные к этой группе.Использование технологии IGMP Snooping позволяет снизить нагрузку на сеть и улучшить производительность. Кроме того, она обеспечивает безопасность сети, так как предотвращает передачу многоадресных пакетов на несанкционированные порты.В следующей части статьи мы рассмотрим более подробно, как работает технология IGMP Snooping в роутере и как ее настроить.

Роль IGMP Snooping в сети

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

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

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

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

Как настроить IGMP Snooping на роутере

IGMP Snooping – это технология, которая позволяет оптимизировать работу мультикастовых приложений в сети. Если в вашей сети есть мультикастовые приложения (например, IPTV), то настройка IGMP Snooping на роутере поможет избежать ненужного трафика и улучшить производительность сети.

Для настройки IGMP Snooping на роутере необходимо выполнить следующие шаги:

1. Войдите в интерфейс управления роутером.

2. Найдите раздел «IGMP Snooping» или «Multicast».

3. Включите опцию «IGMP Snooping».

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

5. Сохраните изменения и перезагрузите роутер.

Готово! Вы успешно настроили IGMP Snooping на своем роутере и теперь можете наслаждаться более эффективной работой мультикастовых приложений в сети.

Преимущества использования IGMP Snooping

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

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

Кроме того, IGMP Snooping позволяет улучшить качество обслуживания (QoS) в сети. Роутер может определить, какие приложения или устройства наиболее важны для пользователя, и обеспечить им приоритетный доступ к сети. Это позволяет увеличить скорость работы приложений и улучшить пользовательский опыт.

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

Примеры проблем, которые решает IGMP Snooping:

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

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

3. Еще один пример проблемы, которую решает IGMP Snooping, это проблема совместимости с устройствами, которые не поддерживают протокол IGMP. Некоторые устройства могут отправлять запросы на групповые адреса без уведомления роутера. IGMP Snooping позволяет определить, какие устройства отправляют запросы на групповые адреса, и передавать трафик только тем, кто его запрашивает.

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