Инженерный гайд по развёртыванию сети на контроллере NWS и управляемых точках SNR AP
Назначение документа
Этот документ описывает базовый порядок развёртывания беспроводной сети на базе системы NWS, в которой одна точка доступа работает в роли контроллера, а остальные точки работают в подчинённом режиме и управляются через контроллер.
Гайд ориентирован на системных администраторов, инженеров и технических специалистов. Он описывает первичное развёртывание и покрывает следующие вопросы:
- первоначальный доступ к устройству;
- выбор роли устройства;
- предварительную подготовку контроллера;
- создание обязательных объектов конфигурации;
- настройку профилей и политик;
- принятие точек на контроллер;
- базовую проверку результата.
В этом гайде приведён путь развёртывания через CLI.
Что нужно знать до начала работ
Логика развёртывания
В типовой схеме одна точка переводится в режим контроллера. Остальные точки остаются в режиме Managed by the controller и пытаются обнаружить контроллер. После обнаружения контроллер отображает такие точки в show adoption в состоянии JOIN_REQ.
Принятие точки выполняется командой system adopt <AP ID>. Это немедленная system-операция: она не создаёт строку в running-config, не сохраняется в startup-config и не требует commit. Состояние принятия хранится во внутренней базе контроллера. Точка считается принятой только после того, как контроллер получил её полную identity: AP ID, management IP, MAC address, model, serial number и firmware version.
Конфигурация точки хранится отдельно, в секции device <AP ID>. Если после принятия у точки ещё нет device-секции, она может быть создана автоматически политикой Auto Provision при следующем commit или commit write.
Если точка принята на контроллер, через локальный интерфейс можно получить диагностическую информацию или сбросить точку к заводским настройкам.
Если и контроллер и точки находятся в одном broadcast domain и получают адреса от DHCP, дополнительная настройка обнаружения контроллера обычно не требуется.
Если контроллер и точки находятся в разных сегментах сети и между ними нет L2-доступности, точкам необходимо сообщить адрес контроллера через DHCP option 43 или option 138, либо задать адрес контроллера вручную на точке.
Важные особенности архитектуры
- Устройство всегда должно быть привязано к одному
Site. - Устройство всегда должно использовать один
Profile. - Политики начинают работать только после применения на уровне
ProfileилиDevice. - Настройки уровня
Deviceимеют приоритет над настройками уровняProfile. - L3-функции реализованы только на
VLAN-интерфейсах. - На уровне
Profileнельзя настраивать статические IP-адреса. Статическая адресация допустима только на уровнеDevice. - Состояние
adoptionхранится отдельно отrunning-configиstartup-config. system adoptиno system adoptвыполняются немедленно и не требуютcommit.device <AP ID>описывает конфигурацию AP, но не является фактом принятия AP на контроллер.- В
show adoptionполеCONFIGпоказывает наличие или отсутствиеdevice-секции для AP. Auto Provisionзапускается наcommitилиcommit writeи создаётdevice-секцию только для AP в состоянииADOPTED, если такой секции ещё нет.
Для успешного взаимодействия между точкой и контроллером должны быть открыты следующие порты - 8883 TCP - управление; 4433 TCP - обновление прошивок контроллером на точках; 5353 UDP - обнаружение точками контроллера.
Рекомендации по подготовке
- До принятия подчинённых точек предварительно настройте контроллер.
- Основные массовые настройки точек выполняйте на уровне
Profile. - Индивидуальные параметры для отдельных точек и настройки контроллера задавайте на уровне
Device. - По возможности используйте DHCP reservation/binding вместо статической адресации для подчинённых точек.
- Созданная, но нигде не применённая политика работать не будет.