[alibek]

На большой и достаточно сложной территории (деревья, кусты, вода) нужно организовать беспроводную сеть. Как сейчас принято говорить — с бесшовным роумингом. Если точнее, то нужны 802.11r/k, большим бонусом будет двухдиапазонность. Сейчас не нужно, но возможно в будущем бонусом будет нормальная поддержка WPA-EAP с динамическими VLAN, аккаунтингом и прочими плюшками. Предполагаю, что потребуется несколько десяткой точек доступа.

Сильно умные устройства не нужны. Предполагается, что точки доступа будут просто транспортом с минимальным набором возможностей, а авторизация, управление доступом и пользователями будет осуществляться централизованно, на шлюзе доступа. Сейчас в качестве такого шлюза будем использовать Mikrotik RB4011, в дальнейшем возможно заменим на нормальный BRAS или сервер. Проприетарные решения с привязкой к конкретному вендору/устройствам и обязательным контроллером будет рассматривать в последнюю очередь.

Хотспот будет не для монетизации, а скорее для имиджа и частично для рекламы.

Подскажите, на какие устройства стоит обратить внимание?

Из личного опыта:

 

1. Ubiquiti UniFi/PicoStation. Имеется городской хотспот из полусотни UniFi (или перешитых под PicoStation) с самописным порталом авторизации. Для бесплатного хотспота работает вполне приемлемо, но все же есть нарекания:

- нет роуминга, а отсечка по уровню сигнала работает не так хорошо, как хотелось бы;

- нет 5 ГГц;

- из-за особенностей UniFi (контроллер реконфигурирует каждую точку) при значительном количестве точек доступа авторизация клиента на точке может занимать пару минут, это некомфортно;

- иногда слетает или не проходит авторизация (но тут возможно причина не в точках доступа, а в самописном портале);

- оборудование не производится и его почти нет на складах;

Конечно сейчас у Ubiquiti есть устройства посовременнее и получше, например UniFi AP AC Mesh Pro, но мне сам по себе подход Ubiquiti и архитектура UniFi кажется не очень подходящими к моей задаче.

 

2. Mikrotik. В больших масштабах не применял, но на мой взгляд для хотспотов он совсем не подходит. Роуминга нет, RADIUS и EAP очень своеобразные, весьма вероятны проблемы с яблочными устройствами. К тому же я не вижу моделей подходящего форм-фактора: RBGroove глючная и недвухдиапазонная, OmniTik на форуме постоянно фигурирует с различными проблемами, а остальные модели предполагают использование конструктора (бокс для устройства и внешняя антенна).

 

3. Энтерпрайз-точки TP-Link — по сути клоны Ubiquiti где-то 3-5 летней давности с сырым софтом и частично неработающими функциями. Вообщем всерьез не рассматриваю, перечислил только чтобы показать, что знаю про такого вендора.

 

4. SNR-CPE с Wive-NG-mt. А вот тут практика довольно позитивная. Применяли на двух объектах (гостиницах) именно как объектный хотспот, понравилось как все работает. Но нет уличных моделей и скорее всего никогда не будет нормальной поддержки EAP с плюшками.

Тем не менее, пока что я подумываю об использовании ME1 или MD11 в уличном боксе с выведенными наружу антеннами.

 

Еще есть EnGenius — с ним лично не сталкивался, но NAG уже несколько раз рекомендовал обратить на них внимание. Однако на одном из КРОС-ов я их видел в действии (раздавали WiFi в конференц-зале) и как-то совершенно не впечатлило. Наш городской хотспот на UniFi и то работал лучше. Кроме того, они контроллерные и лицензии дорогие, а я предполагаю, что точек доступа потребуется несколько десятков.

[jffulcrum]

Давеча видел решение от Dlink. У них есть программный контроллер, не требующий лицензирования, и новые точки под него (в т.ч. внешние), причем некоторые поддерживают режим MESH, когда на 5 ГГц идет опорная сеть между точками,а на 2.4 принимают клиентов. Всякие каверзные вопросики позадавал про роуминг  - тут все как с UniFi обстоит, про совместимость с гейфонами - сказали что нет проблем даже с последними Х, про 802.1x - не умеют. Про EAP не спрашивал. Смутило, что программный контроллер два года не обновлялся, а железные - обновлялись.

[Urs_ak]

1 час назад, alibek сказал:

