Wi-Fi roaming

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

Для начала стоит определиться с тем, как вообще происходит соединение в wi-fi. Точнее, что именно ему предшествует.

Первое, что мы должны сделать – это выяснить, какие точки доступа (далее , access point – AP) ведут вещание. Данная процедура может быть осуществлена двумя способами:

1) активное сканирование
2) пассивное сканирование.

Процедура активного сканирования сама состоит из нескольких фаз:
1) Смена канала
2) Посылка probe request
3) Ожидание ответа

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

Сканирование одного канала (включая ожидание ответа) занимает около 20мс. Так, например, активное сканирование 2.4ГГц диапазона, доступного в РФ (1-13 каналы), займёт 260мс.

Сканирование всего 5ГГц диапазона, доступного в РФ (36-48, 52-64, 132-144 , 149-165), – 960мс.

Понимание этого будет важно в будущем. Потому обязательно следует запомнить эти цифры.

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

Вариант пассивного сканирования сводится к прослушиванию эфира на предмет маяков, которые рассылает AP (обычно раз в 100мс). Никакие запросы в этот момент клиент не посылает. Это крайне важно понять и запомнить.

Т.е., нам нужно опять-таки перебрать все каналы, на каждом находиться и слушать эфир минимум 100мс (на самом деле больше, чтобы гарантированно услышать все AP, ведущие вещание).

Исходя из этого мы можем посчитать время, затрачиваемое на такой вариант сканирования – оно будет минимум в 5 раз больше (100/20), нежели в активном режиме. В 2.4ГГц – 1300мс, в 5ГГц – 4800мс.

Казалось бы, такой режим не имеет права на существование, т.к. в разы уступает варианту активного сканирования. Но это только кажется. 😉

Эти 2 варианта доступны нам, когда клиент ещё не подключен к AP.

Если мы подключены к AP, то нам становится доступен ещё один – третий способ определения того, какие AP ведут вещание. А именно, мы можем послать текущей AP, к которой подключены, запрос neighbor report request, используя протокол 802.11k radio resource management (RRM). В ответ мы получим как минимум список соседних AP.

К сожалению, этот протокол поддерживается, на текущий момент, лишь небольшим числом AP. Хорошая новость в том, что Wive-NG-MT имеет поддержку RRM. Подробнее о RRM мы поговорим при рассмотрении средств ускорения миграции в сетях 802.11. Пока просто запомним, что такой механизм у нас есть, и он, в отличии от сканирования, не требует остановки передачи данных с текущей AP, а также занимает минимум эфирного времени.

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

Модификация добавляет в схемы сканирования ещё 2 шага к уже имеющимся.

А именно:
1) перед сменой канала мы должны перейти в режим PSM (Power Saving Mode), что заставит текущую AP начать буферизацию данных в сторону нашего клиента;
2) переключить канал и выполнить один из вариантов сканирования, описанных выше, вернуться на свой канал;
3) выйти из PSM режима, после чего AP очень быстро должна сгрузить нам данные.

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

Для пассивного режима существует исключение. Если нам требуется получить данные только об AP на том же канале, на котором работаем и мы, то необходимость в шагах 1 и 3 отпадает, как и переключение канала. Как результат, в пассивном режиме мы можем получать данные о соседних AP, работающих на том же канале, без остановки передачи данных с текущей AP. Это очень полезное свойство пассивного режима.

Итак, используя один или все методы, мы получили данные об AP, ведущих вещание. Что дальше?

А дальше мы должны выбрать кандидата для подключения.

Обычно это происходит просто банально выбором AP с максимальным уровнем и SSID, совпадающим с выбранным пользователем. Различия тут будут лишь при использовании каких-либо дополнительных механизмов. Например, band preffered или 802.11r, который добавляет, кроме SSID ещё поле MDIE. Но об этом в следующих статьях.

Как только кандидат определён, мы посылаем ему probe req с указанием MAC клиентского устройства, т.е. такой целевой probe запрос. Во-первых, на этом этапе мы проверяем готова ли эта AP нас принять и/или жива ли она вообще, во-вторых, получаем дополнительные данные о режимах работы (алгоритм аутентификации, алгоритм шифрования).

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

