Архитектура Unified Wireless Network предполагает централизованное управление всеми точками доступа (далее ТД) с единого интерфейса — контроллера беспроводной сети, на который точки доступа должны предварительно зарегистрироваться.

Для быстрого устранения неисправностей в беспроводной сети очень полезно понимание CAPWAP State Machine (последовательности перехода состояний) при взаимодействии точки доступа и контроллера. CAPWAP State Machine описан в стандарте RFC 5415 (CAPWAP Protocol Specification). В данной статье детально описаны состояния Discovery в реализации Cisco Unified Wireless. В последующих статьях будут описаны состояния Join, Failover и Fallback в реализации Cisco Unified Wireless.

CAPWAP Discovery Phase IPv4 в Cisco Wireless AireOS

Регистрация точки доступа на определенный контроллер состоит из следующих этапов:

Discovery Phase (фаза обнаружения);
- Точка доступа посылает CAPWAP Discovery Request всем известным контроллерам;
- Каждый контроллер, получивший CAPWAP Discovery Request отвечает сообщением CAPWAP Discovery Response;
Join Phase (фаза подключения)
- Исходя из данных, собранных в СAPWAP Discovery Response пакетах, точка доступа выбирает, к какому контроллеруподключиться и посылает ему CAPWAP Join request
- Контроллер проверяет точку доступа и посылает CAPWAP Join response
- Точка доступа проверяет контроллер.

CAPWAP discovery request посылается на IP адрес Management интерфейса контроллера.
Чтобы точка доступа определила, куда посылать CAPWAP discovery request, предусмотрено несколько инструментов, но для начала работы механизмов поиска точке доступа необходимо получить IP адрес. Это можно сделать по DHCP или задать его вручную. Далее начинают работать механизмы поиска. Точка доступа посылает CAPWAP discovery request всем контроллерам, которые удалось обнаружить и формирует список контроллеров, из которого уже выбирает, к какому конкретному контроллеру подключиться (послать CAPWAP Join Request).

ТД посылает широковещательный запрос третьего уровня (layer 3 local broadcast на адрес 255.255.255.255;
ТД смотрит в локальный список контроллеров, хранящийся на NVRAM;
ТД при запросе DHCP адреса смотрит в DHCP Option 43 в DHCP offer сообщении;
Точка доступа пытается разрешить DNS имена CISCO-CAPWAP-CONTROLLER.local-domain или CISCO-LWAPP-CONTROLLER.local-domain

Работа механизмов CAPWAP Discovery Phase IPv4

Посмотреть текущие настройки ТД можно через консоль с помощью команды:

show capwap client config

Если на точке доступа были сделаны какие-то изменения, можно восстановить первоначальную конфигурацию, удалив private-config и настройки IP адреса.

clear capwap private-config
clear capwap ap ip address
clear capwap ap ip default-gateway

В текущих испытаниях всегда хватало команды clear capwap private-config, но в книге Deploying and Troubleshooting Cisco Wireless LAN Controllers автор рекомендует, чтобы ТД точно забыла все известные контроллеры, использовать команду erase /all nvram: для которой, в свою очередь, нужно активировать debugging/troubleshooting режим командой debug capwap console cli.

debug capwap console cli
erase /all nvram:

Далее перезагрузить точку доступа.

reload

После перезагрузки можно убедиться (если сервис DHCP не запущен), что пока точка доступа не получила IP адрес, она не может начать Discovery Phase:

%CAPWAP-3-ERRORLOG: Not sending discovery request AP does not have an Ip !!

%CAPWAP-3-DHCP_RENEW: Could not discover WLC using DHCP IP. Renewing DHCP IP.

Для того, чтобы начать Discovery Phase, точке доступа нужно выдать адрес по DHCP или задать статически через консоль с помощью команд:

capwap ap ip address ip mask
capwap ap ip default-gateway ip

1) Layer 3 local broadcast

