Роуминг (миграция клиентов между ТД) в Wi-Fi сетях — Часть 4 — Handoff
HandOFF дословно — передавать. Однако в контексте 802.11 я бы скорее перевёл бы этот термин (применительно к АП) как "руки прочь".
В третьей части цикла мы рассмотрели такую процедуру как handover, которую выполняет клиент для миграции внутри wi-fi сети.
А что делать, если клиент по какой-то причине отказывается инициировать переход? А если клиент вообще не умеет самостоятельно мигрировать?
Вот тут к нам на выручку придёт механизм HandOFF. Как обычно в 802.11, этот механизм не является частью стандарта, не обязателен к реализации и вообще не предусмотрен. Сюрпрайз!
Настройки HandOFF в Wive-NG
Ну что же, нам не привыкать.
В чём смысл? А смысл прост, АП мониторит уровни от клиентов, и при достижении минимального порога посылает DEAUTH сигнал клиенту.
Клиент благополучно «слетает» с ТД, а дальше…
А дальше выполняет всё то, что мы описывали в первой части. Чаще всего при этом сразу же будут оборваны все соединения локальных приложений. Т.е. так называемой бесшовностью тут не пахнет. Исключение разве что клиенты с модифицированной логикой обработки события прихода DEAUTH фрейма и обработка его как сигнал к форсированию логики handover. К сожалению этот вариант встречается не очень часто, например так умеет радио от Qualcomm (описывал опцию в соседней статье, см опцию gEnableHandoff).
Кто-то разумно заметит, что DEAUTH фрэйм может быть послан с несколькими десятками reason code. Зачем слать StaLeave если можно использовать что-то более «мягкое».
Ну во первых потому что ничего более мягкого по сути и нет. А во вторых в 802.11 как обычно, даже если в стандарте это есть, совсем не факт, что по факту эти reason коды будут обработаны клиентом, т. е. вообще будет присутствовать реализация обработки этих reason`ов.
Как пример вот что об этом говорит CISCO. Смотрим табличку https://supportforums.cisco.com/t5/wireless-mobility-documents/802-11-association-status-802-11-deauth-reason-codes/ta-p/3148055
Нас интересует 802.11 Deauth Reason Codes. Слегка офигиваем от NOT SUPPORTED и успокаиваемся.
Справедливости ради, стоит заметить, что в 802.11 есть нужный reason за номером 12 - Disassociated due to BSS Transition Management. Однако даже CISCO оный ризон не поддерживает. И вообще по факту мне не удалось найти клиента который бы его обрабатывал корректно.
Чаще всего клиент его обрабатывает так же как и 8 (sta leave) или же вовсе игнориурет, и в итоге получаем клиента который до упора будет считать, что подключен к ТД, в то время как ТД считает, что клиент обработав сигнал ушёл на соседнюю АП.
В результате, даже если клиенты умеющие 12 reason и существуют в природе, мы всё равно вынуждены, ради совместимости, слать всё тот же Sta Leave т. к. ТД не знает, что именно реализовано в клиенте.
Так же нет никаких механизмов при этом сказать клеинту куда нужно мигрировать и нужно ли вообще.
Проще говоря мы просто выпинываем (kick out) клиента с ТД и надеемся, что клиент переключиться на более подходящую ТД, что не всегда так. А многие клиенты первым делом пытаются вернуться назад. Или вовсе впадают в ступор и ждут пока пользователь снова ткнёт «подключиться». Благо последний вариант всё же редкость. А против возвращенцев можно использовать временную блокировку на уровне probe/assoc/auth (как например это сделано в Wive).
Подведём итог. Handoff в 802.11 это по сути простое спинывание клиента с ТД в надежде, что клиент перейдёт на соседнюю ТД с лучшими параметрами. Процедура инициируется ТД, что даёт возможность более гибко, исходя из различных параметров линка (но чаще всего тупо из уровня с которым АП слышит клиента) вынуждать клиента мигрировать (не всегда успешно и почти всегда с потерей соединения приложениями).
Безусловно, это лучше чем ничего. И если не стоит задачи получить именно бесшовность, то можно смело использовать для балансировки нагрузки и обеспечения максимальной производительности сети. И/или как подстраховку в бесшовной сети для клиентов не умеющих мигрировать самостоятельно. Правда в этом случае придётся выбрать порог срабатывания настолько низкий, что бы не затронуть нормально мигрирующих клиентов. Что в свою очередь сильно уменьшит эффект от такой балансировки.
В ближайшее время постараюсь расписать как handover реализован у нас (в Wive-NG-MT), как его настроить в зависимости от задачи и т. д.
P.S. По традиции немного веселья из мира Enterprise $). Описание настройки handoff для рукуса https://support.ruckuswireless.com/answers/000002277. Они называют это smart roam. Как всегда в мире Enterprise любой костыль выдаётся за мегадостижение, а т.к. сейчас всё SMART то и костыль должен быть Smart. Так же по ссылке есть рекомендации по отладке роуминга, которые сводятся к обновлению софта (видимо для поддержки RRM) и настройки агрессивности роуминга на клиенте (говорил в первой части о этой опции). Ну и если совсем не помогло, включаем smart roam. =) Ну и обилие опций (аж одна штука) поражает воображение. =)
