- PVSM.RU - https://www.pvsm.ru -
В связи с появлением приличного количества статей по Cisco, Aruba, Ubiquiti и даже Juniper, решил добавить статью по Motorola, с которой я очень плотно работаю. В идеале, будет цикл статей – от обзора архитектуры, до конфигурации и фишечек. Посмотрим, как взлетит. В этой части проведем общий обзор архитектуры.
WiNG5 (Wireless Next Generation) – пятое поколение беспроводных сетей Motorola. Последняя на данный момент стабильная версия имеет номер 5.4.4, но описание основано на бете 5.5, которая должна выйти осенью. Версия 5.5 значительно расширяет возможности именно с архитектурной стороны. К тому же, я смог пощупать ее в работе – хоть и не без глюков, но заявленные фишки присутствуют и в целом работают.
По сравнению с четвертой версией архитектура изменена в корне, включая программную базу, конфигурационную модель и пользовательский интерфейс — это, фактически, новый программный продукт. Понятное дело, было много боли со стороны пользователей и интеграторов, которым пришлось переучиваться. Что привело довольно консервативного корпоративного вендора к такому радикальному шагу?
Основным отличием WiNG5 от предыдущих поколений является уход от строгой контроллерозависимости в сторону распределенных сетей. Это вызвано несколькими очевидными факторами:
Всё это и привело к тому, что потребовалось выпустить кардинально новый продукт. Другие Tier1 вендоры (Cisco, Aruba) около года пытались каким-то образом адаптировать свои контроллерозависимые архитектуры к новым требованиям (Aruba Instant, Cisco FlexConnect — переименованный и слегка допиленный H-REAP). Но в итоге Aruba таки анонсировала переход на новую архитектуру MOVE, а Cisco вообще помимо программного апгрейда еще заставила сделать аппаратный (плюс, купила Meraki, так что теперь в активе Cisco 5 разных WLAN-платформ).
Так что, хотите вы этого или нет, но для работы с современными сетями 802.11n и 802.11ac придется учить матчасть заново — таковы современные реалии.
Для работы под WiNG5, Motorola выпустила приличное количество новых продуктов — точек и контроллеров, поддерживаются и некоторые старые модели. Так как фокус данной статьи — архитектура, а не железо, ниже приведено весьма краткое описание контроллеров и точек для общего понимания. Но если есть интерес — напишу отдельную статью с таблицами и картинками, а также описанием особенностей (кодировка моделей, разлоченные радиомодули, пожизненная гарантия, RadioShare, уловки маркетологов и т.д.).
Точек доступа доступно великое множество — они разделены на несколько линеек, почти всегда доступны модификации с внешними или внутренними антеннами, много вариаций на тему исполнения (внутреннее/наружное/особое), производительности радиомодулей, зависимости от контроллера (Independent/Dependent) — всегда можно выбрать что-то подходящее.
Для первого знакомства, давайте рассмотрим варианты архитектуры/внедрений, доступные с WiNG5.5, заодно объяснив в общих чертах, как и когда достигаются заявленные выше вкусности и полезности. Приведенная ниже картинка наглядно показывает процесс роста и эволюции сети на WING5.
Никакой фантастики – набросали точек, они работают, каждая сама по себе, друг с другом не общаются (можно сделать, чтобы общались, но есть вариант получше). Смысл в таком решении есть только когда точек ровно одна штука – для всего остального есть следующий пункт.
Одна из точек назначается «Виртуальным контроллером (VC)» и управляет остальными точками.
Ограничения:
Итого, вполне можно построить сетку с RADIUS-бакендом смотрящим в Active Directory, хотспотом и Mesh впридачу — самое оно для небольшого внедрения.
Если точек больше 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-сервер, виртуальный контроллер и т.д.) в этих точках отключен за ненадобностью.
Если мало одной площадки – можно завести несколько. При этом не обязательно (но возможно) ставить на каждую из них по контроллеру – всё может управляться из центра.
Точки на каждой удаленной площадке находят контроллер (локальный или удаленный), находят друг друга, выбирают 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, которые могут хостить виртуальные машины. Основные применения –
Таким образом, начав с одной точки, можно вырасти до виртуального контроллера, потом добавив «реальный» контроллер в сеть, просто переконфигурировать точки на работу с ним, потом можно разраститсь до ~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
Источник [3]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/besprovodny-e-seti/41738
Ссылки в тексте:
[1] я писал про нее ранее: http://habrahabr.ru/post/153069/
[2] хостинг: https://www.reg.ru/?rlink=reflink-717
[3] Источник: http://habrahabr.ru/post/191310/
Нажмите здесь для печати.