- из-за особенностей UniFi (контроллер реконфигурирует каждую точку) при значительном количестве точек доступа авторизация клиента на точке может занимать пару минут, это некомфортно;

Как у вас на UniFi сделано перенаправление на портал авторизации ? Через опцию на контроллере "External Portal Server" ?

 

Кстати, в версиях контроллера >5.8, была замечена опция "Fast Roaming" (beta):

[NewUse]

1 час назад, alibek сказал:

и скорее всего никогда не будет нормальной поддержки EAP с плюшками. 

спросите у разработчика @sfstudio https://forum.nag.ru/index.php?/profile/30112-sfstudio/ но не думаю что это проблема тем более динамикВлан хостапд умеет с незапамятных времён, и ааа клиент на нём давно доведён до ума...

а вот с уличными, возможно засада, как я понял их в скором времени ждать не предвидится...

[sfstudio]

3 часа назад, alibek сказал:

Но нет уличных моделей и скорее всего никогда не будет нормальной поддержки EAP с плюшками.

Чего конкретно нет-то? Опишите на wi-cat.ru каких плюшек не хватает. И причём тут хотспот и EAP. Распишите схему - будет понятно.

 

Экаунтинг в новом софте под новое железо есть. В старое натянуть можно но геморно и не окупиться.

 

В общем распишите у нас в разделе "функционал" - возьмём на заметку. На эту тему вообще случайно нарвался. Так что если что-то хотите увидеть в Wive описывайте у нас ибо собирать хотелки со всей сети точно никто не будет.

 

Более того, запросто может получиться так, что искомое вами уже давно есть, только в UI не вытащено и болтается в ToDo где-нить в полузабытом состоянии ибо оказалось никому не нужно. Опишите свои чаяния - будет повод освежить.

 

Убивают меня люди которые лучше разработчиков знают что будет, а чего не будет. Я сам ещё не определился, а клиенты уже в курсе. =))))) Не гадайте, задавайте вопросы с конкретикой куда и как надо. Задачи вида то, не знаю, что, пока не куда, но может куда-то лет через 100 пригодиться ессно брать в работу сломя голову никто не будет. В сутках всего 24 часа и цели реализовать всё и вся, но абы как и что бы было не стоит. Либо решаем конкретные задачи и делаем это хорошо, либо нечего и 5ю точку мучать. Вот такой подход. Будет спрос и понятные кейзы - бум думать и готовить решение.

 

P.S. Кстати, интересующиеся теперь могут потыкать демоуй https://wi-cat.ru/wive-ng/gui-emulator-wive-ng/ . Собирается прям вот напрямую из GIT прям той же ветки с которой собираются реальные образы. Пока не без шероховатостей (демка всмысле), допилимс.

 

2 часа назад, NewUse сказал:

а вот с уличными, возможно засада, как я понял их в скором времени ждать не предвидится...

Можете написать нам на info[at]wi-cat.ru с примерными объёмами и т.д. Кооперацию никто не отменял, ради 10шт ессно увы стартовать не вижу смысла. А с сотни уже можно начинать разговаривать. Как бы будет заявок в нужном количестве - возьмём в работу. Технически всё реально сделать в сжатые сроки с учётом хоть крайнего севера (ессно ценник в зависимости), хоть подводного монтажа. =)

[sfstudio]

1 час назад, NewUse сказал:

спросите у разработчика @sfstudio https://forum.nag.ru/index.php?/profile/30112-sfstudio/

Плз. всё сюда https://wi-cat.ru/forums/ или на крайняк на support[at]wi-cat.ru по форумам ходить сейчас времени 0,0 да и лички по форумам я либо почти везде повырубал, либо тупо не заглядываю.

 

Если ну уж прям напрямую хочется то sfstudio[at]wi-cat.ru но лучше через офиц каналы выше, тогда запросы точно не потеряются.

 

2 часа назад, NewUse сказал:

динамикВлан хостапд умеет с незапамятных времён

Я вам грил уже раз 5ть. Нет у нас никаких хостапд. Не юзаем мы оные, всё делает драйвер. =) И к WRT мы никакого отношения не имеем тоже. =)))

[sfstudio]

3 часа назад, jffulcrum сказал:

про совместимость с гейфонами - сказали что нет проблем даже с последними Х

Вот с новыми и не будет ни у кого. Ибо теперь яблоко по сути wifi не касается. Все проблемы (99% их проблем) это устройства 11-13г (iphone6* и того же времени некоторые макбуки) с радио на вполне конкретном чипе. Пришлось злобный костыль рожать что бы остальным живущим на той же АП жизнь не портить.

 

