[kitan]

Необходимо организовать Free Wi-Fi и защищенные Wi-Fi зоны для сотрудников в 30 филиалах одного из российских банков. Требуется бесшовный роуминг, приоритезация трафика и единый центр управлениями для этих точек. Ранее работал с Mikrotik Hotspot для организации Free Wi-Fi, но в этот раз хочется готовое промышленное решение которое будет иметь единый центр управления. Дополнительно, Wi-Fi точки будут располагаться в различных участках IP-сети, единый VLAN выделить для них не получится. На оборудование необходимы российские сертификаты соответствия. Какое решение можете посоветовать?

[nimbo]

заказать у оператора не вариант?

[kitan]

Так мы и есть оператор. Хотим подобрать оптимальный кейс.

[alibek]

Требуется бесшовный роуминг

Действительно требуется 802.11r?

[kitan]

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

[alibek]

Бесшовный роуминг — это именно роуминг и именно бесшовный. Для его работы точка доступа и клиент должны поддерживать 802.11r.

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

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

Если это банк, то можно не заморачиваться, а запросить у интеграторов решение Cisco, и все будут счастливы.

Если поиграть в конструктор, то в качестве железа лично я бы использовал UniFi AP — симпатичные и хорошие. Но штатный контроллер для такой схемы подходит мало, нужно использовать самописный.

[kitan]

Согласен, формулировка с роумингом спорная. Не хотелось бы играть в конструктор с mikrotik и unifi, но и решение Cisco будет дороговато. Может у кого-то есть опыт по работе с отечественным производителем в данной сфере?

[alibek]

Дороговато для банка с 30 филиалами?

Ну тогда даже не знаю, что посоветовать. Только конструктор.

[slv700]

Бесшовный роуминг — это именно роуминг и именно бесшовный. Для его работы точка доступа и клиент должны поддерживать 802.11r.

Бесшовный (seamless)-означает без разрыва соединения по сети по MAC (L2) и IP (L3). Роуминг ( roaming ) или handover бывает разных типов, например самый распространенный Opportunistic Key Caching ( OKC) - это расширение стандартного 802.11-2007 PMK cashing роуминга, а также 802.11r( стандарт 802.11-2008). Так что клиент при роуминге не обязательно должен поддерживать 802.11r и при OKC клиент вообще не обязан ничего поддерживать кроме EAP ( 802.1x) аутентификацию.

Время перерыва связи ( по радио) handoff при роуминге 802.11r - до 50 мс, OKC- до 100 мс. Например, VoIP нормально работает при handoff до 150 мс, Viber/Skype video - до 300 мс, голос -больше.

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

Бесшовный роуминг нужен чтобы

1) при смене точки доступа не было повторной аутентификации клиента

2) клиент при перемещении плавно переключался на новую точку (при снижении уровня сигнала ниже заданного уровня) без дисконнекта с сетью , - без дерганий и метаний между точками и исключения возможности подключения к точкам доступа соседних сетей с более мощным и сигналом.

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

Для роуминга обязательно, чтобы у точек доступа был одинаковый SSID. Частотные каналы могут ( должны ) быть разные.

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

Не все вайфай точки доступа поддерживают роуминг. Микротик НЕ поддерживает ни один из возможных типов seamless роуминга ( в том числе через контроллер Capsman). Более того, Микротик НЕ поддерживает защищенный доступ WPA- Enterprise ( в частности , обязательное EAP PEAP/TTLS).

Cтарый UniFi ( не АС) поддерживал Zero handoff roaming ( вcе AP на одной часототе) и поэтому это работало хреново. UniFi AC роуминг НЕ поддерживает.

Если это банк, то можно не заморачиваться, а запросить у интеграторов решение Cisco, и все будут счастливы.

Cisco AP c контролером поддерживает OKC, 802.11r и др. типы роуминга, но очень дорого.

Если поиграть в конструктор, то в качестве железа лично я бы использовал UniFi AP — симпатичные и хорошие. Но штатный контроллер для такой схемы подходит мало, нужно использовать самописный.

Повторяю, UniFi AP не поддерживают seamless роуминг. Ничего "симпатичного" там нет. Например, новый Unifi АС сделан на Broadcom, старый - на зоопарке х.з чего и этим обьясняются постоянные и бесконечные проблемы со всеми поколениями UniFi( в чем они заключается- отдельный вопрос). Если для UniFi сделать "самописный"контроллер наподобие Hotspot Gateway на Микротике Capsman, то это будет проприетарный "псевдороуминг" c одним достоинством -не требуется повторная аутентификация при смене точки доступа, но с разрывом IP соединения ( то есть бесшовности нет), перерывом связи 1-5 сек и другими неприятными "чудесами" при плотном размещении точек доступа ( все точно также плохо как этот типа "роуминг" работает на Микротик).

[slv700]

Так мы и есть оператор. Хотим подобрать оптимальный кейс.

Ставьте Cambium E400 - двухдиапазонная 2.4 Ггц и 5Ггц ( АС) Enterprise точка доступа с band steering. Поддерживает аутентификацию WPA2-Enterprise, роуминг Pre-autentification,OKC, 802.11r и многое другое, нужное для корпоративных и публичных ( гостевой доступ) сетей. Контроллер для роуминга не нужен. Управление сетью - NMS облачный или бесплатный софт под Linux.

