Многоадресный трафик keenetic что это
Перейти к содержимому

Многоадресный трафик keenetic что это

  • автор:

Роутер постоянно что-то качает

Пользователь

Недавно заметил, что роутер keenetic viva постоянно что-то качает. Причем с постоянной скоростью. Канал обновлений — предварительные. Проблему заметил на версии 3.5.6. Только что обновил на версию 3.6.1 — но ситуация не изменилась. Вот скрины состояния прямо сейчас.

Скрытый текст

1.PNG.2df0da74915f3f8c44ab3c7533f9a20c.PNG2.thumb.PNG.3cf8e7cebf18692c76822c01c00d6d7d.PNG3.thumb.PNG.7e745abd3778b2f882d7b634b47bd026.PNG

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

Есть роутер keenetic giga, с той же версией прошивки — на нем такого не наблюдается.

Как выяснить причину проблемы?

Обновления KeeneticOS — Канал разработчика

Протокол многоадресной рассылки DNS (mDNS) преобразует имена хостов в IP-адреса в небольших сетях. mDNS помогает обнаруживать сетевые сервисы, такие как AFP, CIFS, DLNA, сетевые принтеры и сканеры.

KeeneticOS 3.6.0

Улучшения
  • Команда CLI show ip name-server теперь отображает список DNS-серверов со всех подключений к Интернету, с соответствующими именами системных интерфейсов. [ NDMS-1415 ]
Исправления
  • Устранено ограничение, из-за которого файл конфигурации размером более 65639 байт не мог корректно выгружаться с устройства Keenetic или загружаться на него. [ NDMS-1455 ]

KeeneticOS 3.6 Beta 3

Новое
  • Отсутствуют изменения для Keenetic Viva ( KN-1910 ).
Улучшения
  • Улучшен алгоритм выбора оптимальной backhaul-точки при добавлении экстендеров. Теперь он более чувствителен в определении более сильного сигнала от других узлов Mesh Wi‑Fi-системы, что увеличивает пропускную способность и стабильность беспроводных соединений. [ NDMS-1411 ]
Исправления
  • Исправлена проблема монтирования раздела с файловой системой exFAT, форматирование которого было осуществлено в программе MiniTool Partition Wizard. [ NDMS-1390 ]

KeeneticOS 3.6 Beta 2

Исправления
  • Исправлен захват Ретранслятора в Wi‑Fi-систему . [ СообщилUnfaithfull ]
  • Для USB-накопителей исправлен возможный сбой при обработке запроса TREE_CONNECT_ANDX и переименовании файлов. [ NDMS-1133 ]

KeeneticOS 3.6 Beta 1

Исправления
  • Исправлена обработка SMS-сообщений на поддерживаемых QMI-модемах. Полученное сообщение теперь корректно отображается в меню списка SMS-сообщений в веб-интерфейсе. [ NDMS-1383 ] [ Сообщилglogjet ]

KeeneticOS 3.6 Beta 0

Новое
  • Добавлены команды для игнорирования DNS-серверов на интерфейсах IPSec/mobile/OpenVPN. Для применения такой настройки к соответствующему интерфейсу обратитесь к следующим командам CLI. [ NDMS-1355 ]
  • interface ipsec no name-servers
  • interface mobile no name-servers
  • interface openvpn no name-servers

Подсказка

Чтобы подключить к интернет-центру Keenetic модуль Mini PCI-E LTE или M.2 LTE, вы можете приобрести сторонний USB-адаптер со слотом для SIM-карты.

Исправления
  • Исправлена обработка DHCP-опции 249 на L2TP/IPsec-клиенте. Теперь список статических маршрутов, полученных через эту опцию, применяется корректно. [ NDMS-1199 ]

KeeneticOS 3.6 Alpha 16

Новое
  • Добавлена поддержка аутентификации EAP-PEAP для клиента и сервера IKEv2, обеспечивающая расширенную совместимость и повышенную безопасность. [ NDMS-1324 ]
  • Добавлена поддержка режима aes256-sha256-modp2048 IPsec подключение для совместимости с сервисом ProtonVPN. [ NDMS-1004 ] [ Сообщилcemoka ]
