Processo de Associação dos AP em Unified Wireless

Quando um AP é energizado pela primeira vez, ele tenta descobrir seu Controller seguinto o processo de Discovery da seguinte forma:

Discovery L2: Emite mensagens LWAPP L2 em broadcast. Neste modo o LWAPP é encapsulado diretamente em Ethernet.

Discovery L3: Em caso de falha na descoberta de Controller trabalhando em L2, ele então altera seu modo de trabalho para L3. Neste modo, o LWAPP ou CAPWAP é encapsulado em UDP. O AP segue os passos abaixo, na seguinte ordem:

1) Configuração Estática: Caso o administrador tenha cadastrado manualmente o IP do controller, ele então levará em conta no próximo passo.

2) Broadcast L3: Emite mensagens CAPWAP/LWAPP em broadcast, para descobrir controller dentro do mesmo domínio de Broadcast. Este passo pode ser extendido utilizando a feature IP Helper-Address.

3) OTAP: Neste passo, o AP ativa a interface Wireless por alguns segundos e ouve mensagens RRM. Estas mensagens são emitidas por todos os APs associados a um controller. Caso o controller tenha a Feature OTAP ativada, nas mensagens RRM incluirá o IP do Controller atual. Este novo AP poderá ler este campo e adquirir o IP do controller.

4) AP Priming: O AP, armazena na NVRAM o IP do último controller associado. Desta forma, ele terá o IP do mesmo.

5) Opção 43 do DHCP: Está opção emite para o AP o IP do controller. Se configurado no IOS, deverá ser inserido o seguinte comando dentro do escopo DHCP: "option 43 hex 0xf1xx.aaaa.aaaa.bbbb.bbbb.cccc.cccc

Onde: XX: Quantos controllers serão fornecidos ao AP. 1=04, 2=08, 3=12(Max)
aaaa.aaaa: IP do controller Primário, convertido para hexadecimal (Exemplo: 10.10.10.10 = 0a0a.0a0a, 1.1.1.1 = 0101.0101)
bbbb.bbbb: IP do controller Secundário, convertido para hexadecimal
cccc.cccc: IP do controller Terciário, convertido para hexadecimal

6) DNS: Quando enviado para o AP o Domain-name e o DNS-SERVER, ele realizará Query para o DNS do seguinte nome: CISCO-LWAAP-CONTROLLER ou CISCO-CAPWAP-CONTROLER

OBS: Esta ordem não tem importância para o processo de JOIN a seguir.

Depois do processo de DISCOVERY, o AP levantará todos os IP descobertos e iniciará o processo de JOIN, que consiste na troca de certificados digitais para criptografar o túnel LWAPP/CAPWAP e realizar teste de MTU da rede.

Quando um AP entra no estado operacional pela primeira vez, ele armazena na NVRAM, além do IP do último controller, o Mobility Domain List. Nesta lista, existe todos os controller que estavam dentro do seu antigo mobility Domain.

Logo, O AP enviará mensagens de JOIN REQUEST para todos AP dentro de sua Mobility Domain List e caso não possúa uma Mobility Domain List tentará os outros APs.

Para ambos, ele segue o seguinte critério:

1) AP Primário, Secundário e Terciario.
2) Controller com o bit "MASTER CONTROLLER" setado.
3) Controller menos congestionado.

Vamos exemplificar que um AP esteve operacional anteriormente, e que na sua Mobility Domain antiga estava a Opção 1 e 2.

No processo de Discovery do AP 1, ele levantou os seguintes controller:
1) C1, 10.10.10.10, Domain WIRELESS, 4402-25, 20 APs
2) C2, 10.10.10.11, Domain UNIFIED, 2106, 5 APs
3) C3, 10.10.10.12, Domain CISCO, WISM, 0 APs

O AP realizará Join para a Opção 1, pois o total disponível é de 5, e está na sua Mobility Domain List

Caso eu deseje que o C3 participe da eleição para JOIN, ele deverá ser incluso na Mobility Domain List.

Grupos no mundo Unified Wireless

No mundo Unified Wireless da Cisco, existem 4 grupos importantes que devemos estudar:

1) MOBILITY GROUP: Um grupo de Controllers trabalhando como um cluster. Por padrão é possível um grupo de até 24 controllers. Para o funcionamento correto é necessário configurar um túnel Ethernet-Over-IP entre os Controllers, onde precisamos inserir os seguintes dados:

IP do Controller Destino
MAC do Controller Destino
Mobility Domain do Controller Vizinho.

Se o Mobility Domain local for idêntico (Case Sensitive) ao Mobility Domain do controller cadastrado, então existe a possíbilidade de ocorrer Roaming de usuários entre os Controllers.

Quando eu digo "existe a possíbilidade", é porque existem outros critérios que deverão ser cumpridos antes do roaming de clientes.

Os critérios são os seguintes:

- Virtual IP idêntico
- SSID deverá ter todos os parâmetros identicos, com excessão da INTERFACE.

2) RF GROUP: Um grupo de cooperação mutua para escolher os melhores parametros (Canal e Potência) de RF para o AP.
Em cada RF Group é eleito um Controller Leader, que realizará os calculos de RF e determinará os parametros corretos para cada AP.

Os AP emitem periodiamente mensagens RRM na maior potência possível e em todos os canais possíveis. Dentro destas mensagens existe em hash o nome do RF Group. Os APs que possúem Hash identicos trabalham em grupo. Quando são identificados APs sem este Hash, os mesmos são considerados Rogue AP.


3)AP GROUP: Para evitar que exista um grupo muito grande de clientes dentro da mesma subrede, e respeitar o limite de 200 clientes dentro do mesmo domínio de colisão, é possível que determinados APs, ao receberem o tráfego de dado SSID, enviem este dado para uma interface diferente. Esta customização é feita por AP GROUP.

4) H-REAP Group: Este é um caso especial, para AP no modo H-REAP. Este grupo permite que os H-REAP, em caso de modo Standalone, continuem authenticando os clientes em uma base de usuários Radius local no site. É permitido inserir até 2 servidores Radius, onde estes serão sobrepostos na configuração global. O Ideal é que seja o primeiro o Radius Central e o segundo o Radius Local do site.