Включить igmp snooping asus что это

[Беспроводное устройство] Как настроить IPTV?

Отсканируйте QR-код, чтобы открыть эту страницу на вашем смартфоне.

[Беспроводное устройство] Как настроить IPTV?

Примечание: для просмотра IPTV порт WAN должен быть подключен к сети Интернет. Пожалуйста, перейдите по ссылке Dual WAN , чтобы подтвердить, что порт WAN назначен как основной WAN.

Примечание: Настройки IPtv зависят также от требований провайдера IPTV. Мы рекомендуем проверить с провайдером сервисов IPTV есть ли возможность использования через Wi-Fi и требуются ли какие-либо дополнительные настройки.

Где найти IPTV в интерфейсе роутера GUI?

• Перейдите во вкладку [LAN] >> [IPTV]

Как настроить IPTV?

Шаг1. Подключите свой компьютер к маршрутизатору через проводное или Wi-Fi соединение и введите http://www.asusrouter.com для доступа на страницу настроек роутера GUI.

Шаг2. Введите имя и пароль пользователя для доступа на страницу роутера.

Примечание: Если Вы забыли имя пользователя и/или пароль, пожалуйста, восстановите заводские настройки маршрутизатора по умолчанию.

Шаг3: Проверьте [Использование DHCP]

Выберите, какие маршруты DHCP Вы используете. [Disable/Microsoft/RFC3442/RFC3442 &Microsoft ]

Шаг4: Проверьте, хотите ли Вы включить многоадресную маршрутизацию (IGMP Proxy) или нет. Включение этой функции позволяет беспроводному маршрутизатору обрабатывать многоадресные пакеты.

Включение многоадресного маршрутизатора также включает функции RTP (транспортный протокол реального времени) и RTSP (протокол потоковой передачи в реальном времени).

Версия IGMP по умолчанию: [IGMP v3], другие варианты: [IGMP v1], [IGMP v2]

Enable Fast Leave: Отключено (По умолчанию)

Шаг5: Настройте UDP-прокси (Udpxy). Используйте эту функцию для запуска приложения IPTV (например, VLC) на нескольких компьютерах одновременно. Эта функция может преобразовывать многоадресные потоки UDP в одноадресные потоки HTTP.

Введите порт (например, 4000) , который Вы хотите назначить для приложения IPTV, затем используйте этот формат, чтобы ввести адрес в список воспроизведения для просмотра потоков IPTV: http: // [IP-адрес маршрутизатора]: [Порт Udpxy] / [ протокол] / [IP-адрес канала]: [порт канала] (например, http://192.168.1.1:4000/udp/239.255.1.1:5000 или http://192.168.1.1:4000/rtp/239.255.1.1: 5000).

Введите ноль (0) для отключения функции.

Шаг6. Проверьте, хотите ли Вы включить многоадресную маршрутизацию (IGMP Proxy) или нет. Включение этой функции позволяет беспроводному маршрутизатору обрабатывать многоадресные пакеты. Включение маршрутизации многоадресной рассылки также включает функции RTP (транспортный протокол реального времени) и RTSP (протокол потоковой передачи в реальном времени).

Версия IGMP по умолчанию: [IGMP v3], другое выберите [IGMP v1], [IGMP v2]

Включить быстрый отпуск: Отключить (по умолчанию)

Примечание: Пожалуйста, проверьте, что Включить IGMP Snooping включено.

Откройте Беспроводная сеть > Профессионально > выберите диапазон (2.4GHz/5GHz) > Включить IGMP Snooping > щелкните Применить для сохранения.

FAQ

1. Можно ли использовать больше IPTV на роутере? Я хочу использовать IPTV в нескольких LAN портах.

• Роутеры не поддерживают использование нескольких IPTV через 1 порт LAN.
• Функция IPTV, которую предоставляет роутер, поддерживает только 1 IPTV.

2. Могу я использовать сервисы IPTV через Wi-Fi сеть?