Улучшения
  • Улучшен алгоритм обнаружения IPv6-адресов для локальных хостов. Исправлена проблема периодической потери соединения с Интернетом на зарегистрированных локальных устройствах, использующих IPv6 адресацию, когда включена строгая настройка Без доступа в Интернет в Профиле доступа для незарегистрированных устройств . [ NDMS-433 ] [ Сообщилavn ]
Исправления
  • Исправлена некорректная запись файлов размером менее 64КБ на подключенное USB-хранилище по протоколу WebDAV. [ NDMS-1316 ] [ СообщилA. Okan Dagistan ]
  • Исправлены самопроизвольные перезагрузки при использовании модемов Huawei по протоколу CDC-NCM. USB-модемы могут использоваться как для основного, так и для резервного подключения. [ NDMS-1191 ]
  • Профили доступа в Интернет , использующие подключение через модем QMI-типа теперь работают правильно. [ NDMS-1203 ]

KeeneticOS 3.6 Alpha 15

Исправления
  • Исправлена ошибка, не позволяющая добавить новое правило статической переадресации портов в Web-конфигураторе. [ NDMS-1334 ] [ Сообщилsnark ]

KeeneticOS 3.6 Alpha 14

Исправления
  • Доступ к веб-интерфейсу устройства восстановлен. Ошибка в UPnP компоненте, вызывающая циклическую переадресацию на Мастер первоначальной настройки — теперь исправлена. [ NDMS-1326 ] [ Сообщил3-50 ]
  • Исправлено отображение пропавшей кнопки Захват/Проверить для Ретранслятора на странице Wi‑Fi-система . [ NDW-1848 ] [ СообщилUnfaithful ]

KeeneticOS 3.6 Alpha 13

Новое
  • Реализовано ограничение зоны работы клиентских устройств в Wi‑Fi-системе. По умолчанию беспроводные клиенты могут переключаться между любыми узлами (ретрансляторами) Wi‑Fi-системы. В силу разных условий иногда они выбирают дальний, а не ближний узел, получая не оптимальную производительность. Теперь для конкретного беспроводного клиента можно выбрать, чтобы он придерживался определенного ретранслятора (или даже нескольких). Эта настройка доступна как в CLI, так и в веб-интерфейсе на странице Зарегистрированные устройства . [ NDMS-1311 ]
  • mws zone — ограничить зону работы устройства mac-узлом Wi‑Fi-системы cid в интерфейсе командной строки (CLI)
  • или в веб-интерфейсе для определенного клиента выберите узлы Wi‑Fi-системы, которые будут отказывать ему в подключении.

3_6_A_13_mws_zone.png

3_6_A_13_LED.png

Улучшения
  • Отсутствуют изменения для Keenetic Viva ( KN-1910 ).
Исправления
  • Исправлена ошибка force-host: not enough arguments . [ NDMS-1259 ] [ СообщилAndreBA ]
  • Для 4G-модемов исправлено отображение более чем двух несущих. Модемы 4G LTE Cat 6 и выше используют несколько несущих для передачи и приема данных. Информация о нескольких несущих, сообщаемая модемом, теперь отображается корректно. Вы можете найти ее в подробностях мобильного соединения на странице Системный монитор и Подключение к оператору 3G/4G . Или выполнить команду show interface интерфейсе командной строки (CLI). [ NDMS-1156 ] [ Сообщилr13 ]

KeeneticOS 3.6 Alpha 12

Новое
  • Инвертировано расписание работы световых индикаторов. [ NDMS-1265 ] Не используйте устаревшую команду system led shutdown schedule . Вместо устаревшей команды созданы новые команды в CLI для применения настройки:
  • system led power schedule — расписание подачи питания на LED индикаторы
  • system led power shutdown (front | back | all) — режим выключения LED индикаторов
  • ip http proxy force-host
Улучшения
  • Реализован новый пул для улучшенного управления ключами PMK-R1. Это изменение устраняет нестабильное подключение некоторых беспроводных клиентов, использующих безопасность WPA3, при роуминге между узлами вашей Wi‑Fi системы . Механизм быстрого и плавного перехода, улучшающий использование приложений, чувствительных к задержке и потере пакетов, теперь полностью доступен для клиентов WPA3. [ NDMS-1236, NDMS-1253, NDSM-1258, NDMS-1272 ].