Время на фазы ассоциации+аутентификации (в случае, если всё прошло без проблем) в режиме WPA2 PSK составляет около 110мс.
Для режима WPA2 FT-PSK (с использованием 802.11r) время сокращается примерно до 10-20мс.

WPA2 802.1x (WPA Enterprise) без использования FT (802.11r) или OKC (opportunistic key caching) зависит от загруженности radius сервера, к которому AP должна обращаться, чтобы выяснить, пустить или не пустить пользователя. В особо тяжёлых случаях может занимать секунды.

При использовании WPA2 802.1x (WPA Enterprise) + FT/OKC время сокращается примерно до тех же 10-20мс, что и в режиме FT-PSK.

Опять-таки, хорошая новость для пользователей Wive-NG-MT. Мы умеем 802.11r для всех режимов, что гарантирует минимальное время, затрачиваемое на аутентификацию.

Но важно не это. Важно, что фаза аутентификации, на фоне фазы сканирования во всех случаях, кроме голого WPA Enterprise без FT/OKC, достаточно короткая, чтобы добавить проблем с миграцией, или чтобы пользователь заметил этот момент.

Банальное сканирование 2.4ГГц диапазона – 260мс. А если нужно оба диапазона (радиомодуль в клиенте обычно один), то это уже все 260мс + 960мс = 1220мс в лучшем случае при активном сканировании.

Плюс есть ложка дёгтя. Для работы механизмов FT/RRM (802.11r/k) требуется их поддержка как на клиенте, так и на AP.

По факту же, AP, умеющих эти протоколы, в SOHO сегменте почти не наблюдается, а клиентов с их поддержкой – вообще минимум. Из более-менее массовых устройств, это свежие Samsung Galaxy S и A серий, а также свежие устройства от Apple.

Проверить, умеет ли ваше устройство хотя бы один из этих протоколов (замечу, один другого не заменяет), можно косвенно, попытавшись найти ваше устройство на сайте Wi-Fi Альянса и убедиться, что он прошёл сертификацию по программе “Voice-Enterprise: Voice quality and bandwidth management tools for the enterprise”.

Подробнее: https://www.wi-fi.org/discover-wi-fi/wi-fi-certified-voice-programs

Однако, нахождение устройства в списках сертификации не гарантирует фактическую работу (часто ломают после первых же обновлений). И наоборот, отсутствие устройства в списках не говорит о том, что оно 100% не умеет 802.11k/r. Однако, если у вас устройство под Android и его нет в списке программы сертификации, то это 99%, что устройство не умеет ни K, ни R.

Напомню, что Wive-NG-MT умеет 802.11 K/R, хотя мы и не проходили сертификации у альянса.

Исследование CISCO стадии сканирования в процессе миграции и использование 802.11k (RRM) для сокращения этой фазы https://www.cisco.com/c/en/us/td/docs/wireless/controller/technotes/8-0/iPhone_roam/b_iPhone-roaming.html на примере iphone6

Band steering глазами инженера
Band steering глазами инженера

«Технология» Band Steering. Это необходимое для понимания работы миграции в Dual Band сетях отступление.

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

Поясню. На заре появления 802.11a, т.е. варианта 802.11, работающего в 5ГГц диапазоне, никто (как обычно) не задумывался о совместном использовании двух диапазонов, и о возникающих проблемах. В итоге вся логика, используемая на клиентах для 2.4ГГц, плавно перекочевала в 5ГГц.

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

Т.к. «стандарт» 802.11 не требует никакой специальной логики для dual band сетей, то выбор осуществляется просто по уровню сигнала (RSSI).

Но тут существует несколько моментов:
1) чем выше частота — тем выше затухание сигнала с отдалением от передатчика
2) чем выше частота — тем выше затухание в преградах

Т.е. при той же мощности передатчика (что на практике зачастую именно так) мы крайне часто, даже находясь в одном помещении, будем иметь ситуацию, когда RSSI в 5ГГц диапазоне будет заметно ниже. И наш клиент, несмотря на то, что умеет 5ГГц, будет стремиться соединиться в 2.4ГГц.

