При построении сетей с роумингом чаще всего забывают об одной, практически самой важной части. А именно, о правильности организации опорной сети.
Определимся с терминологией:
DS – Distribution System. Дословно «система распределения». В контексте рассматриваемой задачи это опорная сеть. Т.е. непосредственно сеть, по которой бегает трафик от клиента в мир и назад.
Как может быть организована DS?
- Самый частый (и правильный) случай – это банальная кабельная сеть, связывающая все AP и шлюз в мир в единую сеть.
- Второй вариант – использование WDS/APCLI. По сути то же самое, но по воздуху без использования кабельной ифраструктуры.
- Гибридные схемы. Например, разные 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) , эти подходы не меняются и для полноценной прозрачной миграции являются необходимостью.
Гибридные сети.
Что касается гибридных сетей, то это хоть и возможный и реально работающий кейз, но, в силу слабой предсказуемости и отсутствия механизмов какого-либо контроля, использовать его стоит лишь в исключительных случаях.
Лучшая 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, не теряя полного контроля над логикой работы на самом низком уровне.