KeeneticOS 3.6 Alpha 11

Новое
  • Добавлен режим отладки STP для получения подробной информации о работе Wi‑Fi-системы. Она может быть запрошена инженером технической поддержки для дополнительной диагностики. Вам не нужно включать его для повседневной работы. [ NDMS-1204 ]
  • mws log stp — включение STP-отладки на bridge- интерфейсе
  • no mws log stp — отключение STP-отладки на bridge- интерфейсе
Улучшения
  • Чтобы дать вам более детальный контроль над функциями KeeneticOS, мы разделили Мобильное приложение Keenetic и Агент облачной службы Keenetic Cloud и KeenDNS компоненты. Если мобильное приложение не используется, соответствующий компонент теперь можно полностью удалить из KeeneticOS. [ NDMS-1174 ]

3_6_A_11_KeenDNS_a.png

Исправления
  • Сделано улучшение для плавного Wi‑Fi роуминга: исправлен нестабильный Быстрый переход беспроводных клиентов в Гостевой сегмент . Проблема затронула все сегменты сети с уровнем protected режима безопасности. [ NDMS-1244 ]
  • Отключен STP на интерфейсах OpenVPN и EoIP при добавлении их в мост. Это изменение предотвращает нестабильное поведение Wi‑Fi-системы, вызывающее падение туннельных соединений. [ NDMS-986 ]
  • Исправлен возможный сбой при обращении к SIM-карте QMI-модема. [ NDMS-1285 ]

KeeneticOS 3.6 Alpha 10

Исправления
  • Ранее в Mesh Wi‑Fi-системе с множественными сегментами, IP-адрес Ретранслятора мог некорректно отображаться в списке доступных ретрансляторов на странице Wi‑Fi-система . [ NDMS-1263 ] [ СообщилMDP ]

KeeneticOS 3.6 Alpha 8

Улучшения
  • Ретрансляторы Mesh Wi‑Fi-системы теперь имеют уникальные локальные MAC-адреса в каждом сетевом сегменте. Это обеспечивает стабильность Wi‑Fi-системы, особенно когда ретрансляторы подключаются через неуправляемые Ethernet-коммутаторы. [ NDMS-1083 ]
  • Реализована передача настроек временной зоны на ретрансляторы. Ретрансляторы теперь автоматически применяют настройку часового пояса от Контроллера Wi‑Fi-системы. Нет необходимости вручную устанавливать часовой пояс для каждого узла. [ NDMS-1251 ]
  • Внесены изменения в Монитор трафика хостов для улучшения удобства использования. [ NDW-1577 ]

TrafficMonotorUplift.png

Исправления
  • Исправлено разрешение имени KeenDNS из локальной сети. Теперь клиенты домашней сети могут корректно разрешать доменное имя Keenetic, забронированного с помощью службы KeenDNS. [ NDMS-1250 ] [ СообщилVladimir Dobromyslov ]

KeeneticOS 3.6 Alpha 7

Исправления
  • Исправлено подключение по протоколу PPPoE через VDSL. [ NDMS-1231 ] [ Сообщилaarnet ]
  • Исправлена запись файлов на USB-диск через встроенный Файловый браузер в веб-интерфейсе устройства. [ NDMS-1227 ] [ Сообщилrustrict ]
  • Исправлена поддержка модема Sierra Wireless EM7455. [ NDMS-1230 ]

Подсказка

Чтобы подключить к интернет-центру Keenetic модуль Mini PCI-E LTE или M.2 LTE, вы можете приобрести сторонний USB-адаптер со слотом для SIM-карты.

KeeneticOS 3.6 Alpha 6

Новое
  • Для PPPoE-подключения добавлен сброс физического WAN Ethernet-линка при отсутствии ответа на PADO-пакет. [ NDMS-1179 ]
  • В веб-интерфейсе добавлен селектор отображения Скорость на странице Монитор трафика хостов . Используйте его для наблюдения за скоростью подключения к Интернету для клиентов вашей домашней сети в течение определенных периодов времени. [ NDW-1580 ]