Проблема усугубляется с ростом расстояния от AP.

Почему это, собственно, вообще проблема? Какая, казалось бы, разница, в каком диапазоне будет работать клиент.

Тут всё просто. В 2.4ГГц очень тесно. В том смысле, что нет ни одного непересекающегося канала для полосы 40МГц (если посмотреть на спектр, который, как известно, не заканчивается резким обрывом). А 80МГц (и более) полосы вообще не доступны.

Плюс уже работает море устройств, не только wifi, и в т.ч. у соседей. Всё это приводит к значительному падению SNR (соотношению сигнал/шум). А именно SNR, а не RSSI, важен. Т.е., можно орать сколько угодно громко, но если рядом соседи будут кричать со сравнимыми уровнями, то клиент просто не сможет разобрать, что ему пытаются сказать.

В 5ГГц всё иначе. Диапазон более чистый, т. к. устройств там не так много, и в основном это такие же wifi устройства. Также, заметно более низкое влияние оказывают соседи, т.к. заметно выше затухание сигнала в преградах (читай стенах). Т.е., SNR даже при заметно более низком RSSI будет заметно выше, а передача данных быстрее и стабильнее. Плюс, доступна как минимум в четыре раза большая полоса (в случае с РФ), нежели чем в 2.4ГГц.

С точки зрения логики и здравого смысла, а также физики, имеет смысл пытаться использовать 5ГГц диапазон, если клиент его умеет, даже если уровень сигнала от конкретной AP заметно ниже, чем от неё же в 2.4ГГц.

И вот тут мы вспоминаем, что клиентские устройства у нас поголовно “тупые” и выбирают, куда будут соединяться, исключительно ориентируясь в RSSI.

Т.е. при одинаковых SSID в обоих диапазонах, большинство dual band клиентов банально будет использовать грязный и узкий 2.4ГГц диапазон, вместо того, чтобы работать в 5ГГц.

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

Настройка band preffered на картах Intel
Настройка band preffered на картах Intel

Настройка band preffered на картах Intel

И такие клиенты есть. Например, многие радиокарты от Intel позволяют выбрать preffered band (предпочтительный диапазон). Плюс большинство радиокарт в ПК и ноутбуках позволяют просто отключить поддержку того или иного диапазона, что также можно использовать для решения проблемы. Обычно все эти настройки доступны в настройках драйвера (Windows) или на уровне wpa_supplicant (Linux).

С мобильными устройствами в виде смартфонов дела обстоят иначе. В 99% случаев нет не то что band preffered, но и даже возможности банально отключить поддержку 2.4ГГц диапазона. И именно с ними проблема встаёт в полный рост.

Казалось бы, проблема решается элементарно, путём внесения в следующую итерацию «стандарта» и сопутствующих спецификаций требования реализации логики «preffered band» для всех клиентов, претендующих пройти сертификацию на совместимость с очередным 802.11AN/AC/AX и т.д…

К сожалению, Wi-Fi альянс считает иначе, поэтому требования не было и нет. Т.е. с 1999 года, когда был представлен вариант 802.11a «стандарта» wi-fi, проблема хоть и была выявлена, но никаких действий для её решения ни со стороны WiFi Aliance, ни со стороны большинства производителей клиентского оборудования, сделано не было.

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

Но это лирика. Вернёмся к Band Steering.

Т.к. Wi-Fi яльянс решил проблемой не заниматься, пришлось производителям беспроводных решений изобретать свой велосипед.

Первыми на лоне решения этой проблемы была Meraki. Именно они предложили первый в своём роде костыль и назвали его Band Steering https://documentation.meraki.com/MR/Radio_Settings/Band_Steering_Overview

Наглядное пояснение как работает band steering от Meraki
Наглядное пояснение как работает band steering от Meraki

Основной смысл на тот момент заключался в том, что для нового клиента мы не сразу начинаем отвечать на probe request при активном сканировании и на стадии предшествующей ассоциации в 2.4ГГц диапазоне. А поставим клиента на hold и будем ждать несколько секунд, пока либо клиент не подключится к 5ГГц модулю, либо ничего не произойдёт, и тогда мы будем считать, что клиент у нас умеет только 2.4ГГц, и тогда мы его пустим.

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

