Статья, в целом, шикарная. Однако, есть несколько неточностей.
Виртуальный контроллер (Virtual Controller). Чисто маркетинговая фича, которая позволяет обходиться без контроллера в случае, если точек не очень много (сейчас — 24, будет — больше). Точки должны быть одинаковые (одной модели) и находиться в одном rf-domain. Тонкость с виртуальным контроллером одна — он никогда не выбирается автоматически, а должен быть назначен вручную (с помощью галочки в GUI), При этом иметь его на сайте «про запас» — не получится, ибо становясь виртуальным контроллером, точка прекращает попытки найти контроллер для себя и, наоборот, норовит выступить таковым для местных точек. Таким образом, при наличии нормального централизованного контроллера, мы на нём теряем эту точку из управления. Вывод — при наличии центрального контроллера, его упрощённым аналогом — виртуальным контроллером не следует пользоваться никогда.
Что действительно выбирается автоматически — это RF domain manager. Он выбирается для каждого домена в отдельности. При выборе кандидата на эту должность учитываются возможности оборудования. Если в домен входит контроллер — он всяко становится в нём менеджером, если же домен состоит только из точек — для начала сравнивают модели. AP7161 (она — круче) предпочтут AP650. Если точки одинаковые — в ход идут MAC-адреса и приоритеты. Хотите назначить менеджером самую малонагруженную точку в углу помещения — поправьте её приоритет командой «rf-damain-manager priority». Не хотите, чтобы точка вообще участвоваля в выборах — «no rf-domain manager capable». понять, кто сейчас в домене менеджер можно командой «sh rf-domain-manager»
Поскольку rf-domain manager общается напрямую с каждой точкой домена и занимается координацией роуминга, рассылкой ключей, софта, сбором статистики, переносом сессий stateful firewall при роуминге и прочая и прочая, следует опасаться включать центральный контроллер в расположенный за тридевять земель домен — весь этот трафик поедет по wan
При использовании vendor specific options в DHCP, он, понятно, выдаёт их всем, кому ни попадя. Другое дело, что интересны они только точкам (и врагам). Чтобы выдавать нужные опции только точкам (а, заодно, организовать их в компактный пул адресов) следует воспользоваться поддержкой классов в сервере DHCP. Каждая модель точки включает имя vendor class identifier в запрос DHCP. Например, для AP650 имя класса — MotorolaAP.AP650. Примеры как это сделать — в уже упомянутом документе «WiNG 5.X How-To Guide Centralized Deployments» На худой конец, если влом крутить DHCP и у вас не тысячи удалённых точек, можно обойтись выдачей по DHCP стандартного набора опций. Если в нём присутствует имя домена, то, не найдя в ответе DHCP сервера нужных опций, точка попытается найти контроллер по адресу motorola-wlc.имя.домена. Таким образом, вы намекаете всем желающим, где у вас контроллер ;)
Сервисный контракт можно заключить на год и на три (на три — только на новое оборудование). По окончании трёхлетнего контракта, его можно продлить минимум на два года. ПО всех зависимых точек уже входит в ПО контроллера, ПО автономных точек (обычно) доступно отдельно. Поскольку версия ПО на точках и контроллере (в идеале) должна совпадать — следует озаботиться покупкой хотя бы одного сервисного контракта на точку каждого типа. Сами по себе они ломаются редко ;)
При включении в кластер, перезагрузка контроллера не требуется.
При выключении точки она становится новенькой как с завода только если её не инструктировали сохранять конфигурацию (" configuration-persistence "). Обычно это актуально для зависимых точек и для заказчиков, страдающих параноей на тему «украдут точку — вскроют ей мозг». Для удалённых автономных точек важно иметь конфигурацию на борту для варианта «свет уже включили, а контроллера пока не видно». Вас также попросят включить сохранение конфигурации при попытке включить mesh — точка опасается остаться на мачте освещения без линка на ethernet и без идей, как правильно включить радио в этой дикой стране, чтобы не нарушить законодательство. При желании, можно написать «configuration-persistent secure» — из читабельной версии уберут упоминания про пароли.
Непонятно, что за цены. По каталогу AP-0650-66030-WW стоит $685. Если покупаете самое дешевое — убедитесь, что у вас есть силы всё самим настроить (как у авторов статьи). Обратите особое внимание на последние две буквы парт-номера — они должны быть WW или WR. В последнее время к нам через неразборчивых завозчиков попадает большое количество точек с буквами EU. Они предназначены для продажи в европе и не будут работать в rf-domain с country code ru. Сразу оговорюсь — НИКАК перепошить нельзя. Поэтому вам придётся включать в домене европейский код страны (например fi) и каждая точка будет посылать его 10 раз в секунду (с каждым beacon) с неоднозначными последствиями для клиентов и для вас, потому что это — хорошее начало для общения с регулирующими инстанциями.
Виртуальный контроллер (Virtual Controller). Чисто маркетинговая фича, которая позволяет обходиться без контроллера в случае, если точек не очень много (сейчас — 24, будет — больше). Точки должны быть одинаковые (одной модели) и находиться в одном rf-domain. Тонкость с виртуальным контроллером одна — он никогда не выбирается автоматически, а должен быть назначен вручную (с помощью галочки в GUI), При этом иметь его на сайте «про запас» — не получится, ибо становясь виртуальным контроллером, точка прекращает попытки найти контроллер для себя и, наоборот, норовит выступить таковым для местных точек. Таким образом, при наличии нормального централизованного контроллера, мы на нём теряем эту точку из управления. Вывод — при наличии центрального контроллера, его упрощённым аналогом — виртуальным контроллером не следует пользоваться никогда.
Что действительно выбирается автоматически — это RF domain manager. Он выбирается для каждого домена в отдельности. При выборе кандидата на эту должность учитываются возможности оборудования. Если в домен входит контроллер — он всяко становится в нём менеджером, если же домен состоит только из точек — для начала сравнивают модели. AP7161 (она — круче) предпочтут AP650. Если точки одинаковые — в ход идут MAC-адреса и приоритеты. Хотите назначить менеджером самую малонагруженную точку в углу помещения — поправьте её приоритет командой «rf-damain-manager priority». Не хотите, чтобы точка вообще участвоваля в выборах — «no rf-domain manager capable». понять, кто сейчас в домене менеджер можно командой «sh rf-domain-manager»
Поскольку rf-domain manager общается напрямую с каждой точкой домена и занимается координацией роуминга, рассылкой ключей, софта, сбором статистики, переносом сессий stateful firewall при роуминге и прочая и прочая, следует опасаться включать центральный контроллер в расположенный за тридевять земель домен — весь этот трафик поедет по wan
При использовании vendor specific options в DHCP, он, понятно, выдаёт их всем, кому ни попадя. Другое дело, что интересны они только точкам (и врагам). Чтобы выдавать нужные опции только точкам (а, заодно, организовать их в компактный пул адресов) следует воспользоваться поддержкой классов в сервере DHCP. Каждая модель точки включает имя vendor class identifier в запрос DHCP. Например, для AP650 имя класса — MotorolaAP.AP650. Примеры как это сделать — в уже упомянутом документе «WiNG 5.X How-To Guide Centralized Deployments» На худой конец, если влом крутить DHCP и у вас не тысячи удалённых точек, можно обойтись выдачей по DHCP стандартного набора опций. Если в нём присутствует имя домена, то, не найдя в ответе DHCP сервера нужных опций, точка попытается найти контроллер по адресу motorola-wlc.имя.домена. Таким образом, вы намекаете всем желающим, где у вас контроллер ;)
Сервисный контракт можно заключить на год и на три (на три — только на новое оборудование). По окончании трёхлетнего контракта, его можно продлить минимум на два года. ПО всех зависимых точек уже входит в ПО контроллера, ПО автономных точек (обычно) доступно отдельно. Поскольку версия ПО на точках и контроллере (в идеале) должна совпадать — следует озаботиться покупкой хотя бы одного сервисного контракта на точку каждого типа. Сами по себе они ломаются редко ;)
При включении в кластер, перезагрузка контроллера не требуется.
При выключении точки она становится новенькой как с завода только если её не инструктировали сохранять конфигурацию (" configuration-persistence "). Обычно это актуально для зависимых точек и для заказчиков, страдающих параноей на тему «украдут точку — вскроют ей мозг». Для удалённых автономных точек важно иметь конфигурацию на борту для варианта «свет уже включили, а контроллера пока не видно». Вас также попросят включить сохранение конфигурации при попытке включить mesh — точка опасается остаться на мачте освещения без линка на ethernet и без идей, как правильно включить радио в этой дикой стране, чтобы не нарушить законодательство. При желании, можно написать «configuration-persistent secure» — из читабельной версии уберут упоминания про пароли.
Непонятно, что за цены. По каталогу AP-0650-66030-WW стоит $685. Если покупаете самое дешевое — убедитесь, что у вас есть силы всё самим настроить (как у авторов статьи). Обратите особое внимание на последние две буквы парт-номера — они должны быть WW или WR. В последнее время к нам через неразборчивых завозчиков попадает большое количество точек с буквами EU. Они предназначены для продажи в европе и не будут работать в rf-domain с country code ru. Сразу оговорюсь — НИКАК перепошить нельзя. Поэтому вам придётся включать в домене европейский код страны (например fi) и каждая точка будет посылать его 10 раз в секунду (с каждым beacon) с неоднозначными последствиями для клиентов и для вас, потому что это — хорошее начало для общения с регулирующими инстанциями.