У нас теперь есть экспериментальная прошивка, которая показала положительные результаты в решении этой ошибки. Мы создали новую тему, чтобы сосредоточить и упорядочить обсуждение. Подробности здесь: https://community.ui.com/questions/63eef4ff-303f-4088-89cd-a799620fd0d6#comment/d27d72de-4033-458b-9208-b46ecf8002f8

@trustlab, извините за задержку с ответом. Мы собирали предварительные результаты по этому вопросу.

@EricE

Это классные вещи. Но мы немного отвлеклись от темы. Я продолжу это в другом треде позже. Я отмечу тебя в теме.

Ну, я просто сделал /16, чтобы не заморачиваться с размером сети. Мы не такие большие, как вы, и в основном это было нужно, чтобы не закончились адреса в пуле DHCP, потому что ни ISC, ни Microsoft обычно не освобождают лизы, как обещают, а если задать слишком короткое время аренды, начинаются настоящие шторма обновлений, когда устройства пытаются обновить лизу примерно на середине срока. А с увеличением числа устройств в сети это становится только хуже. 😛 Если бы у меня действительно было несколько тысяч устройств одновременно в крупной системе Unifi, я бы не был таким легкомысленным, как раньше (уф!).

Я думал, что широковещательные сообщения фильтруются на каждом точке доступа, даже без изоляции клиентов, но, когда я это написал, понял, что это не имеет смысла — вещи, которые у меня сейчас работают (например, airprint), бы не работали. Без изоляции клиентов с таким количеством устройств было бы совсем другая история.

Наверное, пришлось бы разбивать на зоны по SSID, чтобы люди сохраняли настройки сети и надеялись, что устройства смогут переключаться между SSID (ужас!). Или, может, VLAN, управляемые через Radius? Если это не гости, то можно контролировать аутентификацию через radius и группировать пользователей по VLAN. У меня не было установки достаточно большой, чтобы заморачиваться с этим radius, проверить как оно реально работает, но это интересный вызов, и с реальным кейсом стоит почитать про VLAN на radius, может, теперь это будет любопытно. Я, конечно, могу совсем ошибаться — меня это не удивит, но, наверное, именно из-за таких ситуаций люди и хотят VLAN, управляемые radius.

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

Да, я пропустил вторую страницу, когда сначала публиковал сообщение. Как ты в итоге решил эту проблему? Это было непонятно (или я и это тоже пропустил?).

Вы ошибаетесь. Просто сделайте подсеть больше! Абсолютно нет причины для того сложного беспорядка, который у вас сейчас — не удивляюсь, что у вас проблемы. РЕДАКТИРОВАНИЕ: сначала пропустил вторую страницу. Я использую /16 для гостевой сети (точно 172.20.0.0/16). Один SSID, один VLAN. Диапазон DHCP-сервера у меня с 172.20.10.0 по 172.20.40.0 — более 5000 IP-адресов доступно для выдачи, и я еще мог бы увеличить пул (сейчас, когда смотрю, не понимаю, почему именно такой диапазон выбрал — ну да ладно). За всю историю максимум было несколько тысяч активных арендаемых адресов в самые загруженные недели, так что у меня сеть была крупнее вашей и никаких проблем. У вас проблема с сетью, которая совсем не связана с Unifi. РЕДАКТИРОВАНИЕ: пропустил вторую страницу обсуждения. Всё равно не понимаю, как у вас один SSID может работать сразу на двух разных L2-сетях. Если бы речь шла о разных частях здания или кампуса и возникали бы проблемы с широковещательными пакетами, тогда, мне кажется, нужен был бы Guest2 или другой SSID. Но в гостевой сети с изоляцией клиентов широковещательные пакеты должны ограничиваться отдельными точками доступа и не распространяться по всей системе, так что я всё равно не вижу, в чём тут проблема, если только я действительно чего-то не понимаю в том, как AP обрабатывают широковещательные пакеты.

Да, мы действительно назначили их в отдельные VLAN.

Да, согласен. Если только ваше оборудование не поддерживает что-то вроде динамического VLAN-пулинга. В таком случае можно использовать сколько угодно VLAN, и они «поедут» вместе с клиентом при роуминге, если это нужно. На самом деле мы никогда не использовали подсети больше /22 (1022 узла) для наших Wi-Fi сетей. Просто потому что хотим избежать проблем с широковещательными рассылками, и можем просто применять VLAN-пулинг с оборудованием Aerohive. Знаю, что большая часть Wi-Fi оборудования (включая unifi) снижает количество широковещательных рассылок при необходимости, но я предпочитаю перестраховаться. Всякая неоднозначность, правда. Некоторые вендоры рекомендуют /23, другие /22, а есть и те, кто без проблем работают с /19. Возможно, мы тоже попробуем такое на одном из наших объектов, посмотрим, что из этого выйдет 😉

@UBNT-BenBuckley

Спасибо, что указали, что правильнее объяснять топологию как одну L2-сеть или «один и тот же широковещательный домен». Именно это я и пытался сказать.

@UBNT-jeff

По поводу большого DHCP пула класса B... Что скажете о том, что широковещательные рассылки создают слишком большую нагрузку на L2-сеть с тысячами беспроводных клиентов? Не существует ли порога количества L2-клиентов, после которого рассылки просто «убьют» беспроводную сеть? Теоретически, я не представляю, как можно эффективно работать с полной сетью класса B из 65 000 клиентов. Проводную сеть ещё могу представить, а вот беспроводную — никак.

Привет,  

@UBNT-BenBuckley, @ и @DBNet — вы были среди тех, кто сообщил о замедлениях после обновления до 4.8.14 (3.3.19.4015). У нас есть только один объект с 10 AP-Pro. На этом объекте стоит 4.8.14 (3.3.19.4015), и никаких жалоб на тормоза не поступало. Извините, помочь с данными для устранения неполадок в этом случае не могу.