Ок, подумали в Meraki и решили расширить логику. А давайте, AP будут слушать все probe req для всех AP от клиента, а не только для себя, и на основании этих данных мы сможем достаточно достоверно определить (еще до подключения клиента), умеет ли клиент 5ГГц, и если умеет, то вообще не отвечать на probe этому клиенту в 2.4ГГц. Тем самым, заранее сможем определить куда пускать, а куда нет.

И это был прорыв… Подход сработал (ну почти), это позволило даже как-то сожительствовать band steering совместно с бесшовным роумингом и всё было прекрасно, пока…

Пока в один прекрасный день, параноики из Apple и Google не задумались о том, что ведь на основании прослушивания эфира можно отслеживать положение того или иного устройства по mac в probe. И просто начали рандомизировать MAC адреса в probe запросах.

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

Плюс, клиенты почти поголовно научились использовать фоновое сканирование, а там на стадии сканирования вообще никакие probe не шлются, а значит клиент в любом случае будет видеть оба диапазона, и “спрятаться” от него не выйдет. И опять-таки, в лоб сравнивая RSSI, будет пытаться соединиться в 2.4ГГц.

Хорошо, сказали Meraki, раз решить проблему теперь исключительно на уровне probe не удаётся, давайте будем, как последний барьер, использовать assoc/auth req. Да, это не решает проблем с задержками при подключении/миграции, но позволяет хотя бы большую часть клиентов насильно заставить соединиться в 5ГГц.

Вот на этом уровне реализация Band Steering остановилась.

Конечно существуют и расширенные реализации, которые например разрешают клиентам переключаться в 2.4ГГц при падении уровня (как в Wive) или могут насильно спинывать (слать DEAUTH что приведёт к обрыву связи и с определённой долей вероятности переключения клиента на другой диапазон) клиента с 5ГГц диапазона при падении уровня ниже порога (как у MTK), но основной смысл от этого не меняется.

По факту, применять Band Steering сейчас имеет смысл разве что на хотспотах, где не критично, что часть клиентов получит проблемы, и где нет возможности использовать разные SSID для разных диапазонов, заставляя административными мерами пользователей с dual band устройствами использовать 5ГГц.

Во всех остальных случаях (особенно, когда строится сеть для прозрачной миграции) от использования Band Steering следует отказаться.

Исходя из этого, если на клиенте нет возможность задать приоритетный диапазон – стоит воспользоваться вариантом с разными SSID для разных диапазонов. И в самом крайнем случае – Band Steering. А если вы строите сеть с прозрачной миграцией, и ключевым аспектом является именно миграция, то band steering строго противопоказан.

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

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

The cat handover

Хэндовер (англ. Handover) — в сотовой связи процесс передачи обслуживания абонента во время вызова или сессии передачи данных от одной базовой станции к другой.

Вот мы и подобрались непосредственно к миграции. В т.ч. в случае так называемого бесшовного роуминга.

Попробуем дать определение этой процедуре применительно к сетям 802.11 (да-да, в 802.11 как всегда всё наизнанку, привыкайте).

Handover — процедура миграции между точками доступа, инициируемая и осуществляемая клиентом исходя из определённых (одному ему известных), не регламентированных “стандартом” критериев.

Самое важное в этом определении – то, что именно клиент инициирует процедуру перехода, и именно он решает когда, куда, как и по какой причине он решил мигрировать.

Когда клиент запускает процедуру handover? На этот вопрос нет однозначного ответа, т. к. «стандарт» 802.11 не определяет ни самой процедуры, ни критериев.

В самом простом (однако в самом часто встречающемся) случае происходит буквально следующее:

При каждом возникновении события RSSI changed происходит проверка уровня сигнала. И если сигнал низкий (обычно на клиентах низким считается RSSI < -75dB), то клиент:
– запускает процедуру сканирования,
– просматривает данные фонового сканирования, выполненного недавно,
– проводит опрос текущей станции по RRM на предмет наличия соседей с более высоким (обычно используется дельта порядка 5-10dB) уровнем сигнала. Собственно уровень сигнала в данном случае и является критерием выбора кандидата.