Точка доступа посылает широковещательный Discovery request на адрес 255.255.255.255 по UPD порту 5246. Discovery request обрабатывается Management интерфейсом контроллера. Если Management интерфейс контроллера и интерфейс ТД находятся в одном VLAN, то контроллер обработает этот запрос и отправит Discovery response.

После того, как точке доступа получает адрес, она активирует все возможные механизмы поиска и в результате получает Discovery response благодаря широковещательной рассылки Discovey request.

delphi
%DHCP-6-ADDRESS_ASSIGN: Interface BVI1 assigned DHCP address 10.0.191.7, mask 255.255.255.0, hostname AP001b.d542.1d2c
AP001b.d542.1d2c#
Translating "CISCO-CAPWAP-CONTROLLER"...domain server (255.255.255.255)
AP001b.d542.1d2c#
*Dec 28 02:26:04.306: %CAPWAP-3-ERRORLOG: Did not get log server settings from DHCP.
Translating "CISCO-LWAPP-CONTROLLER"...domain server (255.255.255.255)
*Dec 28 02:26:13.307: %CAPWAP-3-ERRORLOG: Could Not resolve CISCO-CAPWAP-CONTROLLER
*Dec 28 02:26:22.308: %CAPWAP-3-ERRORLOG: Could Not resolve CISCO-LWAPP-CONTROLLER
*Dec 28 02:26:32.309: %CAPWAP-3-ERRORLOG: Go join a capwap controller 
*Mar 16 10:18:26.000: %CAPWAP-5-DTLSREQSEND: DTLS connection request sent peer_ip: 10.0.191.4 peer_port: 5246
*Mar 16 10:18:28.500: %CAPWAP-5-DTLSREQSUCC: DTLS connection created sucessfully peer_ip: 10.0.191.4 peer_port: 5246
*Mar 16 10:18:28.502: %CAPWAP-5-SENDJOIN: sending Join Request to 10.0.191.4

Теперь попробуем поместить точку доступа в другой VLAN, предварительно обнулив её конфигурацию. Подключения не происходит.

delphi
*Dec 28 01:55:27.942: %DHCP-6-ADDRESS_ASSIGN: Interface BVI1 assigned DHCP address 10.0.192.3, mask 255.255.255.0, hostname AP001b.d542.1d2c
Translating "CISCO-CAPWAP-CONTROLLER"...domain server (255.255.255.255)
*Dec 28 01:55:32.817: %CAPWAP-3-ERRORLOG: Did not get log server settings from DHCP.
Translating "CISCO-LWAPP-CONTROLLER"...domain server (255.255.255.255)
*Dec 28 01:55:41.817: %CAPWAP-3-ERRORLOG: Could Not resolve CISCO-CAPWAP-CONTROLLER
*Dec 28 01:55:50.818: %CAPWAP-3-ERRORLOG: Could Not resolve CISCO-LWAPP-CONTROLLER*Dec 28 01:56:36.324: %CAPWAP-3-DHCP_RENEW: Could not discover WLC using DHCP IP. Renewing DHCP IP.

Широковещательный запрос не попадает на Management интерфейс контроллера, так как точка доступа находится в другом VLAN.

В этом случае можно принудительно перенаправить широковещательных запрос на Management интерфейс контроллера. Для этого необходимо активировать перенаправление широковещательного трафика именно по UDP порту 5246 с помощью команды

forward-protocol udp 5246

и на интерфейсе третьего уровня прописать

ip helper-address [адрес контроллера]

В конфигурации коммутатора это выглядит так:

CAT2(config)#ip forward-protocol udp 5246
CAT2(config)#int vlan 192
CAT2(config-if)#ip helper-address 10.0.191.4

Тогда широковещательный запрос так же попадет на контроллер и точка подключится к контроллеру.

2) Локальный список NVRAM

Точка доступа смотрит в собственный список контроллеров, который хранится в энергонезависимой памяти NVRAM. В NVRAM хранится следующая информация. Primary, Secondary и Tertiary контроллер, сконфигурированный предварительно на точке доступа. Эти настройки могут быть заданы как на самой точке доступа через CLI, так и, в случае если точка доступа подключена к контроллеру, через контроллер (через CLI или web). Последний подключенный контроллер и его Mobility Members в той же группе. По поводу этой части в документации есть небольшие расхождения, про которые будет рассказано ниже в соответствующем разделе.