Если у кого-то имеются проблемы с яблочниками других серий - значит проблема уже не на стороне яблок. Не более ранние, не более поздние яблоки не имеют каких-либо значимых проблем выбивающихся за рамки разночтений "стандарта" 802.11, и вполне могут быть без проблем учтены софтом на стороне АП.

 

Включая некоторые шероховатости с TxBF vs MU-MIMO на последних Xовых. Т.е. их реализация не нарушает требований "стандарта", просто "стандарт" такой блин... Благо всё правиться.

 

[alibek]

4 часа назад, sfstudio сказал:

Убивают меня люди которые лучше разработчиков знают что будет, а чего не будет. Я сам ещё не определился, а клиенты уже в курсе. 

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

Под плюшками я имел ввиду например следующее - беспроводной клиент подключается к WiFi, точка авторизует его по RADIUS, RADIUS сообщает точке, в какой vlan его засунуть и на какой скорости. Такое есть?

 

7 часов назад, Urs_ak сказал:

Через опцию на контроллере "External Portal Server" ?

Да.

 

7 часов назад, Urs_ak сказал:

Кстати, в версиях контроллера >5.8, была замечена опция "Fast Roaming" (beta):

Я хочу уйти от UniFi.

В UniFi конфигурируется каждая точка, на точке есть ACL с разрешенным доступом, а все остальное заруливается на портал самой точкой. И контроллер обновляет эти настройки при авторизации или изменениях.

При таком подходе есть ряд неудобств.

[Urs_ak]

39 минут назад, alibek сказал:

7 часов назад, Urs_ak сказал:

Через опцию на контроллере "External Portal Server" ?

Да.

Надо делать через встроенный портал (опция "Simple Password"), а там веб-редирект на свой самописный портал.

 

У нас с лета 18-ого сделан проект для 6-ти этажной гостиницы эконом-класса, развёрнута 41 точка доступа UAP-AC-LR по номерам. Проблем с авторизацией абонентов через свой самописный портал нету, авторизует быстро.

[Saab95]

Мы такие сети строим на микротике и все отлично работает - настроили и забыли. Если для помещения, то у микротика есть готовые решения, в том числе и двухдиапазонные. Для улицы не обязательно конструктор и пихать 2 и 5 ггц в одно устройство - есть и SXT в 2ггц, есть и в 5ггц, есть секторные - все есть. Можно брать и строить. Капсман нормально отрабатывает, можно собрать весь L2 в центр и т.п. Другие производители такой гибкости из коробки не предоставляют, одно чего только стоит - это установка оборудования на чужих сетях, когда надо поднять туннель в центр. Умеет так унифай?

[jffulcrum]

10 часов назад, Urs_ak сказал:

опция "Fast Roaming"

Вот как раз она с гомофонами вызывает проблемы

[Urs_ak]

1 час назад, jffulcrum сказал:

Вот как раз она с гомофонами вызывает проблемы

Ну кстати, сотрудник пишет что у них в офисе нормально работает, а проблемы со старыми моделями телефонов.

[slv700]

Для уличного Hotspot c роумингом включая OKC, 802.1 r/k/v, порталом Spash page, авторизацией EAP и открытым доступом, в общем со всем необходимым  для публичного  вайфай доступа подходят двухдиапазонные точки доступа  Cambium Outdoor E500, E501S, E502S. Держат  100+  активных клиентов. Бесплатный облачный и on Premise NMS- контролер доступа.

Успешно эксплуатируются   в сетях вайфай публичного доступа в парках, улицах и площадях во многих городах ( в Украине). 

[sfstudio]

6 часов назад, alibek сказал:

беспроводной клиент подключается к WiFi, точка авторизует его по RADIUS, RADIUS сообщает точке, в какой vlan его засунуть и на какой скорости. Такое есть?

Ну если вам пофигу что при этом заломается миграция можно вланы нарезать и поклиентно. А шейпит один фиг шлюз, а не АП. Так что радиус говорит шлюзу в какую трубу (например HTB) запихать с какой скоростью и нет проблем. 

 

Опять таки причём тут хотспот и EAP ? Если хотспот то endpoint будет например chilli, который умеет в т.ч. поклиетно во вланы заворачивать, бесплатно без SMS. При желании можно на нём и шейпер разрешить и им шейпить, но даже на современном железе это грусть и печаль ибо юзерспэйсное.

 