[Vladimir-nag.ru]

Например, новый Unifi АС сделан на Broadcom,

Вторая волна линейки AC уже идет на Qualcomm

[slv700]

Например, новый Unifi АС сделан на Broadcom,

Вторая волна линейки AC уже идет на Qualcomm

Идет но не пришла, и когда придет - х.з

[sfstudio]

1) при смене точки доступа не было повторной аутентификации клиента

 

Будет повторная аутентификация, по короткой или длинной процедуре вот и вся разница.

 

2) клиент при перемещении плавно переключался на новую точку (при снижении уровня сигнала ниже заданного уровня) без дисконнекта с сетью

 

Дисконнекта с чем? Дисконнет физически будет на клиенте как не крути. Если вы не видете это по индикации и соединения на L3 не рвуться - это не значит что его нет. Никакого плавного перемещения там не существует. Один фиг клиент должен отвалиться на какое-то время что бы мигрировать, а вот насколько быстро он это всё сможет сделать уже зависит от поддерживамых им и АП плюшек. А сделать надо относительно быстро что бы таймауты соединений на уровне таблицы соединений клиента и шлюза не истекли как минимум.

 

Ну и обычно хрен клиенты чего поддерживают по человечески. Так что все фаст роуминги и 802.1x при внедрении могут аукнуться не кислым секисом. Уже столько насмотрелся в разных связках...

 

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

 

Вы опять? Я на вас потратил несколько дней что бы до вас донести, что это зависит исключительно от прямости реализации логики на стороне клиента, и никак не связано с его умением K/R/ЗЮ. Если клиент кривой то ему будет наплевать что там умеет ваша АП и если ему взбредёт в голову ринуться на орущую в ухо открытую сеть - он запросто это сделает не смотря ни на какие плюшки и никакие протоколы. Тоже насмотрелся и вижу регулярно на ведроидах (увы самое распространённое таки).

 

Для роуминга обязательно, чтобы у точек доступа был одинаковый SSID. Частотные каналы могут ( должны ) быть разные.

 

Роуминг может быть и между точками с разными SSID как таковых препятствий к этому нет. Т.е. вообще нет кроме того что опять таки клиент должен эти SSID знать и софт на нём и на АП должен уметь поддерживать такую схему, что в реальном мире проблематично встретить из коробки, но вполне себе работает в т.ч. с 802.1x.

 

Не все вайфай точки доступа поддерживают роуминг. Микротик НЕ поддерживает ни один из возможных типов seamless роуминга ( в том числе через контроллер Capsman).

 

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

 

Прозрачность обеспечивают далеко не K/R. Прозрачность и неразрывность (именно неразрывность) на уровне приложений обеспечиватся dhcp с выделением ip по хэшу мак адреса (в простом случае), или вообще из единой БД юзая связку BD+Radius+DHCP (то что обычно делают хвалёные контроллеры) что бы при миграции между AP оно не прыгало и на клиенте таблица соединений не дропалась. Но и тут как повезёт ибо link beat один фиг будет в момент переключения (ещё раз грю, если от вас его скрыли, эт не значит что его нет), а при этом клиенты часто дропают адрес с интерфейса + таблицу соединений и лезут по полной заново просить адрес у dhcp причём клиент может пройти по короткой процедуре и уметь все роуминговые плюшки, но вот на уровне connection manager (ну например в ведроиде) запросто может жить (и часто живёт) такая засада. И что толку что он потратил не 150мс, а 50мс если потом на несколько секунд выпал в осадок на получение ip занова ещё и с дропом соединений?

А вот нормальные клиенты при link beat при переходе с между АП с одинаковми ssid не пытаются отрубить себе ноги и максимум на всякий просят продление лизы, или же (те что по кривее) требуют новый адрес, но получив такой же (помним о динамической привязке к маку или логину если 802.1x или к тому и тому или ещё чему неизвменному) корректно это отрабатывают не сбрасывая таблицу соединений. А таймауты на соединения в современных осях и приложениях обычно такие что и 3 секунды провисит и не порвётся, дальше будет уже либо на уровне протокола (если поверх tcp работает) или на уровне приложения (если поверх udp) перезапрос данных, или частичный дроп с кваком в динамик, но само соединение выживет.

 

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

 

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

 

Мы же с вами это вроде уже всё обсудили? Зачем опять народу по ушам ездить?

 

P.S. Что касается банка. У них есть ИТ отдел, и начните с разговора с ними по тому какие бумажки надо будет на всё это. Потом выясните у кого есть все эти бумажки из вендоров и с кем вас туда вообще пустят. Роуминг это будет самая маленькая из ваших проблем. =)

 

P.SS. За состоянием дел с поддержкой K/R на реальном клиентском железе можно подглядывать тут http://forum.nag.ru/forum/index.php?showtopic=108990 =) Грустно там всё.

[sfstudio]

Бесшовный роуминг — это именно роуминг и именно бесшовный. Для его работы точка доступа и клиент должны поддерживать 802.11r.

 