Также могут использоваться и другие критерии (например, драйвера Qualcomm для каждого кандидата начисляют очки исходя из данных загруженности, поддержки WMM, совпадения MDIE и др.). Пороги срабатывания handover могут быть динамическими или форсировать запуск handover исходя из оценки каких-либо критериев (например, ситуация, когда уровень и сейчас с большим запасом, но рядом есть точка доступа с уровнем многократно выше).

Однако, чаще всего критерий ровно один — падение уровня на текущей AP ниже порогового значения, которое чаще всего задано как -75dB.

Опять-таки, т. к. требования со стороны «стандарта» не определены, каждый чипмэйкер реализует это по-своему.

Настройка агрессивности роуминга у Intel

Зачастую нет даже регулировок порога срабатывания на клиенте. За исключением, разве что Intel`а, который традиционно предоставляет такую возможность в своём драйвере, называя её “Агрессивность роуминга“. Эта крутилка меняет частоту фоновых сканирований и порог, по которому будет инициирована процедура миграции.

Многие производители клиентских устройств вообще не заморачиваются и не включают поддержку handover при сборке (благо, сейчас почти всегда в SDK как минимум этот механизм включен по умолчанию).

Но вернёмся к вопросу.

Когда кандидат для миграции выбран, мы попросту инициируем новое соединение с ним, проходя все те же этапы, что и при обычном соединении. Разумеется, не забыв при этом попрощаться с текущей AP, послав ей STA_LEAVE (опять же, не все клиенты это делают).

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

Для ускорения этой процедуры используются следующие механизмы:
– если клиент уже ранее был на этой AP, и в кэше (PMK Chache) есть запись для него, то 4 шага аутентификации будут сокращены до двух, и клиент пройдёт по упрощённой процедуре реассоциации (Reassoc).
– также будет использована всё та же короткая процедура при использовании FT(802.11R)/OKC.
– процедура выявления кандидатов может быть ускорена с помощью (RRM)802.11K за счёт запроса у текущей AP списка работающих соседей без выполнения процедуры сканирования.

Однако, подавляющее число клиентов умеет разве что PMK Cache и OKC. Последний применим только в WPA2 Enterprise сетях.

Но сейчас не об этом. Да и основная проблема в другом.

Основной нюанс для осуществления именно бесшовности (на этом уровне, на L2,L3 есть свои не менее важные нюансы) – то, что в момент миграции клиент должен уложиться в тайм-аут TCP соединений системы, и что ещё важнее не сбрасывать эти соединения, т. е. на уровне операционной системы при успешной миграции не должно генерироваться событие link beat (Link down/up).

К сожалению, около 70% клиентов всегда генерят link beat и всегда сбрасывают соединения приложений. Именно это основная проблема при миграции на стадии переключения. Т.к. даже если всё прошло гладко, но система сбросила состояния соединения пользовательских приложений, то вместо кратковременного «квака» (например в VOIP) из-за небольшой потери пакетов получим гарантированную необходимость перезвонить.

На таких клиентах бесшовная миграция не возможна в принципе.

На других клиентах порог уровня, по которому инициируется Handover, задан ниже -80dB, и часто происходит так, что AP гораздо раньше перестаёт слышать клиента и отстреливает его, нежели клиент сам инициирует процедуру handover`а. И повлиять на это можно только одним способом — понижать уровень сигнала со стороны AP, чтобы AP не теряла клиента до момента срабатывания handover. Обычно уровень в 2.4ГГц при этом приходится выбирать ниже 16дБм, что заметно сказывается на SNR и приводит к заметной деградации сервиса (к сожалению мы не одни в эфире).

Вот так, в двух словах, можно описать всё, что происходит на L1 уровне в процессе handover и основных проблемах. Крайне упрощённо, но достаточно для понимания. В одной из частей мы вернёмся к проблемам (их значительно больше и не только на L1 уровне) и рассмотрим их подробнее.

Что из сказанного обязательно к запоминанию:

1) handover всегда инициирует клиент исходя из собственных соображений;
2) в 802.11 нет ни одного механизма сказать клиенту форсировать процедуру handover или просто внепланово «посмотреть вокруг», выполнив сканирование; ОБНОВЛЕНИЕ: В новых редакциях 802.11v предусмотрен механизм BTM, но поддерживается увы менее чем на 50% клиентов собственно умеющих этот самый 802.11v.
3) в 802.11 нет чёткого набора требований к алгоритмам реализации handover — всё отдано на откуп третьим лицам, потому существует далеко не одна реализация разной степени кривости;
4) на весьма большом числе клиентов процедура handover не подразумевает бесшовности, т. е. всегда приводит к сбросу соединений приложений;
5) немалый пласт клиентов вообще не умеет процедуры handover, и попытка соединения к новой AP будет выполнена только тогда, когда соединение с текущей будет утеряно, или же текущая AP пошлёт клиенту DEAUTH фрэйм;
6) единственное критичное требование к AP для функционирования процедуры хэндовер на клиенте – это её нормальная работа. Грубо говоря, она просто должна гарантированно пустить нового клиента без каких-либо аномалий.

Для решения проблемы миграции у клиентов, о которых сказано в пункте 5, производители AP изобрели ещё один костыльный механизм. Называется он HandOFF и о нём мы поговорим в следующей статье.

Исследование CISCO на тему критериев запуска процедуры handover можно увидеть тут https://www.cisco.com/c/en/us/td/docs/wireless/controller/technotes/8-0/device_classification_guide.html

Исследование CISCO стадии сканирования в процессе миграции и использование 802.11k (RRM) для сокращения этой фазы https://www.cisco.com/c/en/us/td/docs/wireless/controller/technotes/8-0/iPhone_roam/b_iPhone-roaming.html на примере iphone6

Определение роуминга от wi-fi alliance https://www.wi-fi.org/knowledge-center/faq/how-does-a-client-roam

Wi-Fi Handoff

HandOFF дословно — передавать. Однако, в контексте 802.11 я бы скорее перевёл бы этот термин (применительно к AP) как “руки прочь”.

В третьей части цикла мы рассмотрели такую процедуру как handover, которую выполняет клиент для миграции внутри wi-fi сети.

А что делать, если клиент по какой-то причине отказывается инициировать переход? А если клиент вообще не умеет самостоятельно мигрировать?

Вот тут к нам на выручку придёт механизм HandOFF. Как обычно в 802.11, этот механизм не является частью стандарта, не обязателен к реализации и вообще не предусмотрен. Сюрпрайз!

wive-ng handoff parametrs
Настройки HandOFF в Wive-NG

Ну что же, нам не привыкать.

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

Клиент благополучно «слетает» с AP, а дальше…

А дальше выполняет всё то, что мы описывали в первой части. Чаще всего при этом сразу же будут оборваны все соединения локальных приложений. Т.е. так называемой бесшовностью тут не пахнет. Исключение составляют разве что клиенты с модифицированной логикой обработки события прихода 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) или же вовсе игнориурет, и в итоге получаем клиента, который до упора будет считать, что подключен к ТД, в то время как ТД считает, что клиент обработав сигнал ушёл на соседнюю AP.

В результате, даже если клиенты, умеющие 12 reason и существуют в природе, мы всё равно вынуждены, ради совместимости, слать всё тот же Sta Leave т. к. ТД не знает, что именно реализовано в клиенте.

Также нет никаких механизмов сказать при этом клиенту, куда нужно мигрировать, и нужно ли вообще.

Проще говоря, мы просто выпинываем (kick out) клиента с ТД и надеемся, что клиент переключится на более подходящую ТД, что не всегда так. А многие клиенты первым делом пытаются вернуться назад. Или вовсе впадают в ступор и ждут, пока пользователь снова ткнёт «подключиться». Благо, последний вариант всё же редкость. А против возвращенцев можно использовать временную блокировку на уровне probe/assoc/auth (как, например, это сделано в Wive).

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

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

В ближайшее время постараюсь расписать, как handover реализован у нас (в Wive-NG-MT), как его настроить в зависимости от задачи и т. д.

