В связи с появлением приличного количества статей по Cisco, Aruba, Ubiquiti и даже Juniper, решил добавить статью по Motorola, с которой я очень плотно работаю. В идеале, будет цикл статей – от обзора архитектуры, до конфигурации и фишечек. Посмотрим, как взлетит. В этой части проведем общий обзор архитектуры.
WiNG5 (Wireless Next Generation) – пятое поколение беспроводных сетей Motorola. Последняя на данный момент стабильная версия имеет номер 5.4.4, но описание основано на бете 5.5, которая должна выйти осенью. Версия 5.5 значительно расширяет возможности именно с архитектурной стороны. К тому же, я смог пощупать ее в работе – хоть и не без глюков, но заявленные фишки присутствуют и в целом работают.
По сравнению с четвертой версией архитектура изменена в корне, включая программную базу, конфигурационную модель и пользовательский интерфейс — это, фактически, новый программный продукт. Понятное дело, было много боли со стороны пользователей и интеграторов, которым пришлось переучиваться. Что привело довольно консервативного корпоративного вендора к такому радикальному шагу?
И зачем оно нужно?
Основным отличием WiNG5 от предыдущих поколений является уход от строгой контроллерозависимости в сторону распределенных сетей. Это вызвано несколькими очевидными факторами:
- Сети Wi-Fi становятся быстрее и быстрее. С 802.11n/ac прокачивать весь трафик через контроллер в мало-мальски крупной сети не представляется разумным, да и стоимость апгрейда проводного сегмента для доставки всего этого трафика к контроллеру тоже будет весьма немалой. Ради интереса, посчитайте суммарную пропускную способность, скажем, сотни точек 802.11n-450 с двумя радио. WiNG5 позволяет очень гибко выбирать, куда слать трафик: коммутировать/маршрутизировать прямо на точке, слать на контроллер, слать на другую точку (об этом позже). Таким образом, контроллер более не является узким местом, и сеть может спокойно расти и развиваться.
- Сети становятся больше, в т.ч. включая удаленные площадки. Если раньше идея «отдельный сайт = отдельный контроллер» была вполне приемлемой (т.к. сайтов было 5-10), то сейчас счет площадок идет на сотни. Управлять ими по-отдельности или с помощью дополнительной «навесной» системы управления не хочется. WING5 позволяет управлять кучей контроллеров, точек и площадок (до 10 000 устройств, до 4 000 площадок) с единой консоли контроллера с той же лёгкостью, с которой управляется один единственный сайт. Также, есть довольно гибкий механизм алиасов и наследования, позволяющий не плодить в конфиге сущности без необходимости, его мы тоже рассмотрим ниже.
- Удаленные площадки должны нормально работать без связи с центральным контроллером. Архитектуры прошлого поколения позволяли точкам работать без контроллера, но при этом единая Сеть распадалась на множество отдельно стоящих точек – никакого тебе согласованного управления покрытием, отслеживания роуминга, переноса сессий файрволла и т.д. В WING5 удаленные площадки продолжают работать как целостные сети даже при потере связи с центром. Плюс, много внимания уделено оптимизации полосы пропускания WAN.
- Тем не менее, небольшие внедрения всё еще имеют место быть, поэтому архитектура должна работать и на малом уровне (и расти вместе с сетью без необходимости выкинуть всё и заменить на совсем другую платформу). WING5 позволяет начать с одной точки и расти до тысяч сайтов с контроллерами без необходимости кардинально переучиваться: один и тот же продукт, CLI, UI, модель управления, нужно просто доучить пару новых команд.
Всё это и привело к тому, что потребовалось выпустить кардинально новый продукт. Другие Tier1 вендоры (Cisco, Aruba) около года пытались каким-то образом адаптировать свои контроллерозависимые архитектуры к новым требованиям (Aruba Instant, Cisco FlexConnect — переименованный и слегка допиленный H-REAP). Но в итоге Aruba таки анонсировала переход на новую архитектуру MOVE, а Cisco вообще помимо программного апгрейда еще заставила сделать аппаратный (плюс, купила Meraki, так что теперь в активе Cisco 5 разных WLAN-платформ).
Так что, хотите вы этого или нет, но для работы с современными сетями 802.11n и 802.11ac придется учить матчасть заново — таковы современные реалии.
Для работы под WiNG5, Motorola выпустила приличное количество новых продуктов — точек и контроллеров, поддерживаются и некоторые старые модели. Так как фокус данной статьи — архитектура, а не железо, ниже приведено весьма краткое описание контроллеров и точек для общего понимания. Но если есть интерес — напишу отдельную статью с таблицами и картинками, а также описанием особенностей (кодировка моделей, разлоченные радиомодули, пожизненная гарантия, RadioShare, уловки маркетологов и т.д.).
Контроллеры:
- Серия RFS: RFS4000/6000/7000 — контроллеры WLAN с уклоном в сетевые сервисы. Помимо поддержки до 144/256/1024 точек соответственно, выполняют функции L3-коммутации, маршрутизации (NAT, OSPF) и других сетевых сервисов (IpSec, L2TP, RADIUS, WIPS, etc). Некоторые модели поддерживают PoE, SFP и т.д.
- Серия NX: NX45xx/65xx/9150 — контроллеры WLAN с уклонов в сервисы приложений. Помимо поддержки до 144/264/10240 (это не опечатка!) точек, также поддерживаются продвинутые прикладные сервисы (аналитика, кеширование контента, IP-АТС и т.д.) и виртуализация на основе гипервизора Xen (подробности ниже). NX45/65 доступны в исполнении со встроенным LAN-коммутатором с PoE (NX4524/6524) или без него (NX4500/6500). Функции линейки RFS тоже присутствуют, но мощность/масштабируемость немного пониже. NX45/65 позиционируются как коробки «всё-в-одном» для небольшого или среднего офиса, а NX9510 — как сверхмощный центральный контроллер для огромной распределенной сети (стОит соответственно :) ).
Точки доступа
Точек доступа доступно великое множество — они разделены на несколько линеек, почти всегда доступны модификации с внешними или внутренними антеннами, много вариаций на тему исполнения (внутреннее/наружное/особое), производительности радиомодулей, зависимости от контроллера (Independent/Dependent) — всегда можно выбрать что-то подходящее.
- Low-end: AP6511/AP6521/AP621 — максимально простая и дешевая платформа, одно радио 2x2:2 MIMO, минимальная масштабируемость, некоторые фичи недоступны. AP621 — Dependent-модификация AP6521 (подробности про Dependent ниже). AP6511 — особое исполнение, я писал про нее ранее.
- Mid-range: AP6522/AP622/AP6562 — менйстрим, два радиомодуля 2x2:2, но без ограничений присущих low-end точкам. По-сути, одна и та же точка в разном исполнении: AP6521 — Independent, AP622 — Dependent, AP6562 — наружное исполнение.
- Upper-mid: AP650/6532. Чуть более производительная версия за счет радио 2x3:2. Используют в основном там, где есть выгода от 2x3 MIMO (работа с маломощными мобильными устройствами и т.д.) — иногда оказывается, что можно обеспечить такое же покрытие, используя на 30-40% меньше точек. Для всего остального есть серия 622/6522
- High-end: AP7131/7161/7181, AP8132 — топовые модели с 2 или 3 радиомодулями (сенсор WIPS, 3G-модем), серия 7xxx — 3x3:2, серия 81xx — 3x3:3 (450Mbps). AP7161 и AP7181 предназначены для наружного применения, при этом AP7181 — настоящий монстр с особой конструкцией антенн, дальностью до 25 км и возможностью запитки от себя IP-камер и проч. В общем, оборудование для покрытия целых районов города.
- 802.11ac: серия AP82xx. Пока только анонсированы, вживую еще не видел. Обещается одна точка High-End, и две среднего уровня.
И как это всё работает?
Для первого знакомства, давайте рассмотрим варианты архитектуры/внедрений, доступные с WiNG5.5, заодно объяснив в общих чертах, как и когда достигаются заявленные выше вкусности и полезности. Приведенная ниже картинка наглядно показывает процесс роста и эволюции сети на WING5.
1. Одна площадка: отдельно стоящие точки.
Никакой фантастики – набросали точек, они работают, каждая сама по себе, друг с другом не общаются (можно сделать, чтобы общались, но есть вариант получше). Смысл в таком решении есть только когда точек ровно одна штука – для всего остального есть следующий пункт.
2. Одна площадка: виртуальный контроллер.
Одна из точек назначается «Виртуальным контроллером (VC)» и управляет остальными точками.
- Можно управлять всей площадкой с одной консоли,
- не нужно настраивать точки по-отдельности,
- точки общаются между собой, предоставляя такие функции как управление покрытием (RRM, в терминологии Motorola “SMART RF”), бесшовный роуминг с переносом сессий Stateful firewall и т.д.
Ограничения:
- до 24 точек,
- только одна площадка (можно поставить и на 24, но система будет думать, что все точки на одной площадке),
- все точки должны быть одной модели
- недоступны некоторые сильно продвинутые функции типа туннелирования трафика, Role-Based Firewall (RBAC) и т.п.
Итого, вполне можно построить сетку с RADIUS-бакендом смотрящим в Active Directory, хотспотом и Mesh впридачу — самое оно для небольшого внедрения.
3. Одна площадка: полноценный контроллер
Если точек больше 24 или хочется продвинутых функций, нужен полноценный контроллер. Как-бы классическая контроллерная схема, но с рядом существенных улучшений. Контроллер работает не так, как в сетях предыдущего поколения: точки могут слать трафик в контроллер (если так удобнее, скажем, на складе c 50 терминалами сбора данных, работающих с Телнетом) или могут коммутировать/маршрутизировать трафик сами (если так быстрее, скажем, для VoIP). При этом выбор этот достаточно гибкий – отдельно для каждой VLAN, WLAN, и некоторых типов служебного трафика. Напримет, трафик AAA можно проксировать через контроллер (чтобы не конфигурить кучу RADIUS-клиентов на сервере), а сами пакеты данных слать в сеть напрямую.
Таким образом, контроллер выступает в роли Feature Server’а и системы управления. Кроме того, упомянутые выше фичи типа управления покрытием будут продолжать работать и без контроллера – за их работу отвечает одно из устройств на площадке, которому путем выборов назначается роль RF Domain Manager (RFDM). Обычно, если на площадке присутствует контроллер, он и будет RFDM, но если контроллера нет (или он умрет, и нет кластера) – выборным путем должность RFDM будет назначена одной из точек доступа. При этом (с версии 5.5) точка-RFDM может координировать работу до 128 устройств (включая себя). Есть исключение – точки нижней ценовой категории поддерживают до 24 устройств (не хватает мощности).
Еще одной интересной особенностью архитектур с контроллером является возможность точек туннелировать трафик между собой (ТД-контроллер или ТД-ТД) посредством проприетарного служебного протокола MiNT. Это позволяет избежать возни с прокладной транков на проводных коммутаторах и их настройкой при добавлении новых WLAN, что значительно экономит время и нервы. MiNT позволяет устанавливать туннели по Layer 2 и Layer 3 и туннелировать L2-трафик (проводной и беспроводной) как душе угодно.
Также, использование контроллера позволяет сэкономить на точках: вместо «полноценной» модели можно купить «облегченную» (Dependent в терминологии Motorola). Они стоят значительно (~-30%) дешевле полноценных, имеют все те же функции, но без контроллера работать отказываются (есть определенный интервал, несколько минут, после которого точки устраивают забастовку). Соответственно, ряд функций, необходимых только в автономных сценариях (RADIUS-сервер, виртуальный контроллер и т.д.) в этих точках отключен за ненадобностью.
4-6. Несколько площадок: без локального контроллера или же с ним
Если мало одной площадки – можно завести несколько. При этом не обязательно (но возможно) ставить на каждую из них по контроллеру – всё может управляться из центра.
Точки на каждой удаленной площадке находят контроллер (локальный или удаленный), находят друг друга, выбирают RFDM и счастливо живут вместе. Поскольку RFDM находится на локальной площадке, все оперативные функции работают в полном объеме, а контроллер, по сути, исполняет роль системы мониторинга и управления. При этом, довольно здорово устроен процесс управления: связь с удаленным контроллером (посредством MiNT) поддерживает только RFDM, остальные точки проксируют запросы через него. В такой ситуации, внутри MiNT автоматически поднимается двухуровневая маршрутизация а-ля IS-IS. Опять же, если RFDM умер – динамически выбирается другой и всё продолжает работать.
Поддерживается куча WAN-механизмов: IPSec, NAT (с failover'ом), L2TPv3, L2NAT, PPPoE, VRRPv2/v3, и даже OSPFv2 и PBR (Policy-Based Routing), но обычно весь трафик просто туннелируют через MiNT, защищенный VPN-туннелем (поднимается полуавтоматически — нужно прописать руками PSK или сертификат).
Такая архитектура масштабируется до 128 точек на удаленном сайте без необходимости закупать и ставить локальный контроллер, при этом точки не обязаны быть одной модели (но это должны быть полноценные точки, если необходимо, чтобы они продолжали работу после, скажем, отказа аплинка).
Если на удаленной площадке есть контроллер (или кластер) – не проблема. Он точно также подключается к центральному контроллеру, получает с него ЦУ и начинает рулить сайтом. При этом, на центральной консоли всё отображается в красивой двухуровневой модели. Из приятных штрихов – сайт-контроллеры (Site Controller в терминологии Motorola) могут «занять» лицензий на точки у центрального контроллера, если своих не хватает. Лицензии эти держатся достаточно долго и переживают ребуты, так что можно из вообще ставить исключительно на центральный контроллер.
При желании (и довольно несложно), можно сделать так, что на удаленной площадке точки и контроллер достаточно вынуть из коробок и включить в сеть. Аналогично, если что-то пошло СОВСЕМ не так – контроллер/точки на удаленной площадке просто сбрасываются в настройки по-умолчанию и всё автоматом настраивается заново.
Плюс, есть много умных фишек по автоматизации подключения точек, минимизации загрузки WAN-канала при обычной оперативной деятельности и, скажем, обновлении прошивок или раздаче кастомных веб-страниц для сервера хостпота – об этом поговорим отдельно (как-нибудь в другой раз).
Прочие модели и особенности
Удаленные площадки не обязаны быть удаленными – если у меня есть здоровенный кампус с 15 корпусами по 129 точек в каждом – можно завести «виртуальные» сайты (RF Domain в терминологии Motorola) и поручит управлять всем центральному контроллеру. Делается одной галкой.
Cloud Controller. Модная нынче тема. Если не использовать тунеллирование MiNT на контроллер (по-прежнему можно использовать между ТД) – не обязательно закупать контроллерное железо. Вместо этого можно использовать контроллер как VM (XEN) или как PaaS-сервис от Motorola.
Mesh. У Motorola есть две Mesh-технологии: традиционная, как у большинства вендоров, и своя проприетарная – MeshConnex (MCX) – после которой традиционной пользоваться не хочется. MCX поддерживает двухуровневую маршрутизацию, несколько механизмов отказоустойчивости и балансировки нагрузки и масштабируется до сотен узлов в сети (мне заявляли про 1400, но я не видел :)).
Виртуалки/сервисы приложений. У Motorola есть линейка контроллеров NX45xx/65xx/95xx, которые могут хостить виртуальные машины. Основные применения – дополнительных сервисов от Motorola (AirDefense Service Platform, Secure Access Server, куча голосовых серверов), или вариант «всё-в-одном» для удаленной площадки. Ничто не мешает захостить на NX65xx какой-нибудь BDC на Windows Server или Linux с прозрачным кеширующим веб-прокси на основе Squid (хотя, последнее, вроде уже вкрутили в 5.5 напрямую).
Таким образом, начав с одной точки, можно вырасти до виртуального контроллера, потом добавив «реальный» контроллер в сеть, просто переконфигурировать точки на работу с ним, потом можно разраститсь до ~4000 площадок с 10 000 точек и контроллеров на них (суммарно), работая, в принципе, с одним и тем же продуктом, одним и тем же CLI/GUI и одними и теми же принципами настройки и развертывания. Это является одной из уникальных фишек Motorola, т.к. другие вендоры обычно предлагают комплекс из разных продуктов, которые надо все изучить и как-то между собой интегрировать. У Motorola, прошивки точек и контроллеров собираются из одних и тех же исходников (просто включаются/выключаются определенные фичи и выставляются пределы масштабируемости), так что по-сути вы всегда работаете с одним и тем же продуктом и интерфейсом. Сейчас ударными темпами идет интеграция ADSP в WiNG – многие функции доступны напрямую. Но подозреваю, как минимум до следующего года мы еще будем видеть торчащие «концы» там и тут :)
И как это всё настроить?
С точки зрения конфигурации, WING5 выглядит достаточно интересно, но, на первый взгляд сложно – куча опций и непонятно с чего начинать. Eсть Wizard, который, при всей своей простоте, позволяет настроить на контроллере/точке транки, роутинг с NAT’ом, и беспроводные сети с поддержкой внешнего RADIUS.
Учитывая масштабируемость и гибкость решения, конфигурационная модель не так уж и сложна — есть всего пять типов элементов и многослойная схема их комбинирования с наследованием и переопределением — очень напоминает ООП. Однако, начав писать описание и пример конфигурации я понял, что это еще 5-8 страниц текста с иллюстрациями. Поэтому на этот раз давайте ограничимся скриншотами GUI и Wizard'а (под катом), а в следующей статье обсудим конфигурационную модель в деталях и настроим небольшую сеть с контроллером, PSK и внешним RADIUS. Отдельно, я хочу посвятить статью настройке WLAN, так как количество опций и интересных возможностей просто зашкаливает.
Wizard: настройка LAN:
Wizard: настройка WLAN
GUI: пример экрана настройки (Role-Based Firewall):
GUI: пример Dashboard'а: визуализация RF в реальном времени
GUI: пример экрана статистики — визуализация MeshConnex (crop)
В целом должен сказать, что решение от Motorola, хоть и не без недостатков (которые обсудим в процессе настройки), выглядит очень сильно на фоне остальных конкурентов. Оно не обладает огромным количеством фич на все случаи жизни как Aruba, оно не обладает сильной документацией и мощной железной поддержкой как Cisco, не хватает наличия проводных коммутаторов, управляемых из-под того-же контроллера, как у Aruba/Meraki/Aerohive. Но зато оно в разы проще конфигурится (что мне еще предстоит доказать :) ) и отлично масштабируется, не требуя тотальной замены всего железа — в плане гибкости и дружественности к админу и Cisco и Aruba до Motorola еще далеко (хотя мой фаворит тут — Aerohive, но они пока еще не дорасли до Tier1). Можно сказать, что правило «80/20» применимо к Motorola в формулировке "Настрой 80% фич Cisco/Aruba с 20% геморроя Cisco/Aruba", не считая уникальных фишек, присущих только Moto.
Спасибо за внимание.
Автор: apcsb
