Прочитал все старые вопросы и ответы про SONOS через VLAN, но интересно, не изменилось ли что-то за последние годы на уровне ROS7 и/или прошивки SONOS. В общем, хочу поставить колонки SONOS в одну VLAN, а ПК и смартфоны с приложением SONOS — в другую VLAN. Пробовал такую конфигурацию PIM/SM, но приложение SONOS не находит колонки.
Сейчас никакой файрвол не блокирует маршрутизацию между VLAN. Я могу пинговать колонки и обращаться к REST endpoint. Также пробовал более простую настройку через IGMP proxy — без результата. Железо — CCR2004 с ROS версии 7.12.
blighterfog
Guest
0
07.03.2024 02:08:00
Пробовал использовать VPN?
gotsprings
Guest
0
08.03.2024 00:12:00
Это работает на моём стенде… /routing pimsm instance add disabled=no name=pimsm-instance1 vrf=main /routing pimsm interface-template add disabled=no instance=pimsm-instance1 interfaces=bridge,Guest
unlikely
Guest
0
08.03.2024 09:28:00
После моих первоначальных вопросов мне наконец удалось заставить систему Sonos работать через VLAN. Она даже работала через Wireguard VPN! К сожалению, на прошлой неделе, несмотря на то, что она всё ещё работает с приложениями на ПК/Mac, на мобильных приложениях для Android/iOS она больше не работает, даже при локальном подключении. Есть идеи?
gotsprings
Guest
0
08.03.2024 22:34:00
Я использовал iPhone и телефон на Android в основной сети и подключался к сети Sonos. Wireguard... подожди... если ты не в Wi-Fi, Sonos вообще не подключится на мобильных устройствах.
unlikely
Guest
0
10.04.2024 09:23:00
Думаю, я сделал некоторые интересные открытия и достиг определённого прогресса. Сейчас система Sonos корректно и стабильно определяется контроллерами в разных VLAN. Хочу поделиться своим опытом и извиниться за использование онлайн-переводчика. Немного контекста: моя сеть в основном состоит из Mikrotik CCR2004, UniFi Aggregation Pro и нескольких других коммутаторов и точек доступа UniFi. На данный момент между CCR и агрегатором есть только 2x SFP+ bonded-соединение; все VLAN проходят на этом бонде с тегами, а ethernet-порты CCR не задействованы. Другие коммутаторы подключены к агрегатору, а точки доступа — к другим коммутаторам. По сути, на CCR настроен один мост с указанным бондом в качестве порта, включён vlan-фильтр и созданы разные vlan sub-интерфейсы.
Несколько месяцев назад настроен WAN Failover с двумя провайдерами (на основе , а недавно добавлен WAN Load Balancing с тремя провайдерами. Фаервол построен на официальной документации Mikrotik () с разными модификациями под конкретные задачи и для реализации очередей; сейчас он не ограничивает трафик между «доверенными» VLAN.
Всего в сети 10 колонок Sonos версии S2, они подключены к общему Wi-Fi, но им через radius выделена отдельная VLAN. Контроллеры Sonos работают и по проводам, и по Wi-Fi и находятся в двух других VLAN. Некоторые контроллеры подключены через Client-to-Site и Site-to-Site VPN по Wireguard-туннелям, которые установлены на CCR.
Сегментация VLAN была сделана примерно в январе, и благодаря PIM/SM система Sonos сначала работала довольно стабильно, требовалась лишь авторизация multicast-трафика между доверенными VLAN. Но недавно практически все локальные контроллеры начали плохо определять Sonos. Похоже, что распознавание системы затруднялось, когда у двух колонок был нестабильный Wi-Fi. За последние дни подключение стало практически невозможным, кроме смартфонов, находящихся в одной VLAN с колонками. Любопытно, что у контроллеров, подключённых через Wireguard, проблем не было ни разу.
Вот что, как мне кажется, я понял. После первичного обнаружения системы через multicast/SSDP контроллер «привязывается» к конкретной колонке (это видно в настройках приложения) и дальше общается с системой по unicast, может управлять даже без маршрутизации multicast, по крайней мере некоторое время, пока привязанная колонка доступна в сети. Это объясняет, почему удалённые клиенты по Wireguard, которые изначально связаны с колонками со стабильным соединением, всегда работали, а локальные, связанные с колонками с нестабильным Wi-Fi, испытывали проблемы.
Поведение системы UniFi по multicast изменилось уже некоторое время назад. В консоли UniFi написано, что IGMP snooping — это оптимизация multicast, но на деле сейчас это скорее необходимая функция для передачи multicast-трафика. Даже если во всех сетях UniFi snooping выключен и на CCR-мосту отключён IGMP snooping, SSDP multicast-трафик не распространяется в сеть колонок, по крайней мере M-SEARCH с сети контроллера не доходит. Если же на UniFi включить IGMP snooping, агрегатор начинает работать как IGMP querier (об этом сообщает CCR). На CCR IGMP snooping — это скорее оптимизация, которую можно включать или отключать, но если обнаружен внешний querier, CCR запросы не посылает вне зависимости от настроек.
В итоге могу сказать, что проблемы были связаны не столько с настройками Mikrotik CCR, сколько с конфигурацией UniFi, которая, вероятно, была изменена обновлением и сначала осталась незамеченной по причинам, описанным в пункте 1.