• В основном, большинство IPTV STB (Set-up-box) нуждаются в подключении кабеля для стабильного iptv подключения, поэтому в приоритете будет настройка по кабелю.
• Настройки IPtv зависят также от требований провайдера IPTV. Мы рекомендуем проверить с провайдером сервисов IPTV есть ли возможность использования через Wi-Fi и требуются ли какие-либо дополнительные настройки.

Как скачать (Утилиты / ПО)?

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

Настройка IPTV на роутере ASUS по Wi-Fi, кабелю и через приставку

Если ваш интернет-провайдер предоставляет услугу IPTV, то для просмотра интерактивного телевидения нужно настроить роутер. В этой статье мы рассмотри настройку IPTV на роутере Asus.

Смотреть IPTV через роутер можно несколькими способами:

• Через специальную приставку.
• На компьютере, при подключении к роутеру по сетевому кабелю.
• И еще можно настроить воспроизведение IPTV на ноутбуке, планшете, Smart TV и т. д., при подключении по Wi-Fi сети.

Сейчас мы рассмотрим подробнее эти настройку на примере роутеров Asus.

Что касается просмотра интерактивного телевидения через STB-приставку, то здесь все просто. Задаем в настройках роутера номер LAN порта, к которому подключена приставка, и все готово. Ну а для просмотра телевидения на компьютере по кабелю, или в случае раздачи IPTV по Wi-Fi, на компьютере (или другом устройстве) нужно будет использовать специальный плеер. Самые популярные, это PC Player и IPTV Player.

Хотелось бы отдельно написать о поддержке IPTV роутерами Asus. Поддержка есть практически на всех моделях. Но, не нужно забывать, что просмотр интерактивного телевидения особенно по Wi-Fi сети создает большую нагрузку на роутер. Так же может падать скорость подключения к интернету. Поэтому, если вы планируете пропускать IPTV через роутер, то на роутере лучше всего не экономить. Я покажу на примере настройки модели Asus RT-N18U, и более старого RT-N13U (у него другая прошивка на вид, голубая) . Эта инструкция подойдет практически для всех маршрутизаторов этой компании: RT-N66U, RT-N12, RT-N14U, RT-N10 и т. д.

IPTV через роутер Asus с использованием приставки

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

Если у вас роутер с новой прошивкой, темной, то перейдите на вкладку Локальная сеть – IPTV. В выпадающем меню Выбор порта IPTV STB выберите номер одного или двух LAN портов, к которому будет подключена приставка. Если вы выберите два порта, то можно будет подключить две приставки. Нажмите на кнопку Применить для сохранения настроек.

Если у вас роутер с более старой, голубой прошивкой, то в панели управления откройте вкладку WAN, и в меню «Выбор порта IPTV STB» укажите нужный порт. Нажмите на кнопку Применить.

Это все настройки, которые нужно задать на маршрутизаторе Asus для работы IPTV через приставку. Мы просто включили режим поста между LAN и WAN портом.

Просмотр IPTV по Wi-Fi и LAN кабелю через роутер Asus

Эти настройки вам пригодятся в том случае, когда вы планируете смотреть интерактивное телевидение на своем компьютере, или ноутбуке при подключении к роутеру по сетевому кабелю, или по Wi-Fi сети. Через специальный плеер, о котором я писал в начале этой статьи. Так же IPTV можно будет смотреть на смартфонах, планшетах, телевизорах со Smart TV и т. д.

Сначала рассмотрим настройку на роутерах с прошивкой ASUSWRT (которая темная) . В настройках откройте вкладку Локальная сеть – IPTV.

• Пункт «Включить многоадресную маршрутизацию (IGMP Proxy)» ставим «Включить»
• Напротив «Включить IGMP Snooping» так же выбираем «Включить». Тем самым включаем Multicast на роутере Asus
• В поле «UDP-прокси (Udpxy)» пропишите «1234».

Нажмите на кнопку Применить.

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

Если необходима трансляция IPTV по Wi-Fi сети:

Перейдите на вкладку Беспроводная сеть – Профессионально. Найдите там пункт меню «Включить IGMP Snooping» и установите «Включить«. А в меню «Скорость многоадресной передачи данных (Мбит/с)» выберите «OFDM 24«.

Нажмите на кнопку Применить для сохранения настроек.

После этих настроек телевидение по беспроводной сети должно работать стабильно.

Если у вас роутер со старой панелью управления

Для включения поддержки IGMP (Multicast) откройте вкладку ЛВС – Маршрут. Напротив пункта «Включить многоадресную маршрутизацию?» установите Да и нажмите кнопку Применить.

Для стабильной трансляции телевидения по беспроводной сети, перейдите на вкладку Беспроводная сеть – Профессионально. Напротив «Скорость многоадресной передачи данных (Мбит/с)» выбираем «24«. Не забудьте сохранить настройки кнопкой Применить.

Все, настройка закончена.

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

104
169556
Сергей
Asus

Здравствуйте. Поэтапно настраивал роутер asus rt-ac55u и после последних настроек (Беспроводная сеть – Профессионально. «Включить IGMP Snooping» и «Скорость многоадресной передачи данных (Мбит/с)» «OFDM 24».) роутер ушел в постоянную перезагрузку — сначала загорается Power, через несколько секунд начинает гореть красным WLAN, еще через несколько секунд Power начинает мигать, после чего все индикаторы загораются синим и начинается все заново. Пробовал аварийное восстановление прошивки, во время закачки/установки видно что моде реагирует на программу, после завершения модем перезагружается и происходит тоже самое. В сервисных выходные. Помогите разобраться. Спасибо.

Здравствуйте. А сброс настроек к заводским? Если не получается восстановить через программу, то вряд ли получится что-то сделать.

Нечего не помогает…. Приобрел его в начале июня, надеюсь поменяют по гарантии.
ничего* =/

Случилась точно такая же проблема — выставил OFDM 24, сохранил и роутер жёстко завис, кнопка сброса не помогла, но как ни странно, помогла кнопка WPS, удерживал её больше минуты пока не замигали все светодиоды. Роутер ожил!

Здравствуйте, решил избавиться от проводов. Поставщик IPTV — Ростелеком. Основной роутер ASUS TR-N12VP. Приобрел TP-LINK TL-WA850RE. Включил — связь с основой настроил. Воткнул LAN от приставки Ростелекома в приобретенный репитер, но приставка никак не желает показывать ТВ и просит авторизации
Ранее ростелекомовская приставка была подключена по LAN1. Если лановский кабель обратно подключить к основе LAN1 то ТВ начинает работать. Пытался сделать как написано у вас в статье, не получается! Помогите пожалуйста!

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

Проблема не в роутере-репитере, а в сути работы приставок STB. По вай фаю iptv можно попытаться настроить через связку роутер — ноут-телек (с преобразованием udp — http). Такая же проблема, напрямую кабелем работает, через репитер нет. Буду пробовать Powerline адаптеры.

Возможно, потому что на основном роутере у вас отключено мультикаст вещание во внутреннюю wi-fi сеть. Считается, что это может ее забить. Если второй роутер вы подключаете в режиме усилителя (репитера), и только для подключения второй приставки «по беспроводу», стоит попробовать на основном роутере настроить еще одну виртуальную сеть (Vlan) поверх физической, с отдельным ssid(2, например). В настройках WAN конфигурации включить мультикаст вещание на этот новый ssid2 (также, как для приставок настроены обычно только lan1, lan2). Ну и подключить по новой второй роутер уже к этой сети, как в статье автора про режим усилителя. И да, для ssid2 включить режим wps (pbc режим при этом, если не ошибаюсь, одновременно может быть включен только на одном ssid), чтобы подружить роутеры. Попробуйте.