Грю задачу описываете по человечески со всеми нюансами на wi-cat.ru подскажем как сделать. На уровне хочу странного, ну ой. Тут точно всё подряд никто пилить не будет. Нужно чётко понимать что именно хочется достигнуть, тогда можно работать над решением. Пока каламбур какой-то.

 

6 часов назад, alibek сказал:

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

И? Как это связано с железом для хотспотов или расширением функционала в том месте где уже есть?

 

Более того, если вы не заметили, то NAG и Wi-CAT немного разные компании. Ну так на секундочку. То что мы работали над софтом и железом линейки SNR-CPE не говорит о том, что мы не движемся дальше. Упираться рогом в LowCost End User CPE с нашей стороны никто не планировал и не планирует от слова совсем.

[sfstudio]

14 часов назад, alibek сказал:

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

И при такой схеме уже сейчас нет никаких проблем с реализацией поклиентного шейпинга, изоляции оных и т.д. Нарезка vlan per client или per group тут не очень видно куда впиливается. Если фронтенд чилли поселить на том же шлюзе то вообще никаких проблем хоть влан на клиента хоть влан на группу (и даже без поломки миграции), хоть даже встроенный в него шейпер. Экаунтинг в радиус и ACL там же оно тоже вполне умеет.

 

Лишь бы ресурсов хватало а жрёт оно при полном фарше возможностей мама не горюй, т.е. всяко тащим на шлюз а АП как и написано выше оставляем в роли транспорта с роумингами и прочим.

 

Ещё один плюс такой схемы, что АП в итоге можно любые юзать, хоть те что уже есть у клиента без изменений логики на стороне шлюзосервера вообще. Т.е. нормальное централизованное решение где каждая железка занимается своим делом.

 

Фак конечно уже изрядно протух, но общее представление получить можно http://www.chillispot.org/FAQ.html Более того, почти все коммерческие сервисы авторизации оный умеют.

 

Плюс есть такая заморочка, в некоторых регионах ребята в погонах хотят до кучи net_flow что бы им лили напрямую. Т.е. после чилли ipt_netflow надо и это тоже ресурсы. 

 

Я уже не говорю, что требования эти меняются регулярно. Так что софтшлюз на x86 тут must have, а АП и прочее, как вы правильно сказали должно быть просто надёжным транспортом с нужными плюшками.

[alibek]

2 часа назад, sfstudio сказал:

Опять таки причём тут хотспот и EAP ?

Не причем, это разные задачи.

Хотспот это одна задача.

А транспорт на базе той же беспроводной сети — это задумки на будущее.

То есть будет только одна беспроводная сеть, к которой подключаются клиенты по EAP.

Если это клиенты из списка STAFF — скоммутировать их в VLAN с офисной сетью.

Если это клиенты из списка IOT — скоммутировать их в закрытую служебную сеть с датчиками.

А всех остальных завернуть на контроллер хотспота.

Бонусом будет шифрование WPA2.

[sfstudio]

Ну подключились по EAP в радиусе на шлюзе мы видим как минимум MAC, user/pass, а так же шлюз и IP выдаёт. Кидаем роут  (или разрешаем в FORWARD на шлзе) для этого клиента в нужную подсеть в офис или подсеть датчиков - профит. Тут же прям можеми пошейпить.

 

Проводный сегмент с беспроводным в одну плоскую сеть всё равно делать чревато тем что радио будет заниматься большую часть времени рассылкой броадкаста (а оно на самом низком рэйте летит). Т.е. беспроводный сегмент от проводного один фиг должен быть развязан на L3. А дальше куда пускать и даже какой адрес выдать и в какую подсеть роут кинуть, фаером форвард разрешить уже решает шлюз на основании данных с радиуса (в который ходит AP за авторизацией)  которому известны как минимум mac/ip/user/pass. Всё остальное это сугубо логика шлюза.

 

А вот проблема тут другая. IOT ни о каких EAP на доступе чаще всего не знает. И посему проще сделать 2й MBSSID для IOT с обычным WPA2+PSK с длинным паролем и весь MBSSID запихать в нужный VLAN (делается из рожи на раз). А вот EAP и прочие прелести оставить на 1м MBSSID завёрнутым в другой влан например.

 