Primary, Secondary и Tertiary контроллер

На точке доступа данные об контроллере можно задать двумя командами. Одна из них — capwap ap controller ip address.

delphi
AP001b.d542.1d2c#capwap ap controller ip address 10.0.191.4
*Dec 28 01:57:11.888: %CAPWAP-3-ERRORLOG: Go join a capwap controller

Действие этой команды отображается в двух выводах:

delphi
AP001b.d542.1d2c#sh capwap ip config
LWAPP Static IP Configuration
IP Address 10.0.192.102
IP netmask 255.255.255.0
Default Gateway 10.0.192.1
Primary Controller 10.0.191.3

delphi
AP001b.d542.1d2c#sh capwap cli con 
...
mwarName 
mwarIPAddress 10.0.191.4

То есть с одной стороны контроллер его прописывает в конфигурацию статического IP, с другой стороны, он его прописывает как Primary. Если хитрыми манипуляциями оставлять или в одном месте или в другом, то все равно происходит подключение к данном контроллеру.

Primary, Secondary или Tertiary на точке доступа можно задать с помощью команд:

capwap ap primary-base [wlc_sysname] [IP];
capwap ap secondary-base [wlc_sysname] [IP];
capwap ap tertiary-base [wlc_sysname] [IP];
delphi
AP001b.d542.1d2c#capwap ap primary-base wlc2504 10.0.191.4
*Dec 28 01:57:44.901: %CAPWAP-3-ERRORLOG: Selected MWAR 'wlc2504'(index 0).
*Dec 28 01:57:44.901: %CAPWAP-3-ERRORLOG: Go join a capwap controller
AP001b.d542.1d2c#sh capwap client config 
..
mwarName wlc2504
mwarIPAddress 10.0.191.4

Не обязательно указывать Primary, можно указать только Secondary:

delphi
AP001b.d542.1d2c#capwap ap secondary-base wlc2504 10.0.191.4
*Dec 28 01:57:04.097: %CAPWAP-3-ERRORLOG: Selected MWAR 'wlc2504'(index 1).
*Dec 28 01:57:04.097: %CAPWAP-3-ERRORLOG: Go join a capwap controller

Primary, Secondary, Tertiary контроллеры можно так же прописать не только через консоль точки доступа, но и через CLI или web интерфейсе контроллера (если точка уже подключена к какому-то контроллеру).

(Cisco Controller) >config ap secondary-base wlc2 AP001b.d542.1d2c 10.0.191.5
delphi
AP001b.d542.1d2c#sh capwap cli con
..
mwarName wlc2
mwarIPAddress 10.0.191.5

Последний подключенный контроллер и его Mobility Members в той же группе.

Как было описано выше, по данному пункту есть небольшие расхождения. К примеру

в Configuration Guide на версию ПО 8.0 не написано про это, только про Primary, Secondary или Tertiary контроллеры, так же, как и в Troubleshooting Technote
если посмотреть другой Troubleshooting Technote и ранее упомянутую книгу "Deploying and Troubleshooting Cisco Wireless LAN Controllers", то там написано про то, что в NVRAM хранится информация о последнем подключенном контроллере и его Mobilibty Members в той же группе.
еще в одном документе написано, что точка доступа забывает при перезагрузке всю информацию о mobilibty members, но помнит последний подключенный контроллер: "Remember that the AP forgets the mobility members across reboots."
Для начала, с помощью тестов, я постарался выяснить, действительно ли при перезагрузке точка доступа забывает о всех mobility members.

Mobility members отображаются в стройках "Configured Switch Х" вывода show capwap client config:

delphi
AP001b.d542.1d2c#sh capw cli con
... 
Configured Switch 1 Addr 10.0.191.4
Configured Switch 2 Addr 10.0.193.4