802.11r это Fast BSS Transition с бесшовностью оно не связано никак увы. Только сокращение фазы аутентификации, т.е. ускорение перемещения на низком уровне. Но вы паравы в том, что насколько оно получиться бесшовно и корректно на 99% зависит от клиента. Т.е. нет никакого толка от быстрой реаутнетификации или возврата назад если на клиенте будут дропаться все соединения простопо по link beat (как из-за ошибок реализации происходит во многих ведроидах и даже в каноничных Linux типа Mageia, благо в последних правиться за 2 секунды и никаких разрывов и без всяких K/R =))).

[kitan]

Выбор нужного решения продолжается. Большое спасибо sfstudio за разъяснения по поводу роуминга. Более внимательно изучив ТЗ я понял, что 802.11r не обязателен. Другая особенность, есть условие:

Wi-Fi сеть должна обеспечивать однородное радио-покрытие за счет автоматической калибровки мощности антенн, равномерного разделения среды радио-покрытия по каналам вещания, автоматического или ручного выбора наиболее свободного частного канала. Как это сделать стандартными способами на Mikrotik, без скриптов , я не нашел, , н-р. функционал CAPsMAN такими возможностями не располагает. По поводу Cambium E400 жду информацию по цене, но есть ощущение ценник будет приличным. Так что, если есть предложения по поводу оборудования - сообщайте.

[sfstudio]

См SNR-CPE-MD1 дёшево и сердито. Вы с документами определились? Грю не железо тут будет проблемой..

[kitan]

С документами проблем быть не должно. В данном случае будет осуществляться услуга на продолжительный период времени. Из бумаг как минимум российский сертификат соответствия. Оборудование передаваться в собственность не будет. Кроме SNR есть ещё варианты? Желательно с возможностью подключения контроллера для централизованного управления всеми зонами Wi-Fi.

[sfstudio]

Если надо типа контроллер то SNR пока отпадает. Пилить ещё у нас не перепилить на эту тему.По чужому увы не подскажу ибо не могу дать никаких гарантий.

[nkusnetsov]

kitan, вам пиар-бот-продавашка камбиума столько написал, так старался...

Проблема в том, что камбиум не умеет "автоматической калибровки мощности антенн, равномерного разделения среды радио-покрытия по каналам вещания", что бы вам не врали.

Изменено 22 сентября, 2016 пользователем nkusnetsov

[sfstudio]

Как-то пропустил сообщение.

 

Wi-Fi сеть должна обеспечивать однородное радио-покрытие за счет автоматической калибровки мощности антенн,

 

Наверное за счёт автоматической регулировки Ку PA/LNA по RSSI FEEDBACK и вообще AGC ? Ну у нас оно штатано заложено в чип и дрова, я про SNR.

 

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

 

Доступно 2 алгоритма:

1) по числу АП

2) по уровням шума

 

Оба алгоритма так же учитывают репорты загрузки канала (BSS QLOAD).

 

Так что если централизованное управление не является блокирующей функцией - напишите на wifi@nag.ru вам более подробно расскажут + раздел выше профильный. Ну и в тест дадут без проблем.

 

kitan, вам пиар-бот-продавашка камбиума столько написал, так старался...

Проблема в том, что камбиум не умеет "автоматической калибровки мощности антенн, равномерного разделения среды радио-покрытия по каналам вещания", что бы вам не врали.

 

Правда? Печально чего-то у них... Вот те и ынтырпрайз.

[slv700]

автоматической калибровки мощности антенн,

Видимо под этим все же понимается автоматическая регулировка мощности Tx точек доступа с целью обеспечения равномерности покрытия и/или ATPC клиента. Что касается Tx AP я лично не вижу в ней особой востребованности, отрегулировать Тx можно сделать один раз при инсталляции точек доступа. Какая то автоматика в этом IMHO не нужна, точки же не двигаются, окружающая обстановка не меняется. В чем отсутствие этой фичи является проблемой?

Что касается ATPC, то необходимоть регулирования мощности клиента в вайфай точках доступа также сомнительна. Я в этом также не вижу никаких проблем даже при высокой плотности размещения точек , потому что клиент обычно маломощный и в аплинк не создает заметных помех соседним точкам доступа поскольку не генерирует высокий аплоад трафик. И вообще как можно ограничить мощность клиента со стороны AP, есть ли такая процедура в стандарте?

Тем не менее реализация этой фичи в плане регулировки AP Tx находится в роадмап Камбиум.

Что подразумевается под "равномерным разделением среды радио-покрытия по каналам вещания"? Это одно и то же что и "автоматический выбор наиболее свободного частного канала"? Если это автоматический выбор частотного канала AP, то в cnPilot E400/500 есть Auto Channel Selection при старте AP и по расписанию по критерию минимальных помех и загрузки канала соседними мешающими точками доступа, обеспечивающей максимум пропускной способности AP.

[kitan]

kitan, вам пиар-бот-продавашка камбиума столько написал, так старался...

Проблема в том, что камбиум не умеет "автоматической калибровки мощности антенн, равномерного разделения среды радио-покрытия по каналам вещания", что бы вам не врали.

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