К слову, у меня все получилось.
Имеем осн. роутер Huawei HG845H (от Ростелекома, Gpon) и свой Zyxel keenetic giga 2. Zyxel переводим в режим «адаптера», предварительно установив компонент со вкладки обновления системы (т.е. даже не «усилителя», т.к. мне с него не требуется раздавать дополнительный wi-fi, нужны только lan-порты. В этом осн. отличие режимов). Перезагружаем, синхронизируем с осн. адаптером по WPS PBC (сначала жмем кнопку на втором, а на главном я ее нажимал через админку хуавея на вкалде настройки WLAN (беспр. сети) для второй vlan (вирт. сети с ssid2). Приставка загрузилась, получила адрес, tv включилось �� Ну и чтобы настроить доп сеть, на хуавей надо заходить под дефолтным суперюзером telecomadmin/admintelecom. Под root/admin править WAN запрещено.

Спасибо за информацию.

надо включать impg и будет вам счастье.

Вы имеете введу IGMP? Я писал об этом в статье.

Спасибо огромное! Все получилось! Автору удачи!

Добрый день! Помогите! Купил роутер NETIS, провайдер ТТК. Настроил подключение, интернет работает и по кабелю и по воздуху. Соединение PPPoE для интернета. А для iptv нужно еще одно соединение сделать статическим! Т.е. нужно два активных соединения. До этого был D-link там легко делается два активных подключения PPPoE и статическое ip. А кто знает как сделать на NETIS?

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

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

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

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

Устройство, когда решает получать multicast-трафик, отправляет свой запрос в сообщении IGMP Membership Report (далее IGMP Report). В нём указывается, что именно устройство желает получать. Адрес запрашиваемой multicast-группы указывается в качестве IP-адреса назначения. Данное сообщение в первую очередь предназначается ближайшему маршрутизатору. Ведь именно он отвечает за передачу трафика между локальным сегментом и остальной сетью.

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

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

Первое, что делает коммутатор, определяет, где находится маршрутизатор(ы). Для этого он слушает наличие в сети сообщений IGMP General Query, PIM, DVMRP и пр.

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

Если такие получатели есть, больше коммутатор ничего не делает. Посылать сообщение IGMP Leave в сторону маршрутизатора смысла никакого нет.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Как только мы запускаем 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-порта будет указывать сам на себя:

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

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

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

IGMP snooping и 224.0.0.X

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

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

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

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

В заключение

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

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

Что такое IGMP snooping?

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

Что такое IGMP Snooping?

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

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

Как работает IGMP Snooping?

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

IGMP Snooping решает эту проблему. Как показано на рисунке выше, когда IGMP Snooping не выполняется на коммутаторе, многоадресные пакеты передаются на Хост A, B, C. Но когда IGMP Snooping включено, коммутатор Snooping IGMP может прослушивать и анализировать сообщение IGMP и устанавливать Записи многоадресной пересылки уровня 2 для управления пересылкой многоадресных данных. Таким образом, пакеты многоадресной рассылки являются только членами групп многоадресной рассылки для получателей A и C, а не шировещательными всем узлам.

Виды IGMP snooping

Существуют две вида IGMP snooping: активный и пассивный.

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

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

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

Каковы функции и приложения IGMP Snooping?

Как упоминалось ранее, два основных преимущества коммутатора IGMP Snooping — это предотвращение потери пропускной способности и утечки сетевой информации.

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

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

Соображения по конфигурациям IGMP Snooping

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

IGMP Snooping Querier

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

IGMP Snooping Proxy

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

Версия IGMP Snooping

IGMP имеет три версии протокола: V1, V2 и V3. Соответственно, вы можете выбрать версию IGMP Snooping на устройстве уровня 2 для обработки сообщений IGMP в разных версиях. Обычно IGMPv1 идентифицирует запрашиваемый маршрутизатор на основе протокола многоадресной маршрутизации. IGMPv2 добавляет возможность групповых запросов, позволяя запрашивающему отправлять сообщения хостам в многоадресной группе. IGMPv3 приносит больше улучшений для поддержки фильтрации определенных источников

Заключение

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