Вот вообще не вижу никаких проблем со схемой выделенного SSID для IOT и влана для него. Доступно сейчас, из коробки, бесплатно, без СМС и мегаконтроллеров.

[alibek]

3 часа назад, slv700 сказал:

двухдиапазонные точки доступа  Cambium Outdoor E500

У меня сложилось впечатление, что Камбиум в большей степени ориентирован на БШД.

Ну и насколько я знаю, точки доступа Камбиум сами управляют доступом, переадресацией, управлением скоростью и т.п. под управлением контроллера.

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

У нас же есть свое представление о том, что должен собой представлять хотспот, поэтому нам нужен просто качественный и надежный транспорт WiFi, шлюз/контроллер у нас будет свой собственный.

 

4 минуты назад, sfstudio сказал:

И посему проще сделать 2й MBSSID для IOT с обычным WPA2+PSK с длинным паролем и весь MBSSID запихать в нужный VLAN

На нашем текущем хотспоте (на UniFi) именно так и сделано сейчас.

Но так сделано потому что по другому не получилось.

На мой взгляд RADIUS с поддержкой динамических VLAN (с авторизацией клиента по MAC, логину-паролю или сертификату) будет намного удобнее.

[sfstudio]

11 минут назад, alibek сказал:

На мой взгляд RADIUS с поддержкой динамических VLAN (с авторизацией клиента по MAC, логину-паролю или сертификату) будет намного удобнее.

1 - будут траблы с IOT поэтому хоть застрелись но им отдельный SSID с банальным WPA2-PSK длиной в символов 30.
2 - авторизация по MAC это вообще дурь которая не даёт вообще ничего
3 - динамические влан я вообще не вижу куда тут врулить. IOT поделили за счёт MBSSID, остальные авторизуюттся EAP в радиус по логину паролю, изолируются засовываются в свой влан и летят до шлюза где уже на L3 индивидуально разруливаются. Ну нет тут места для каких-то динамик вланов с которыми до кучи ещё на шлюзе огребёте когда потребуется разобраться с какой-либо новой проблемой внезапно возникшей на каком-нить хитром клиенте. Усложнение ради усложнения это тупик. И даже в этом случае вам никто не мешает авторизовать клиента средствами AP из радиус по средствам EAP а в индивидуальный влан засунуть на уровне шлюза+chillispot. Но вот надо ли?

 

Тут просто уже на сотне клиентов проводных + столько же беспроводных огребёте вышеописанную Ж с броадкастами если тупо будете линковать вланами проводный и беспроводный сегмент. Так что оно тут вот вообще не нужно, максимум уже выше на уровне шлюза, но радиосегмент не должен иметь связности на L2 с проводным. В радио своего мусора хватает.

 

Насчёт первого можете не сомневаться от вообще уже набили люди шишек. Не повторяйте их приключений. IOT в отдельный MBSSID и дело с концом.

[alibek]

6 минут назад, sfstudio сказал:

остальные авторизуюттся EAP в радиус по логину паролю, изолируются засовываются в свой влан

Так это же и есть dynamic vlan assignment.

У меня пока нет проработанного решения, но есть смутно сформулированные хотелки — клиент подключается к публичному хотспоту, вводил свой логин-пароль и попадает не на обычный хотспот с общей для всех авторизацией, а в свою домашнюю или офисную локальную сеть. Тут через L3 не решить, нужен именно L2.

[sfstudio]

13 минут назад, alibek сказал:

Так это же и есть dynamic vlan assignment.

 

Нет у нас это разделение на уровне MBSSID, то что вы хотите это per user. И делалось оно людьми в силу отсуствия возможности на уровне дров изолировать клиентов между собой. У нас такая возможность есть и городить vlan per client нужды по просту нет.

 

13 минут назад, alibek сказал:

У меня пока нет проработанного решения, но есть смутно сформулированные хотелки — клиент подключается к публичному хотспоту, вводил свой логин-пароль и попадает не на обычный хотспот с общей для всех авторизацией, а в свою домашнюю или офисную локальную сеть. Тут через L3 не решить, нужен именно L2.