Предварительно точки доступа были помещены в изолированный VLAN и все механизмы Discovery, кроме как через NVRAM исключены (в том числе Primary, Secondary и Tertiary). Тесты проводились на ПО 8.0.140.0 (15.3(3)JA10).

Точка доступа подключалась к контроллеру 10.0.193.4, на котором в той же Mobilibty Group был прописан контроллер 10.0.191.4. При перезагрузке точка доступа подключалась к контроллеру 10.0.191.4 (точка находилась в другом VLAN и broadcast discovery не мог работать).

То есть в данных тестах все же подтверждалась информация из заголовка: точка доступа по крайней мере в данной версии ПО хранит в NVRAM информацию о mobility members той же группы и п��сылает им discovery request.

Последний контроллер, к которому подключена точка доступа, технически так же является mobility member той же группы. При тестах точка доступа сохраняла данные о последнем подключенном контроллере в записи "Configured Switch 1".

3) DHCP Option 43

Наиболее часто используемым в инсталляциях способом является передача адреса контроллера в 43-й опции DHCP offer пакета, вместе с IP адресом.

Адрес контроллера записывается следующим образом (в шестнадцатиричной форме):

f1[количество контроллеров * 4][IP адрес контроллера(ов)]

К примеру для контроллеров 10.0.191.4 и 10.0.191.5 опция 43 выглядит следующим образом:

f1080a00bf040a00bf05

Для коммутатора синтаксис выглядит так:

CAT2(dhcp-config)#option 43 hex f108.0a00.bf04.0a00.bf05

Вывод с точки доступа:

delphi
*Dec 28 01:56:13.045: %DHCP-6-ADDRESS_ASSIGN: Interface BVI1 assigned DHCP address 10.0.192.2, mask 255.255.255.0, hostname AP001b.d542.1d2c
*Dec 28 01:56:23.945: %CAPWAP-5-DHCP_OPTION_43: Controller address 10.0.191.4 obtained through DHCP
*Dec 28 01:56:23.945: %CAPWAP-5-DHCP_OPTION_43: Controller address 10.0.191.5 obtained through DHCP
*Dec 28 01:56:51.950: %CAPWAP-3-ERRORLOG: Go join a capwap controller

Если настроить только опцию 43, то в данном случае она будет возвращаться всем без исключения, не только точкам доступа.

Если требуется, чтобы эта опция возвращалась только точкам доступа Cisco, то существует возможность проверки VCI (Vendor class identifier) в DHCP discover. Каждая модель точки доступа передаёт определенный VCI в DHCP discover. Если на DHCP сервере прописать Option 60 с соответствующим VCI, то опция 43 будет выдаваться только тем клиентам, которые в запросе передают точно такой же VCI.

Идея состоит в том, чтобы не передавать 43-ю опцию тем, кому это не надо. Но тут есть и другой момент. Если в одном пуле присутствуют точки доступа двух разных серий, не все DHCP серверы поддерживают возможность задания нескольких VCI, это необходимо предварительно проверить.

4) DNS

очка доступа пытается разрешить DNS имена CISCO-CAPWAP-CONTROLLER.local-domain или CISCO-LWAPP-CONTROLLER.local-domain.

Для этого на точке доступа (в пуле DHCP) необходимо прописать DNS сервер и домен. Настраиваем соответствующим образом DNS сервер.

CAT2(dhcp-config)#dns-server 10.0.191.8
CAT2(dhcp-config)#domain test.local

После получения адреса контроллер может разрешить имя и использовать IP адрес в Discovery Phase.

delphi
Translating "CISCO-CAPWAP-CONTROLLER.test.local"...domain server (10.0.191.4)
[OK]

После поиска всеми возможными способами контроллеров, посылки им Discovery request, получении Discovery response, формируется список контроллеров, на основании которого решается, к какому контроллеру попробовать подключиться (послать Join Request).

CAPWAP State Machine в реализации Cisco Unified Wireless: состояние Discovery