Cisco Support Community
отмена
Отображаются результаты для 
Вместо этого искать 
Вы имели в виду: 
cancel
Объявления
Добро пожаловать в Сообщество Технической поддержки Cisco. Мы рады получить обратную связь .

Беспроводные технологии Блоги(Wireless)

65 просмотров
0 Комментариев

Когда точка доступа уже подключилась к контроллеру (AP Join), есть два механизма, которые влияют на выбор контроллера. 

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

Если точке доступа, не теряя связь с контроллером, требуется перейти на другой контроллер, для этого существует механизм AP Fallback

AP Failover

AP Failover использует следующую информацию в порядке приоритета. Сначала наибольший приоритет.

  1.  Per AP Primary, Secondary и Tertiary controller
  2. Global Backup Primary/Secondary WLC
    1. Эти параметры начинают работать только когда активирован FastHeartbeat Timeout . 
    2. Данная информация не сразу активируется на точке, а через какое то время. Она должна появиться в так называемом Backup WLС arrey.
  3. WLC Mobility Group Membership

WLC Mobility Group Membership

Проведем тестирование, начиная с наименьшего приоритета, постепенно увеличивая его. 

В нашем распоряжении есть точка доступа, подключенная к контроллеру vwlc2 (10.0.194.4), на котором настроена только Mobility Group member vwlc (10.0.193.4). 

LAP1#sh capwap cli con
mwarName
mwarIPAddress 0.0.0.0
mwarName
mwarIPAddress 0.0.0.0
mwarName
mwarIPAddress 0.0.0.0
Configured Switch 1 Addr 10.0.193.4
Configured Switch 2 Addr 10.0.194.4

Далее выключаем интерфейсы на vwlc2.

config port adminmode all disable

И смотрим за реакцией точки доступа.

*Mar 20 09:29:18.207: %DTLS-5-SEND_ALERT: Send FATAL : Close notify Alert to 10.0.194.4:5246
*Mar 20 09:29:54.000: %CAPWAP-5-DTLSREQSEND: DTLS connection request sent peer_ip: 10.0.193.4 peer_port: 5246
*Mar 20 09:29:54.520: %CAPWAP-5-DTLSREQSUCC: DTLS connection created sucessfully peer_ip: 10.0.193.4 peer_port: 5246
*Mar 20 09:29:54.521: %CAPWAP-5-SENDJOIN: sending Join Request to 10.0.193.4

Без фазы Discovery точка доступа подключилась к 10.0.193.4.

Global Backup Primary/Secondary WLC

Теперь протестируем следующий по приоритету механизм - Backup Primary/Secondary WLC. Пропишем на контроллере vwlc2 адрес Backup Primary 10.0.191.4 (wlc2504), его нет в mobility group members.

config advanced backup-controller primary wlc2504 10.0.191.4

Посмотреть, как "спустились" данные настройки на точку, можно с помощью команды

LAP1#sh capwap cli ha
fastHeartbeatTmr disabled
primaryDiscoverTmr(sec) 120
primaryBackupWlcIp 10.0.191.4
primaryBackupWlcName wlc2504
secondaryBackupWlcIp 0.0.0.0
secondaryBackupWlcName
DHCP renew try count 0
Fwd traffic stats get 0
Fast Heartbeat sent 0
Discovery attempt 0
Backup WLC array:

Теперь выключаем все интерфейсы на подключенном контроллере. Подключение произошло на контроллер в той же самой mobility group (10.0.193.4). Это произошло, так как не были настроены FastHeartbeat Timeout. Настроим их. 

config advanced timers ap-fast-heartbeat local enable 10

Проверим, что данная настройка "спустилась" на точку

LAP1#sh capwap cli ha
fastHeartbeatTmr(sec) 10 (enabled)
primaryDiscoverTmr(sec) 120
primaryBackupWlcIp 10.0.191.4
primaryBackupWlcName wlc2504
secondaryBackupWlcIp 0.0.0.0
secondaryBackupWlcName
DHCP renew try count 0
Fwd traffic stats get 12
Fast Heartbeat sent 12
Discovery attempt 0
Backup WLC array:
Index [3] System name wlc2504
Index [3] IP 10.0.191.4
Index [3] Aging Count 0

