Снова просто высказываю предположение, чтобы посмотреть, приживется ли: столкнулся с проблемой, вызванной устройством, разработанным в начале-середине 2000-х, которое использует IGMP версии 1, а она не поддерживает IGMP snooping или pruning. Поэтому устройство работает отлично первые 5-10 минут, а потом, с точки зрения огромного коммутатора Cisco, теряется в сети. По последним данным, существуют ещё версии 2 и 3 IGMP, так что, возможно, есть функции, которые нужны, но отсутствуют в используемой версии. Шанс небольшой, ведь я ожидал, что всё, что сделано за последние 10 лет, как минимум поддерживает IGMP v2, но кто знает. Раньше мы много работали с мультикастом, но заставить разное сетевое оборудование нормально взаимодействовать со всеми возможными вариантами, да ещё убедить админов это понять и разрешить, стало головной болью, которая того не стоит. Теоретически это должно экономить трафик, но, похоже, в некоторых случаях происходит наоборот

У Cisco есть несколько вариантов настройки мультикаста, которые влияют на то, как IGMP распространяется по сети. Глобально: ip pim bidir-enable # pim — protocol-independent multicast, ip multicast-routing. На интерфейсе: ip pim sparse-dense-mode.

Это всё на роутере 2800-й серии, но именно настройка sparse-dense mode определяет, как устройство убирает старые пути, и оказалась важной в паре конфигураций, которые мы делали некоторое время назад. Суть в том, что похожие команды, влияющие на мультикаст, могут быть и в коммутаторах UBNT, хотя они не так очевидны; на Cisco нам тоже пришлось их долго распознавать.

Честно говоря, я удивлён, что STP вообще как-то связан с распространением мультикаста.

Я не сильно разбираюсь в STP, но где-то за последний месяц кто-то рекомендовал переключить STP при похожей проблеме с мультикастом. Жаль, что не могу найти тот изначальный топик, зато там пользователю это действительно помогло.

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

Ты имеешь в виду способ, который обходит TCN? Я не менял никаких настроек STP, нет. Но не уверен, что это как-то повлияет. Даже если из-за изменения топологии происходит флуудинг, единственный мультикаст-трафик в локальной сети — это с присоединённого канала. Шлюз ISP работает как мультикаст-маршрутизатор и не флуудит из-за TCN. Так что даже если свитчи UniFi раздают мультикаст трафик повсеместно, то в этом случае это всего пара каналов (~16–20 Мбит/с), потому что включено всего несколько приставок. Не думаю, что это скажется на видео, разве что приставки слишком заняты, сбрасывая другой трафик? Всё же такой небольшой объём трафика не должен быть тяжёлым для обработки.

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

В данный момент я пытаюсь развернуть беспроводное IPTV для многоквартирных домов (MDUs) с использованием Unifi AP, управляемых контроллером CK. Я столкнулся с несколькими странными ситуациями, которые не всегда имеют логичный смысл, но после долгих экспериментов с разными сценариями получилось следующее.

Прежде всего, нужно добавить файл config.properties в каталог /usr/lib/unifi/data/site/[sitename] на контроллере, например, "/usr/lib/unifi/data/site/default". Мой файл config.properties выглядит так:
##Config.properties file  
config.mcast_filter_enabled=false

После того, как вы добавите этот файл на контроллер, необходимо сделать сброс AP к заводским настройкам и повторно его adopter'ить, чтобы применить новую конфигурацию. Просто нажать «забыть» в разделе Manage device и сделать повторный adopt — это сработает. Это позволит multicast-трафику распространяться без фильтрации. И это ОБЯЗАТЕЛЬНО, чтобы беспроводной multicast-трафик прошёл между WLAN и проводной сетью.

В моей настройке в качестве локального роутера выступает USG, с сетью по умолчанию 192.168.1.1/24, которая работает на VLAN по умолчанию (1), обычно untagged. У меня есть WLAN для этой сети, например, с именем «WiFi Access» без настроек VLAN. Также есть SSID «IPTV», который тегируется как VLAN 1050. Дальше у меня два разных сценария, и только один из них работает стабильно.

В моём лабораторном стенде используется аналогичная конфигурация с EdgeSwitch-48 в роли Layer 2 устройства. Я создал VLAN 1050, который выступает как «WAN VLAN». На этом VLAN находятся WAN-порт USG и аплинк на шлюз ISP (контролируемый мной, он же источник multicast). Эти порты — untagged access порты. VLAN также tagged на порту 1, к которому подключён UAP-AC-LITE (untagged 1, tagged 1050). Эта схема работает при условии, что IGMP отключён на EdgeSwitch. Как только я включаю IGMP на EdgeSwitch, каналы пропадают, а STB не загружается (загрузка конфигурации с сервера происходит через multicast). Считаю, что это баг, потому что в других решениях с IGMP (например, на Cisco 2960x) IGMP включают на всех Layer 2 устройствах, чтобы избежать ненужного флудинга.

Самые странные проблемы возникают на объекте у клиента. Тут такая же сеть — USG в роли шлюза, один SSID для обычного интернета, второй «IPTV» на VLAN 1050. Разница в том, что AP — UAP-AC-LR, а коммутаторы — Unifi switch 24-портовый. Тут мне снова пришлось отключать IGMP на коммутаторе, чтобы он и AP нормально загружались, но через 5-10 минут поток сильно портился, а если перезагрузить STB, он зависает при попытке подключиться к multicast-потоку. Для проверки поставил UAP-AC-Lite «просто ради интереса», и поток с ним шел гладко больше часа, пока не начались похожие проблемы с деградацией и загрузкой видео. Во время плавного воспроизведения на Lite я попытался загрузить второй STB — он зависает на multicast join, при этом первый телевизор снова начинает испытывать такие же проблемы. Пробовал снижать мощность AP — без эффекта. Пробовал включить IGMP на свитче и выключить на AP через config.properties — тоже без результата.

Похоже, что проблема именно с IGMP на Unifi Switches, так как единственное отличие между моим лабораторным стендом и объектом клиента — это тип коммутатора. Я исключил помехи (работаю на 5 ГГц на свободном канале) и пропускную способность (в момент теста пользователей wifi не было, контроллер показывал кб/с трафика). Кто-нибудь ещё сталкивался с проблемами multicast для видео на Unifi свитчах?