Это всё делается на уровне чиллиспота, в т.ч. vlan`ы. Почитайте о нём. Никакой EAP тут близко не нужен.

 

Что бы отсечь всякую муть и заставить шифровать данные в воздухе на доступе используем просто обычный WPA2 PSK с паролем как имя сети (табличку на ресепшн и всё). В WPA3 этой проблемы уже нет т.е. там режим шифруем всё при доступе без пароля (на самом деле он всё равно есть просто клиент о нём не знает). Но до WPA3 на клиентских устройствах ещё далеко.

 

Всё остальное делает чиллиспот, он выдаёт адреса, он же умеет засовывать поклиентно во вланы или заруливать в тот или иной сегмент. Там вариантов умотаться. Но всё это уже задача вашего шлюза. Если вы попытаетесь часть этого функционала вынести на сторону АП то прибьёте себя гвоздями к одному вендору и решению, т.к. в 802.11 нет конкретики по реализации оного, значит сиё не стандартно было есть и будет всегда. И совместимости не ждите. А такого ИМХО нужно избегать, даже если кажется что решение будет удобнее.

 

13 минут назад, alibek сказал:

нужен именно L2.

Чёй-то вдруг? NETBIOS нынче мёртв, что там ещё в офисной сети без связности на L2 работать не будет? На худой конец есть proxyarp что один фиг лучше варианта стык в стык. При этом появляется возможность на уровне FW шлюза фильтрануть всё кроме нужного. На L2 разве что городушки ebtables разводить.

 

Если вы действительно решили городить свой шлюз самостоятельно, то ИМХО стоит начать с расписывания взаимодействия оного и сразу избегать таких моментов, плюс искать и реализовывать решения которые не vendor specific. Т.е. избегать использования привязки к каким-то уникальным плюшкам на уровне АП без которых совсем не обойтись и которые не стандартизированы.

 

 

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

 

На уровне FW шлюза и данных из радиуса (ессно на доступе тот самый WPA2 Enterprise EAP) это решается на раз, просто в форварде добавляется необходимый набор правил кому и куда разрешить бегать. А вот с L2 начнуться городухи типа софт бриджига с изоляцией на уровне какого-нить ebtables в них. Горы кривых правил, вместо стройного списка в форварде.

 

Не ну каждый кузнец своего счастья конечно. И всякого рода городушки могут работать и местами даже вполне себе. Но попытки навернуть чего-то эдакого не редко стреляют в ногу.

 

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

 

[alibek]

4 часа назад, sfstudio сказал:

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

Не знал, нужно будет поизучать.

 

4 часа назад, sfstudio сказал:

Если вы попытаетесь часть этого функционала вынести на сторону АП то прибьёте себя гвоздями к одному вендору и решению

Потому я и не выбираю EnGenius/Cambium/Ruckus или даже UniFi.

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

В перспективе такой точкой доступа может быть даже обычная домашняя точка доступа.

 

[sfstudio]

2 часа назад, alibek сказал:

В перспективе такой точкой доступа может быть даже обычная домашняя точка доступа.

 

Домашние точки они тоже сильно разные бывают. То что кто-то налепил лэйбу SMB/ENT оно не стало как-то иначе работать. Впрочем и наоборот бывает. Весь вопрос (в 99% случаев) насколько вендор оздачился отладкой ПО.

 

2 часа назад, alibek сказал:

Не знал, нужно будет поизучать.

Чиллиспот эт вообще такой мегакомбайн специализированный для развёртывания хотспотов. Умеет оооочень многое.

[slv700]

4 часа назад, alibek сказал:

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

В перспективе такой точкой доступа может быть даже обычная домашняя точка доступа.

Это архитектура ( типа клиент-серверная )  10-летней давности, типа все на контроллере, а ТД  -максимально упрощенные легкие  клиенты. Сейчас от нее ушли.  Она имеет много недостатков, главный из которых -сложность в управлении.

Сейчас в тренде безконтроллерная архитектура.  И если есть контроллер , то это не  классический контроллер доступа, а  функционально  по  большей части обычный   NMS, который может быть облачным.

[alibek]

7 часов назад, slv700 сказал:

Это архитектура ( типа клиент-серверная )  10-летней давности

Подобной парадигме — каждый компонент системы специализирован и занимается своим делом — гораздо больше 10 лет. И за это время она не раз подтвердила свою состоятельность.

А вот подход «покупайте наших слонов, это самые лучшие слоны в мире» регулярно появляется у каждого вендора, а затем сливается через некоторое время.

Поэтому облака и контроллерные решения, на которых основана логика сервисов, я вообще не рассматриваю. Если я и выберу контроллерное решение, то для централизованного управления точками, а не для реализации на нем логики.