Видны значительные изменения: счетчик "Fast Heartbeat sent" и "Fwd traffic stats get" увеличивается, в Backup WLC arrey появился контроллер wlc2504 (он появляется не сразу, а через какое-то время, только после этого механизм начинает работать!)

Теперь выключаем все интерфейсы на подключенном контроллере.

*Mar 20 09:29:18.207: %DTLS-5-SEND_ALERT: Send FATAL : Close notify Alert to 10.0.194.4:5246
*Mar 20 09:29:54.000: %CAPWAP-5-DTLSREQSEND: DTLS connection request sent peer_ip: 10.0.191.4 peer_port: 5246
*Mar 20 09:29:54.520: %CAPWAP-5-DTLSREQSUCC: DTLS connection created sucessfully peer_ip: 10.0.191.4 peer_port: 5246
*Mar 20 09:29:54.521: %CAPWAP-5-SENDJOIN: sending Join Request to 10.0.191.4

Точка доступа подключилась к Backup Primary. 

Per AP Primary, Secondary и Tertiary controller

Настроим Primary контроллер снова на vwlc - 10.0.193.4 и убедимся, что Backup Primary так же настроен. 

LAP1#sh capwap cli con
mwarName wvlc
mwarIPAddress 10.0.193.4
LAP1#sh capwa cli ha
fastHeartbeatTmr(sec) 10 (enabled)
primaryDiscoverTmr(sec) 120
primaryBackupWlcIp 10.0.191.4
primaryBackupWlcName wlc2504
secondaryBackupWlcIp 0.0.0.0
secondaryBackupWlcName
DHCP renew try count 0
Fwd traffic stats get 32
Fast Heartbeat sent 32
Discovery attempt 0
Backup WLC array:
Index [3] System name wlc2504
Index [3] IP 10.0.191.4
Index [3] Aging Count 0

Теперь выключим контроллер. 

*Mar 20 09:29:18.207: %DTLS-5-SEND_ALERT: Send FATAL : Close notify Alert to 10.0.194.4:5246
*Mar 20 09:29:54.000: %CAPWAP-5-DTLSREQSEND: DTLS connection request sent peer_ip: 10.0.193.4 peer_port: 5246
*Mar 20 09:29:54.520: %CAPWAP-5-DTLSREQSUCC: DTLS connection created sucessfully peer_ip: 10.0.193.4 peer_port: 5246
*Mar 20 09:29:54.521: %CAPWAP-5-SENDJOIN: sending Join Request to 10.0.193.4

Как видно, точка доступа подключилась к Primary controller, проигнорировав настройку Backup Primary. 

AP Fallback

Когда функция AP Fallback активирована ( закладка CONTROLLER->General), точка доступа может поменять контроллер даже в том случае, если связь с текущим контроллером не потеряна.

Это может произойти в следующих случаях.

1) Если на точке настроен Per AP Primary, Secondary и Tertiary controller и точка доступа не находится на одном из этих трех контроллеров. С Secondary точка доступа не будет переходить на Primary.

2) Если на контроллере настроен Global Backup Primary/Secondary WLC , на котором в свою очередь настроен режим Master Controller Mode.

Постараемся проверить оба варианта.

Точка доступа подключена к контроллеру vwlc2 (10.0.194.4), пропишем на контроллере Primary контроллер 2504(10.0.191.4) и посмотрим, что произойдет. Через какое-то время, точа переключается самостоятельно на контроллер, при этом mobility members на обоих контроллерах не прописаны. 

*Mar 20 09:29:18.207: %DTLS-5-SEND_ALERT: Send FATAL : Close notify Alert to 10.0.194.4:5246
*Mar 20 09:29:54.000: %CAPWAP-5-DTLSREQSEND: DTLS connection request sent peer_ip: 10.0.191.4 peer_port: 5246
*Mar 20 09:29:54.520: %CAPWAP-5-DTLSREQSUCC: DTLS connection created sucessfully peer_ip: 10.0.191.4 peer_port: 5246
*Mar 20 09:29:54.521: %CAPWAP-5-SENDJOIN: sending Join Request to 10.0.191.4