P.S. По традиции немного веселья из мира Enterprise $). Описание настройки handoff для Ruckus : https://support.ruckuswireless.com/answers/000002277. Они называют это smart roam. Как всегда в мире Enterprise, любой костыль выдаётся за мегадостижение, а т.к. сейчас всё SMART, то и костыль должен быть Smart. Также по ссылке есть рекомендации по отладке роуминга, которые сводятся к обновлению софта (видимо для поддержки RRM) и настройке агрессивности роуминга на клиенте (говорил в первой части об этой опции). Ну и если совсем не помогло, включаем smart roam. =) Ну и обилие опций (аж одна штука) поражает воображение.

distribution system

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

Определимся с терминологией:

DS – Distribution System. Дословно «система распределения». В контексте рассматриваемой задачи это опорная сеть. Т.е. непосредственно сеть, по которой бегает трафик от клиента в мир и назад.

Как может быть организована DS?

  • Самый частый (и правильный) случай – это банальная кабельная сеть, связывающая все AP и шлюз в мир в единую сеть.
  • Второй вариант – использование WDS/APCLI. По сути то же самое, но по воздуху без использования кабельной ифраструктуры (частным случаем является MESH — тут мы будем говорить о конкретном и единственном стандартизованном варианте 802.11s. По сути в нашем случае ничем не отличается от WDS, и дальше будет пояснено почему).
  • Гибридные схемы. Например, разные AP подключены в разные шлюзы, используют разный транспорт и даже разные сети, принадлежащие разным операторам (3G/4G,WiFi,LAN и т. д.). Даже в этом случае возможен бесшовный роуминг между AP. Однако, этот подход добавляет лишний слой в виде L2 туннелей (например L2TPv3) для объединения всех их в единую связную на L2 сеть.

Уже на этом этапе вы могли заметить оговорку о необходимости организации плоской L2 сети. Это является основным требованием для реализации бесшовной миграции.

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

Именно тут и добавляются новые требования к построению DS:

1. Плоская L2 сеть между клиентами и шлюзом;
2. Единый шлюз в мир, доступный с любой точки, на какую бы клиент ни переключился;
3. Единое адресное пространство с минимальным шансом смены адреса клиентом при миграции;
4. Быстрое и гарантированное обновление MAC tables на всём промежуточном оборудовании (коммутаторах, например) при первом же пакете от клиента после миграции;
5. Связная на L2 сеть между AP.