3_6_A6_top5_speed.png

3_6_A6_port_description.png

3_6_A6_extender_static.png

Примечание

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

Исправления
  • Исправлена ошибка в процедуре GTK-rekey (Group Temporal Key) в режиме FT-роуминга. Данное улучшение решило проблему стабильности соединения клиентов для бесшовного роуминга. [ NDMS-1205 ]
  • Исправлено отображение МАС-адреса интерфейса для PPPoE-подключений на стартовой странице Системный монитор . [ NDW-1583 ]

KeeneticOS 3.6 Alpha 5

Исправления
  • Исправлено отображение параметров подключения ретрансляторов на странице Wi‑Fi-системы . [ NDMS-1154 ] [ СообщилAndreBA ]
  • Версия Andes-микрокода для Wi‑Fi-модуля возвращена к 20191220015534 (соответствие релизу 3.4) из-за нареканий к алгоритму выбора полосы 40/80 МГц. Это было сделано в ответ на значительное число жалоб от клиентов. [ NDMS-1149 ]

KeeneticOS 3.6 Alpha 4

Новое
  • Расширенные настройки Wi‑Fi ретранслятора теперь позволяют изменять Ширину канала для радиоинтерфейсов, совместно используемых с транспортными backhaul соединениями. [ NDW-1495 ]

3_6_A_4_channel_width.png

3_5_3_USSD_a.png

Примечание

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

Улучшения
  • Улучшен учет трафика для незарегистрированных хостов. [ NDMS-1093 ] [ СообщилZeliboba ]

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

Report Suppression

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

Так как все сообщения 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 он включён по умолчанию:

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. Момент важный, так как именно она лучше всего передаётся по сети (факт проверен).

Чуточку тернистый путь уже в самом начале

С проблемой маршрутизации 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.

Не забываем о TTL

Стоит заметить, что по умолчанию VLC проигрыватель устанавливает TTL для пакетов потокового вещания равным 1. Это значит, что такие пакеты не могут быть переданы в другую сеть, т.е. маршрутизироваться. Поэтому для нашего случая в настройках VLC значение TTL было выставлено больше единицы.