Во втором случае пропишем на wlc2504 Master Controller Mode (все остальные настройки остались с проверки AP Failover. Через какое-то время точка доступа подключается к 10.0.191.4

*Mar 20 09:29:18.207: %DTLS-5-SEND_ALERT: Send FATAL : Close notify Alert to 10.0.194.4:5246
*Mar 20 09:29:54.000: %CAPWAP-5-DTLSREQSEND: DTLS connection request sent peer_ip: 10.0.191.4 peer_port: 5246
*Mar 20 09:29:54.520: %CAPWAP-5-DTLSREQSUCC: DTLS connection created sucessfully peer_ip: 10.0.191.4 peer_port: 5246
*Mar 20 09:29:54.521: %CAPWAP-5-SENDJOIN: sending Join Request to 10.0.191.4

88 просмотров
0 Комментариев

Каким же образом точка доступа выбирает, к какому контроллеру подключиться? 

В процессе фазы Discovery контроллер формирует список доступных контроллеров (controller list).

В Discovery response возвращается следующая информация

  • Ap-Manager интерфейс контроллера (именно к нему подключаются точки доступа, это может быть один и тот же логический IP интерфейс, что и Management);
  • sysname контроллера;
  • тип контроллера;
  • количество подключенных точек (к AP-Manager интефрейсу) и свободная емкость контроллера (сколько еще точек доступа можно подключить);
  • флаг Master Controller Mode.

Точка доступа посылает Join Request в следующей очередности, последовательно (только тем, от которых получила Discovery response, то есть которые присутствуют в controller list):

  1. Точка доступа пытается послать Join Request контроллеру Primary Controller. Sysname в discovery response и прописанный на точке доступа должны совпадать!
  2. Если в сontroller list нет контроллера, который прописан как Primary, то точка доступа пытается послать Join Request следующему, Secondary Controller
  3. Если в controller list нет контроллеров, которые прописаны как Primary, Secondary, то точка доступа пытается послать Join Request контроллеру Tertiary.
  4. Контроллер с установленным флагом Master Controller Mode
  5. Если точке доступа не удалось подключиться на этапе 1-4 , то она из оставшегося списка выбирает контроллер с наибольшей свободной ёмкостью. Тем самым, точки доступа балансируются между контроллерами (AP-Manager) интерфейсами контроллера(ов).

Как можно настроить  можно настроить Primary, Secondary и Tertiary контроллеры, указано в предыдущей статье

Master Controller через CLI настраивается (по умолчанию этот режим выключен) с помощью команды 

config network master-base enable

Через web интерфейс Master Controller можно настроить через закладку CONTROLLER->Advanced->Master Controller Mode

В фазе Discovery не происходит какая либо проверка точек доступа. Но на этапе Join она присутствует. 

  1. Точка доступа посылает Join Request, в котором присутствует X.509 сертификат.
  2. Контроллер проверяет сертификат точки доступа и посылает Join Response, в котором так же присутствует X.509 сертификат.
  3. Точка доступа проверяет сертификат контроллера.  

Если на каком-то этапе проверка не проходит, точка доступа пробует послать Join Request следующему по списку контроллеру. 

Для демонстрации возьмем два контроллера: 2504 с 5 лицензиями, vwlc с 12 лицензиями. А так же в нашем распоряжении четыре точки доступа. 

Пропишем на точках доступа в NVRAM (с помощью Mobility members, заодно проверим, что они запоминаются), все два контроллера, перезагрузим их и посмотрим, как они распределились между контроллерами. 

LAP2#sh cap cli con
Configured Switch 1 Addr 10.0.191.5
Configured Switch 2 Addr 10.0.193.4

По умолчанию, без каких либо настроек, все четыре точки доступа подключаются к контроллеру vwlc (он не является ни Primary, Secondary и Tertiary, ни Master Controller Mode, а проходит по последнему пункту "наибольшая свободная ёмкость"). Наибольшая свободная ёмкость, очевидно, считается по количеству свободных слотов для точек доступа (а не, к примеру, в процентах, иначе, хотя бы одна точка доступа подключилась бы к 2504).  

Далее, не меняя настроек, пропишем Master Controller Mode на 2504 и снова перезагрузим все точки доступа. 

config network master-base enable

В результате все точки доступа подключаются к 2504, ни одна не подключается к vwlc, несмотря на то, что на ней очень много свободной ёмкости. 

Далее на контроллере последовательно пропишем Tertiary контроллер и перезагрузим, затем добавим Secondary и перезагрузим, затем Primary и перезагрузим. Каждый раз точка доступа подключается к наиболее приоритетному контроллеру. 

В процессе тестов выяснилось несколько интересных моментов (которые можно встретить, вероятно, только в лаборатории).

1. Технически Master controller Mode можно прописать на нескольких контроллерах. Как в этом случае поступает точка доступа? Частично ответ я нашел в старом документе: "There should never be more than one WLC configured as a Master Controller." То есть в правильно настроенной сети такого быть не должно.

2. У меня в наличии был старый контроллер 4402 с ПО 7.0 (выше он не поддерживает). В случае, когда я пытался балансировать точки между 4402 и vwlc точки доступа, если на них не было прописано ни Primary, Secondary и Tertiary, ни Master Controller Mode, всегда выбирали контроллер с той же версией ПО, что и на них ( балансировки по "свободной ёмкости" не было). Если на 4402 было прописано Master Controller Mode - точки доступа, несмотря на старую версию ПО, сразу переключались на него. 

Правильно настроенная сеть должна исключать оба этих варианта. 

215 просмотров
0 Комментариев

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

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

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

В данной статье будет подробно описан механизм CAPWAP Discovery Phase IPv4.

CAPWAP discovery request посылается на IP адрес Management интерфейса контроллера. 

Чтобы точка доступа определила, куда посылать CAPWAP discovery request, предусмотрено несколько инструменов. 

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

  1. ТД посылает широковещательный запрос третьего уровня (layer 3 local broadcast на адрес 255.255.255.255;
  2. ТД смотрит в локальный список контроллеров, хранящийся на NVRAM;
  3. ТД при запросе DHCP адреса смотрит в DHCP Option 43 в DHCP offer сообщении;
  4. Точка доступа пытается разрешить 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. 

%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, предварительно обнулив её конфигурацию. Подключения не происходит.

*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 хранится следующая информация.

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

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

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

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
Действие этой команды отображается в двух выводах:
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

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];
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:

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

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:

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

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

*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.

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

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

91 просмотров
0 Комментариев

Чем дальше погружаюсь в тему Wi-Fi позиционирования, тем очевиднее становится факт, что основная задача заключается не в достижении необходимой точности, а в получении необходимого количества замеров! Почему я так думаю?

Требования к плотности размещения точек доступа с каждым годом увеличиваются, что положительно сказывается на точности позиционирования, а вот частота замеров по Probe Request не становится выше, скорее наоборот.

В связи с этим многие производители разработали свои собственные инструменты для увеличения частоты замеров. Традиционно, одним из инноваторов в этой области выступает компания Cisco, которая вывела на рынок инструмент под названием Cisco FastLocation.
Давайте попробуем разобраться во всех нюансах этого инструмента.

FastLocate = Data RSSI


Для начала что же подразумевается под маркетинговыми словами Cisco FastLocate? Если совсем кратко, то это замер уровня сигнала (RSSI) не по management пакетам Probe Request, а по пакетам данных (data). Такой режим замера называется “Data RSSI” (в дополнение к “Probe RSSI”). Далее в статье я буду использовать в зависимости от контекста и тот и другой термин.

FastLocate Release 8.0 vs FastLocate Release 10.2


Технология Cisco FastLocation появилась в 2014 году, когда система позиционирования Cisco начала сильно эволюционировать.

На тот момент она имела достаточно ограниченный функционал, поддерживалась только на специально установленных модулях мониторинга WSM (Wireless Security Module), которые устанавливались в модульные, то есть топовые офисные точки доступа. Это была так называемый FastLocate MSE Release 8.0.

Данную технологию мы рассматривать не будем, так как сейчас актуальна новая, совершенно переработанная версия FastLocate CMX Release 10.2.

Именно её мы будем тестировать с использованием контроллера Cisco WLC 2504 с версией ПО 8.1.131.20 и точек серии Cisco Aironet 3602.

FastLocate без использования дополнительных модулей


Первый вопрос, который мне пришел в голову: можно ли делать Data RSSI без использования дополнительных модулей? В арсенале Cisco уже есть возможность перевести точку доступа в режим мониторинга (сканирования) всех каналов, есть гибридный режим работы, когда точка обслуживает как пользователей, так и сканирует смежные каналы. Можем ли мы использовать эти режимы для Data RSSI?

FastLocate в гибридном режиме ELM


Если в 8-й версии CMX такое было невозможно, то к 10-й версии CMX такая опция появилась. У точек доступа Cisco есть специальный режим работы Enhanced Local Mode (ELM), в котором помимо обслуживания клиентов, точка доступа выполняет так называемый Off-Channel Scanning, то есть сканирует смежные каналы. Это происходит не без потери производительности, которая составляет порядка 15%.

Off-Channel Scanning при выключенном FastLocate


Off-Channel Scanning происходит в весьма неспешной манере и изначально предназначен для обнаружения чужих точек доступа на смежных каналах. Как это работает можно посмотреть здесь и здесь.

К примеру, по умолчанию в диапазоне 2.4ГГц настроено сканирование всех каналов и интервал полного сканирования 180с. В данном режиме точка доступа каждые 180/13=14 секунд прерывается на 50мс на сканирование смежного канала (на переход в каждую сторону так же тратиться 10мс). Картина выглядит примерно вот так:
image
Работу данного алгоритма можно проверить непосредственно на точке доступа при помощи команды debug dot11 do0 trace print channel

Hyperlocation_2#debug dot11 do0 trace print channel 
Oct  4 10:09:37.909: CC0CDA4C-0 Channel 8 (2447) promiscuous  20MHz
Oct  4 10:09:37.957: CC0D772F-0 Channel 11 (2462)  20MHz
Oct  4 10:09:50.753: CCD0DEF8-0 Channel 9 (2452) promiscuous  20MHz
Oct  4 10:09:50.801: CCD17BD3-0 Channel 11 (2462)  20MHz
Oct  4 10:09:53.955: CD948399-0 Channel 10 (2457) promiscuous  20MHz
Oct  4 10:09:53.999: CD951CFD-0 Channel 11 (2462)  20MHz
Oct  4 10:10:06.763: CE57FEC4-0 Channel 11 (2462) promiscuous  20MHz
Oct  4 10:10:06.811: CE589BA7-0 Channel 11 (2462)  20MHz


По данному выводу можно увидеть, что периодичность сканирования порядка 13 секунд, что сходится с документацией. Применение Data RSSI в таком режиме было бы не очень эффективно (забегая вперед скажу, что он и не используется).

Off-Channel Scanning при включенном FastLocate


Если на беспроводном контроллере активировать FastLocate, то Off-Channel Scanning начинает работать несколько иначе.

Hyperlocation_2#debug dot11 do0 trace print channel 
Oct  4 10:05:40.887: BDEC139E-0 Channel 12 (2467) promiscuous  20MHz
Oct  4 10:05:40.967: BDED365C-0 Channel 11 (2462)  20MHz
Oct  4 10:05:43.691: BE16D8E7-0 Channel 13 (2472) promiscuous  20MHz
Oct  4 10:05:43.771: BE17FBC2-0 Channel 11 (2462)  20MHz
Oct  4 10:05:46.775: BE45D2A0-0 Channel 11 (2462)  20MHz
Oct  4 10:05:46.983: BE4919C1-0 Channel 14 (2484) promiscuous listen_only 20MHz
Oct  4 10:05:47.063: BE4A3D27-0 Channel 11 (2462)  20MHz
Oct  4 10:05:49.795: BE7407C6-0 Channel 1 (2412) promiscuous  20MHz
Oct  4 10:05:49.879: BE75291D-0 Channel 11 (2462)  20MHz


Временные интервалы уменьшаются до трех секунд. Технической документации в части того, как работает Off-Channel Scanning при активированном FastLocate я не нашел, но исходя из приведенного вывода можно сделать вывод, что время сканирования составляет так же порядка 50 мс ( 967-887 = 80 мс, это 50-60 мс на сканирование + 10 мс на переключение между каналами).

Очевидно, уменьшение временных интервалах было сделано для улучшения работы механизма FastLocation.

Зависимость Off-Channel Scanning от режима работы wIPS


Точка доступа может работать с локальным или централизованным wIPS (системой обнаружения и предотвращения вторжений), что регулируется настройкой на точке доступа. Тестируя Off-Channel Scanning в разных режимах работы wIPS я не увидел отличий.

FastLocate в режиме Monitor


Еще до появления технологии FastLocate точки доступа умели работать в режиме Monitor mode AP. Этот режим использовался для централизованной системы обнаружения вторжений. При переходе в этот режим оба радиомодуля перестают обслуживать клиентов и последовательно сканируют каналы с продолжительностью 1.2 секунды.

image
Данный алгоритм работы подтверждается выводом с точки доступа:

pod1-1140#debug dot11 do0 trace print channel 
*Oct  4 10:51:22.031: 1FB01CC6-0 Channel 12 (2467) promiscuous  20MHz
*Oct  4 10:51:23.246: 1FC2A970-0 Channel 13 (2472) promiscuous  20MHz
*Oct  4 10:51:24.458: 1FD5283F-0 Channel 14 (2484) promiscuous listen_only 20MHz
*Oct  4 10:51:25.670: 1FE7A716-0 Channel 1 (2412) promiscuous  20MHz


В случае Monitor mode AP алгоритм работы не менялся при включении/выключении FastLocate.

FastLocate работает только для подключенных клиентов


При использовании режима Monitor есть нюанс: FastLocate работает только для подключенных к инфраструктуре клиентов, а при переводе точки доступа в режим Monitor точка перестаёт обслуживать клиентов. То есть подразумевается, что в инфраструктуре будут другие точки доступа, обслуживающие клиентов.

Точки доступа в режиме Monitor предлагается размещать в пропорции 1:5 к обычным точкам доступа.

FastLocate с использованием дополнительного модуля WSM


Это основной режим работы FastLocate, который предусматривает установку в точки доступа модулей WSM в пропорции 2:5 (то есть как минимум 2:5 точек доступа должны быть модульные, то есть самые топовые).

WSM имеет свой собственный алгоритм работы. WSM модуль в отличии от радио в режиме мониторинга сканирует канал не по 1.2 секунды, а по 250 мс. Но он это делает не последовательно, а в соответствии с определенными правилами:

<L1, L1, L1, L1, L1, CA, L2>
It will scan 5 slots of L1(serving channel of the APs) followed by a cleanAir slot (if enabled), followed by one slot of L2 (channels in the country/DCA list). If there are less than 5 channels in the L1 list, the same channels will be scanned repeatedly till the 5 L1 slots are filled up.


Можно сказать, что большой приоритет отдаётся инфраструктурным каналам (на которых работают свои точки доступа), что и понятно, потому что FastLocation работает только для подключенных клиентов и сканирование смежных каналов не так важно.

Как этот алгоритм выглядит при выводе на точке доступа:

Sep 20 16:24:17.824: 2EC10B2D-2 Channel 1 (2412) promiscuous  20MHz
Sep 20 16:24:17.903: 2EC24019-2 Channel 48 (5240) promiscuous  20MHz
Sep 20 16:24:18.151: 2EC60A5D-2 Channel 6 (2437) promiscuous  20MHz
Sep 20 16:24:18.383: 2EC99BD3-2 Channel 11 (2462) promiscuous  20MHz
Sep 20 16:24:18.627: 2ECD54AC-2 Channel 1 (2412) promiscuous  20MHz
Sep 20 16:24:18.895: 2ED16A1E-2 Channel 161 (5805) promiscuous  20MHz
Sep 20 16:24:19.435: 2ED99B31-2 Channel 6 (2437) promiscuous  20MHz
Sep 20 16:24:19.555: 2EDB7010-2 Channel 60 (5300) promiscuous  20MHz
Sep 20 16:24:19.807: 2EDF53C5-2 Channel 48 (5240) promiscuous  20MHz
Sep 20 16:24:20.046: 2EE2EF52-2 Channel 6 (2437) promiscuous  20MHz
Sep 20 16:24:20.282: 2EE695CB-2 Channel 11 (2462) promiscuous  20MHz
Sep 20 16:24:20.514: 2EEA16E6-2 Channel 1 (2412) promiscuous  20MHz
Sep 20 16:24:21.010: 2EF1B48A-2 Channel 11 (2462) promiscuous  20MHz
Sep 20 16:24:21.166: 2EF40C9B-2 Channel 161 (5805) promiscuous  20MHz
Sep 20 16:24:21.454: 2EF86DA9-2 Channel 60 (5300) promiscuous  20MHz
Sep 20 16:24:21.710: 2EFC5A8F-2 Channel 48 (5240) promiscuous  20MHz
Sep 20 16:24:21.929: 2EFFBC42-2 Channel 6 (2437) promiscuous  20MHz
Sep 20 16:24:22.161: 2F033F09-2 Channel 11 (2462) promiscuous  20MHz
Sep 20 16:24:22.645: 2F0AA07D-2 Channel 36 (5180) promiscuous  20MHz
Sep 20 16:24:22.785: 2F0CCDC0-2 Channel 1 (2412) promiscuous  20MHz
Sep 20 16:24:23.061: 2F10F3CB-2 Channel 161 (5805) promiscuous  20MHz
Sep 20 16:24:23.337: 2F1539E8-2 Channel 60 (5300) promiscuous  20MHz
Sep 20 16:24:23.593: 2F192133-2 Channel 48 (5240) promiscuous  20MHz
Sep 20 16:24:23.813: 2F1C798A-2 Channel 6 (2437) promiscuous  20MHz
Sep 20 16:24:24.297: 2F23E056-2 Channel 48 (5240) promiscuous  20MHz
Sep 20 16:24:24.433: 2F25EE6C-2 Channel 11 (2462) promiscuous  20MHz
Sep 20 16:24:24.673: 2F299DFA-2 Channel 1 (2412) promiscuous  20MHz
Sep 20 16:24:24.937: 2F2D9ABB-2 Channel 161 (5805) promiscuous  20MHz
Sep 20 16:24:25.221: 2F31F49A-2 Channel 60 (5300) promiscuous  20MHz
Sep 20 16:24:25.473: 2F35CF9A-2 Channel 48 (5240) promiscuous  20MHz
Sep 20 16:24:25.977: 2F3D7AA1-2 Channel 40 (5200) promiscuous  20MHz
Sep 20 16:24:26.097: 2F3F532D-2 Channel 6 (2437) promiscuous  20MHz
Sep 20 16:24:26.329: 2F42D521-2 Channel 11 (2462) promiscuous  20MHz


Интервал сканирование не такой ровный, как в других режимах, и находится в пределах 50-250мс.

И действительно, не инфраструктурные каналы (в моём случае это каналы 36, 40) обходились достаточно редко, с периодичностью более 3 секунд, что так же можно увидеть в логах.

Оценка частоты замеров


При активации режима FastLocation частота замеров напрямую зависела от активности клиента. Если клиент (смартфон, телефон, ноутбук) находились в спящем режиме, то есть не использовался активно Wi-Fi адаптер, частота замеров была сравнима с методом Probe RSSI. Если же устройство использовало активно Wi-Fi адаптер, то частота замеров резко возрастала.

Я не стал тестировать все возможные схемы работы Cisco FastLocation, так как есть очень много факторов, влияющих на частоту замеров, как со стороны инфраструктуры, так и со стороны клиента, поэтому тесты проводились только в режиме WSM.

Использовалось три типа устройств: смартфон, планшет и ноутбук. Для всех тестируемых устройств интервал между замерами был соизмерим и составлял порядка 2-6 секунд при активном использовании Wi-Fi адаптера.

Общие выводы


1. FastLocate (Data RSSI) по сравнению с Probe RSSI в общем случае для персональных устройств позволяет значительно увеличить частоту замеров, особенно при использовании Wi-Fi модуля.

2. Но если клиентское устройство находится в спящем режиме и не использует Wi-Fi адаптер, частота замеров падает до стандартной при Probe RSSI.

3. Очень сложно говорить о каком-то конкретном значении частоты замеров в случае использования Wi-Fi позиционирования для персональных устройств. Есть очень много факторов, как со стороны инфраструктуры, так и со стороны клиента, влияющих на данную характеристику. Для получения конкретных значений, я полагаю, надо действовать по аналогии с радиообследованием, то есть проводить полевые испытания всей системы целиком и с требуемыми клиентскими устройствами.

СоздатьДля создания публикации, пожалуйста в систему