Иными словами, все клиенты у нас должны быть в одной плоской сети, а IP-адреса выдаваться одним DHCP сервером, дабы избежать ситуации, когда при миграции клиента сменится и его IP-адрес, в результате чего state`ы соединений приложений и conntrack пойдут прахом.

DHCP

Штатный механизм с выделением lease и продлением оных часто тут оказывается бессилен (нередко клиент до или после миграции зачем-то шлёт DHCP release). Поэтому во всех Enterprise системах (в Wive аналогично) используется DHCP сервер, который выдаёт адреса из диапазона с оглядкой не только на возможно уже существующую lease для этого клинта, но и на hash MAC-адреса.

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

Коммутация

AP чаще всего собраны в один или несколько коммутаторов. Важно, чтобы эти коммутаторы не имели распространённой проблемы в виде «залипания» записи в MAC table. Т.е. когда клиент исчез с одного порта и появился на другом, все таблицы по пути должны быть перестроены мгновенно (т. е. процесс, как многие любят выражаться, «обучения» должен быть моментальным).

Для ускорения этого момента на стороне AP в Enterprise мире (в Wive аналогично) используется следующий подход: после миграции клиента AP, не дожидаясь первого пакета в мир от клиента, сама шлёт от его имени что-либо в DS, вынуждая коммутаторы перестроить таблицы коммутации. Чем обеспечивается готовность DS ещё до начала передачи клиентом полезных данных.

Для чего нужна связность между AP?

Дело в том, что AP между собой обмениваются информацией, используя протокол IAPP, внутри которого бегают данные, например, необходимые для ускорения фазы аутентификации при использовании FT (не будем вдаваться в подробности, т. к. это тема отдельной большой статьи).

Самое важное – этот же IAPP используется для move notify.

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

Важно это потому, что чаще всего клиент при миграции не посылает LEAVE той AP, с которой мигрировал. AP, продолжая думать, что клиент всё ещё обслуживается на ней, продолжает пытаться послать данные из очереди в сторону этого клиента. Учитывая, что клиент её уже не слушает, такие передачи всегда будут неудачными. Но проблема не в этом, она глубже: дело в том, что пока AP пытается выполнять TxRetry в сторону такого клиента, никакая передача больше невозможна. TxRetry limits могут быть достаточно большими, к тому же RATE-ALG закономерно снижает rate, думая, что просто ухудшились параметры эфира, и пробует снова. В некоторых случаях этот процесс может занимать секунды, а все соседи на этой AP будут ждать, когда же их обслужат. Проще говоря всё это время любой другой обмен данными с этой AP будет парализован.

Move notify позволяет свести к нулю подобные проблемы, удаляя запись о клиенте из MAC table AP сразу по приходу нотификации о том, что клиент уже обслуживается другой AP.

Это всё работает независимо от того как организована DS. Что бы ни было ниже (LAN/ WDS/ MESH/ APCLI) , эти подходы не меняются и для полноценной прозрачной миграции являются необходимостью.

Пара слов О MESH

На текущий момент нет ни одного клиента (смартфона/ноутбука и т. д.), который может быть непосредственным участником MESH-сети. Таковые только заявлены, причём со стороны чипмэйкров. Например, MTK 8 января 2019г завявил, что новые SOC для телефонов (включающие в себя wifi) смогут быть непосредственно клиентами MESH сети. А значит, все те же требования накладываются и на MESH, что сужает его возможные преимущества до так называемого Smart WDS (как недавно было модно у чипмэйкеров) или, как это называет Asus, AI MESH. Т.е. MESH используется исключительно как WDS между AP (не стоит путать MESH как технологию реализации аплинка AP и механизмы, обеспечивающие миграцию клиентов между AP). Клиенты используют всё те же механизмы, AP точно так же гоняют IAPP между собой и всё так же необходима L2 связность между AP, в то время как клиентов между собой можно и изолировать. Как конкретно внутри устроен этот самый DS значения в таком ключе не имеет абсолютно, лишь бы соблюдались требования, изложенные выше.

Подробнее MESH (на примере 802.11s) в схемах с миграцией рассмотрим в одной из следующих статей.

Гибридные сети.

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

Лучшая DS для сетей с миграцией это LAN DS на коммутаторах с минимумом мозга, т. к. чаще всего проблемы начинаются именно с этого мозга (ложные детекты конфликта MAC-адресов при миграции, залипание записей в MAC table, дикие траблы с ARP cache и прочие прелести).

Workarounds (костыли).

Часто, чтобы обойти излишнюю “умность” и инициативность коммутаторов (из-за которой чаще всего и возникают проблемы с обновлением mac tables и arp cache в DS), в Enterprise делают финт ушами. Разворачивают а-ля контроллер. Он же обычно является шлюзом для беспроводки, на нём же живёт DHCP (с механизмом генерации IP по hash`у MAC-адреса), и на нём же собирают L2 туннели с AP, которые и решают проблемы излишней «умности» оборудования DS. Иными словами, осуществляется надстройка над физической сетью ещё одного уровня логики. Аналогично делает Mikrotik с его capsman.

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

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

Ибо, как говорил Чехов, «Если в начале пьесы на стене висит ружье, то (к концу пьесы) оно должно выстрелить.».

Стоит избегать:

  • Усложнения схемы без нужды (усложнение ради усложнения);
  • Использования чересчур умного оборудования для решения простых задач;
  • Построения DS по воздуху просто в силу того, что воздух – среда передачи непредсказуемая и доступная всем, кто имеет соответствующее оборудование. В случае с WiFi любой школьник с телефоном в кармане может стать проблемой вашей корпоративной сети с DS по воздуху.

Чем меньше потенциальных точек отказа — тем лучше. А Wive-ng позволит вам иметь реализации подходов к организации бесшовной беспроводной сети уровня Enterprise, не теряя полного контроля над логикой работы на самом низком уровне, чего не позволяет ни одно закрытое решение.

Источник