По дампу видно, что получатель запросил трафик (отправил сообщение 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:

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

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

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

Точно также будут обстоять дела со всеми 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. Коммутатор в свою очередь транслирует его на все свои порты.

Итоговый дамп с устройств

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

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

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 стал его обрабатывать:

Сообщения IGMPv3

Я думаю, Вы уже заметили, что в дампе фигурируют пакеты IGMPv3. При этом ранее мы везде видели только IGMPv2. Обусловлено это тем, что на оборудовании Cisco по умолчанию используется IGMPv2. А в ОС Windows (7, 8, 10) используется IGMPv3. Во всех предыдущих случаях на маршрутизаторе был включён IGMP и клиенты, получая периодически от маршрутизатора сообщения IGMPv2 General Query, автоматически переключились также на вторую версию протокола. В текущем сценарии на маршрутизаторе отключён IGMP, поэтому клиент использует третью версию протокола.

Теперь нужно убедиться, продолжает ли коммутатор рассылать 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-порта:

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

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 

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

В заключение

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

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

  • Блог компании CBS
  • Системное администрирование
  • Cisco
  • Сетевые технологии

Расширенные настройки Wi-Fi на UniFi

UniFiWi-FiSettings.png

Расширенные настройки Wi-Fi UniFi часто понимают неправильно. Значения по умолчанию обычно безопасны, но полезно понимать, что они делают при настройке сети или устранении неполадок. Ubiquiti в документации не очень хорошо объясняет, поэтому давайте рассмотрим их один за другим. Эти настройки и описания используют «новый» интерфейс по умолчанию и являются текущими, начиная с версии 6.5.53 сетевого приложения UniFi. В конце я также перечисляю настройки, доступные только в классическом/старом интерфейсе.

Создание новой сети Wi-Fi UniFi

  • Wi-Fi управляет вашими беспроводными соединениями, включая SSID, пароль и другие дополнительные параметры.
  • Сети (Networks) контролируют ваши локальные сети и виртуальные локальные сети, включая DHCP, DNS и IP-адреса.
  • Интернет контролирует ваши подключения к глобальной сети, включая виртуальные локальные сети, IP-адреса и интеллектуальные очереди для QoS.

По умолчанию UniFi имеет одну сеть LAN, которая используется для всех проводных и беспроводных подключений. Создание дополнительных сетей позволяет сегментировать и ограничивать трафик. Это обычно используется для гостевых устройств или устройств IoT или для разделения устройств или областей на разные сетевые группы. Прежде чем углубляться в настройки беспроводной сети, сначала настройте свои сети и VLAN. Это можно сделать, изменив локальную сеть по умолчанию или создав новую сеть на вкладке «Сети».

Если сеть, которую вы хотите использовать для Wi-Fi, уже создана, перейдите в «Настройки» → «Wi-Fi» → «Добавить новую сеть».

UniFi-CreateaWi-FINetwork.png

Дайте ему имя (SSID), пароль и укажите, какую сеть он будет использовать. Если вы не хотите использовать пароль WPA2 по умолчанию для сети, откройте дополнительные параметры, прокрутите вниз до вкладки «Безопасность» и измените настройки там. В противном случае вы можете сохранить его, и он будет добавлен ко всем вашим точкам доступа по умолчанию.

Если вам нужна базовая сеть, это все, что вам нужно сделать. Если вы хотите больше, хорошие вещи скрыты на вкладке «Расширенные функции»/Advanced Features.

Расширенные настройки Wi-Fi UniFi

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

Диапазон WI-FI (WI-FI Band)

  • 2,4 ГГц: медленнее, дальность больше, лучше проникает сквозь стены.
  • 5 ГГц: быстрее, меньший радиус действия, меньшее проникновение через стену.
  • По умолчанию: Оба.
  • Эффект: этот параметр определяет, на каком диапазоне вещает ваша сеть Wi-Fi. Вы можете выбрать один или включить оба.
  • Примечание. Использование двухдиапазонных SSID может привести к проблемам с роумингом, поскольку некоторые клиенты не используют 5 ГГц или не перемещаются к ближайшей точке доступа. Есть несколько способов борьбы с этим — обычно эффективными могут быть корректировка размещения точки доступа, снижение мощности передачи на частоте 2,4 ГГц, включение управления диапазоном, быстрый роуминг или настройки «высокопроизводительных устройств». Вы также можете создать отдельную сеть 2,4 ГГц и 5 ГГц, если хотите гарантированно вручную контролировать, какая полоса частот используется каким устройством.

Оптимизация подключения IoT Wi-Fi (Optimize IoT Wi-Fi Connectivity )

  • Повышает надежность подключения устройств IoT.
  • По умолчанию: Вкл.
  • Эффект: принудительно устанавливает для параметров DTIM значения по умолчанию, равные 1 для 2,4 ГГц и 3 для 5 ГГц. Подробнее о DTIM ниже, в разделе «Управление скоростью и маяком 802.11».

Группы точек доступа (AP Groups)

Позволяет группировать точки доступа и выбирать, какие из них будут транслировать эту сеть Wi-Fi.

По умолчанию: все точки доступа.

Примечание. UniFi имеет ограничение в 4 SSID на диапазон для каждой группы точек доступа. Вы можете увеличить это число до 8 SSID, если ограничите свои сети одной полосой. У вас может быть до четырех сетей 2,4 ГГц и до четырех сетей 5 ГГц или четыре двухдиапазонных SSID. Вы всегда можете создать дополнительные SSID, но каждая точка доступа или группа точек доступа могут одновременно транслировать только четыре SSID в каждом диапазоне.

UniFi+-+Wi-Fi+Band+and+AP+Group.png

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

UAPSD

  • Незапланированное автоматическое энергосбережение, также известное как энергосбережение WMM.
  • По умолчанию: Выкл.
  • Эффект: включение позволяет устройствам, поддерживающим UAPSD, экономить заряд батареи, удерживая их Wi-Fi-радио в спящем режиме в течение большего времени. Как и многие функции, которые отключены по умолчанию, это может вызвать проблемы для некоторых клиентов, особенно для старых устройств или устройств IoT.
  • Рекомендация. Включите, если важно время автономной работы, а подключение к старым устройствам/устройствам IoT — нет.

High Performance Devices (Высокопроизводительные устройства)

  • Подключайте высокопроизводительных клиентов только к 5 ГГц.
  • По умолчанию: Вкл.
  • Результат: отключение этого параметра позволяет «высокопроизводительным» клиентам подключаться к частоте 2,4 ГГц. Это может исправить (или усугубить!) некоторые проблемы с двухдиапазонными SSID и низкой производительностью роуминга за счет снижения пропускной способности при подключении устройств к частоте 2,4 ГГц.
  • Рекомендация: отключите, если у вас есть области, которые покрываются только 2,4 ГГц, или есть проблемы с тем, что клиенты 2,4 ГГц не могут подключиться к сети.
  • Примечание. Ubiquiti не указывает, что такое «высокая производительность», но я предполагаю, что это относится к устройствам, поддерживающим Wi-Fi 5 или 6 и несколько пространственных потоков. Современные телефоны и ноутбуки, в основном.

Proxy ARP

  • Переназначает таблицу ARP для станции. ARP — это протокол разрешения адресов, который используется для получения MAC-адреса для данного IP-адреса.
  • По умолчанию: Выкл.
  • Эффект: включение позволяет точке доступа отвечать на запросы ARP для клиентских устройств, что помогает ограничить широковещательный трафик. Это в основном относится к более крупным сетям с более высокой плотностью.
  • Рекомендация: включите для сетей с высокой плотностью.

Устаревшая поддержка

  • Включите поддержку устаревших устройств (например, 11b).
  • По умолчанию: Выкл.
  • Эффект: включение этого параметра позволяет подключаться к более старым устройствам, которые не поддерживают стандарты 802.11g или более новые.
  • Рекомендация. Включайте, только если вам нужны устройства, поддерживающие только 802.11a или 802.11b для подключения к сети.

Расширение многоадресной рассылки (IGMPV3)

  • Разрешить устройствам отправлять многоадресный трафик зарегистрированным клиентам с более высокой скоростью передачи данных, включив протокол IGMPv3.
  • По умолчанию: Выкл.
  • Эффект: включение этого параметра может повысить производительность продуктов для умного дома, таких как умные колонки или потоковые устройства. Например, динамики Sonos обычно работают лучше, когда…
    • Spanning Tree настроен на обычный режим STP на ваших коммутаторах. Я бы также рекомендовал понизить приоритет ваших коммутаторов, чтобы они продолжали быть корневым мостом Spanning Tree.
    • IGMP Snooping включен в настройках сети -> дополнительно. Это позволяет коммутаторам идентифицировать группы многоадресной рассылки, используемые в каждом порту. Многоадресные потоки перенаправляются только на сетевые устройства, которые должны их получать.
    • Улучшение многоадресной рассылки (IGMPv3) включено в настройках Wi-Fi -> дополнительно. Это активирует службу запросов IGMP на шлюзе UniF i, позволяя ему создавать группы многоадресной рассылки, которые должны улучшить многоадресный трафик, такой как видео- или аудиопотоки. Некоторым людям повезло с этим отключением, и могут быть другие проблемы, такие как топология сети. Многоадресную рассылку трудно устранить без перехвата пакетов и знания задействованных протоколов.
    • Многоадресный DNS включен в разделе «Дополнительные функции» -> «Дополнительные настройки шлюза». mDNS позволяет преобразовывать имена хостов в IP-адреса в локальной сети без DNS-сервера. Примером mDNS является Bonjour от Apple, который используется для быстрой настройки общего доступа между компьютерами и другими устройствами. Служба mDNS UniFi позволяет обнаруживать устройства в других сетях.

    Переход BSS

    • Разрешить переход BSS с помощью WNM, что означает «Управление беспроводной сетью». WNM позволяет точке доступа отправлять сообщения клиентам, чтобы предоставить им информацию о сети и сведения о других точках доступа. Это включает в себя текущее использование и количество клиентов, что позволяет клиенту принимать более обоснованные решения о роуминге.
    • По умолчанию: Вкл.
    • Эффект: Включает 802.11v. Это помогает экономить электроэнергию и процесс роуминга, но клиентское устройство должно принять решение на основе предоставленной информации.
    • Рекомендация: оставьте включенным, особенно в сетях с несколькими точками доступа.

    Изоляция L2

    • Изолирует станции на уровне уровня 2 (Ethernet)
    • По умолчанию: Выкл.
    • Эффект: Запрещает клиентам общаться друг с другом.
    • Рекомендация: включите для гостевых сетей с высоким уровнем безопасности или сетей IoT, которые выиграют от этого ограничения. Это также может привести к непредвиденным последствиям, поэтому проверьте поведение устройств до и после изменения этого параметра.

    Включить быстрый роуминг

    • Более быстрый роуминг для современных устройств с поддержкой 802.11r. Это достигается за счет ускорения процесса согласования ключа безопасности, что позволяет выполнять согласование и запросы ресурсов параллельно. В 802.1X ключи кэшируются, а клиенту не нужно проверять сервер RADIUS при каждом перемещении. В сетях с предварительным общим ключом, таких как WPA2, клиент проходит обычный процесс аутентификации с четырехэтапным рукопожатием.
    • По умолчанию: Выкл.
    • Эффект: Включает OTA (беспроводной) быстрый переход BSS, что позволяет устройствам, которые его поддерживают, быстрее перемещаться между точками доступа. Если этот параметр не включен, роуминг от точки доступа к точке доступа может занять несколько секунд, и в течение этого времени данные не могут быть отправлены или получены. В большинстве случаев вы этого не заметите, но чувствительные к задержке приложения и приложения реального времени, такие как голосовой вызов, работают плохо. Медленное поведение в роуминге при вызове VoIP может привести к разрывам в звуке. При включенном быстром роуминге 802.11r роуминг должен быть практически незаметен.
    • Примечание. Fast BSS Transition работает как с предварительным ключом (PSK), так и с методами аутентификации 802.1X. Старые устройства не должны испытывать проблем с подключением, если эта функция включена.

    Профиль пропускной способности

    По умолчанию или выберите существующий профиль.

    По умолчанию: пропускная способность не ограничена.

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

    Примечание. Создайте новые профили в разделе «Дополнительные функции» → «Профиль пропускной способности».

    UniFi+-+New+Bandwidth+Profile.png

    Протокол безопасности

    • Open. Для подключения к сети пароль не требуется.
    • WPA-2. Более старый метод безопасности с предварительным общим ключом, требующий пароля для подключения к сети. WPA-2 менее безопасен, чем WPA-3, но поддерживается более универсально, особенно на старых устройствах.
    • WPA-2 Enterprise. Более старый метод безопасности 802.1X, который требует, чтобы сервер RADIUS позволял пользователям подключаться к сети с помощью имени пользователя или пароля. Обычно встречается в более крупных сетях, которым необходимо предоставить или отозвать разрешение на присоединение без изменения доступа других людей путем изменения предварительного общего ключа.
    • WPA-2/WPA-3. Позволяет использовать соединения WPA-2 и WPA-3. Устройства, поддерживающие WPA-3, будут использовать более новый и безопасный стандарт, а старые клиенты будут использовать WPA-2. В целом это менее безопасно, чем требование WPA-3, но оно более гибкое и с меньшей вероятностью вызовет проблемы при переходе на WPA-3 по умолчанию.
    • WPA-3. Более новый метод безопасности с предварительным общим ключом, который делает много волшебства за кулисами, чтобы быть более безопасным, чем WPA-2. WPA-3 по-прежнему уязвим для определенных атак, поэтому обязательно используйте сложный пароль и ограничьте доступ к нему, если это имеет значение.
    • WPA-3 Enterprise. Более новый метод безопасности 802.1X, который, как и персональный WPA-3, обеспечивает более безопасные соединения.

    UniFi+-+Wi-Fi+Security+Settings.jpg

    Если выбран WPA3.

    WPA3 SAE anti-clogging threshold in seconds (Порог защиты WPA3 SAE в секундах):

    • По умолчанию: 5
    • Примечание. SAE — это одновременная аутентификация равных, а защита от засорения предназначена для предотвращения атак типа «отказ в обслуживании» (DoS) на точку доступа. Этот параметр влияет на порог времени для того, что точка доступа считает «слишком много» запросов.

    WPA3 Sync в секундах:

    • По умолчанию: 5
    • Примечание. Объяснение того, как работает WPA3, выходит за рамки этого руководства. Изменяйте их только в том случае, если вы знаете, что делаете, и у вас есть веская причина.

    Скрыть название Wi-Fi

    Это заставляет точки доступа отправлять маяковые кадры без SSID, что означает, что поле SSID в маяковом кадре устанавливается равным нулю. Маяки по-прежнему отправляются, а «скрытые» сети по-прежнему легко обнаружить. Чтобы присоединиться к сети со скрытым SSID, клиентам придется вручную вводить имя SSID вместе с паролем.

    Сокрытие SSID не повышает безопасность сети. Использование более сложного пароля или переход на более новый протокол (WPA2/3 по сравнению с WPA или WEP) делают это.

    PMF (PROTECTED MANAGEMENT FRAME)

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

    • Required: точки доступа будут использовать PMF для всех станций. Станции без возможности PMF не смогут присоединиться к WLAN. Требуется для WPA3.
    • Optional: точки доступа будут использовать PMF для всех совместимых станций, позволяя станциям, не поддерживающим PMF, подключаться к WLAN.
    • Disabled: точки доступа не будут использовать PMF ни для каких станций.

    Групповой интервал переключения

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

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

    Настройки авторизации по MAC-адресу

    UniFi+-+Wi-Fi+MAC+Authorization+Settings.png

    MAC address Filter:

    • Позволяет запретить клиентам подключаться к сети, если они не находятся в списке разрешенных, или заблокировать определенные MAC-адреса.
    • Позволяет использовать сервер RADIUS для аутентификации клиентов.
    • Позволяет выбрать предварительно определенные профили RADIUS.
    • Чтобы создать новый профиль, перейдите в «Дополнительные функции» -> «RADIUS» -> «Добавить профиль RADIUS». Здесь вы определяете аспекты вашего сервера RADIUS, такие как IP-адрес, порты, назначенная VLAN, общие секреты и интервал обновления.
    • Позволяет вам установить формат MAC-адреса и ожидаемые точки с запятой или дефисы.

    Управление 802.11 скоростью и маяком

    UniFi+-+802.11+Rate+and+Beacon+Controls.png

    OVERRIDE DTIM PERIOD

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

    • По умолчанию для 2,4 ГГц: 1, что означает, что каждый маяк 2,4 ГГц будет включать DTIM.
    • По умолчанию для 5 ГГц: 3, что означает, что каждый третий маяк 5 ГГц будет включать DTIM.
    • Примечание. Вы не можете изменить значения по умолчанию, если включен параметр «Оптимизировать подключение к IoT Wi-Fi».

    2.4 AND 5 GHZ DATA RATE CONTROL

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

    • По умолчанию для 2,4 ГГц: разрешены все скорости (от 1 до 54 Мбит/с).
    • По умолчанию для 5 ГГц: разрешены все скорости (от 6 до 54 Мбит/с).
    • Рекомендация: оставьте значение по умолчанию для большинства сетей. Отключение скоростей ниже 6 или 11 Мбит/с может повысить эффективность сетей с более высокой плотностью.

    Позволяет включать и выключать SSID в определенное время или настраивать расписание на неделю.

    UniFi+-+Wi-Fi+Scheduler.png

    Настройки доступны только в старом интерфейсе (начиная с версии 6.5.53)

    Эти настройки отсутствуют в новом интерфейсе или были перемещены/переименованы.

    • Apply Guest Policies (Применить гостевые политики)
    • Beacon Country
    • Add 802.11d county roaming enhancements (Добавление улучшений роуминга по округам 802.11d)
    • TLDS Prohibit (TLDS Запрет)
    • Block Tunneled Link Direct Setup (TDLS) connections (Блокировка подключений с прямой установкой туннельного канала (TDLS))
    • Point to Point, also referred to as P2P
    • Send beacons at 1 Mbps (Отправка маяков со скоростью 1 Мбит/с)

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

Ваш адрес email не будет опубликован. Обязательные поля помечены *