Os Pontos de Acesso Lightweight (LAPs) podem descobrir o endereço IP de gerenciamento do controlador através da técnica de Provisionamento Over-the-Air (OTAP). Esse recurso é suportado pelos Cisco 5500 e 4400 Series Controllers. Este documento explica alguns dos detalhes desse processo.
A Cisco recomenda que você tenha conhecimento básico de LWAPP/CAPWAP.
Este documento não se restringe a versões de software e hardware específicas.
Consulte as Convenções de Dicas Técnicas da Cisco para obter mais informações sobre convenções de documentos.
Durante o processo de inicialização do LAP, o LAP usa mecanismos diferentes para descobrir controladores aos quais pode se unir. O LAP mantém cada controlador com os endereços IP que aprendeu através dos diferentes métodos em listas diferentes para refletir como o LAP aprendeu sobre eles. Por exemplo, o LAP pode aprender os endereços IP de gerenciamento de vários controladores através da entrada DNS para CISCO-LWAPP-CONTROLLER.localdomain, opção de DHCP 43, através de broadcasts na sub-rede local, descoberta de endereço IP do controlador armazenado localmente e através do OTAP. Depois que o access point concluir as etapas de descoberta de WLC LWAPP, ele escolhe uma WLC na lista de WLCs candidatas e envia a essa WLC uma solicitação de união LWAPP.
O registro de AP leve (LAP) para uma controladora Wireless LAN (WLC) discute os diferentes métodos que o LAP usa para descobrir controladoras.
Este documento fornece informações sobre o processo OTAP.
O recurso OTAP é habilitado na GUI do controlador na página General do controlador ou através da CLI com o comando config network otap-mode {enable | disable}.
Observação: esse recurso é desabilitado por padrão e deve permanecer desabilitado quando todos os access points estiverem instalados.
O processo OTAP começa quando o LAP momentaneamente ativa as interfaces de rádio antes da fase de Descoberta e examina os diferentes canais de RF que escutam os pacotes vizinhos de RRM. É possível que o LAP receba ou não receba um pacote de vizinho RRM na primeira inicialização. Isso depende de:
Quantos LAPs estão na área (quanto maior o número de LAPs na área, maior a chance de o LAP receber um pacote de vizinhos RRM)
Quantos canais estão sendo usados pelo AutoRF (quanto mais canais, menor a probabilidade de o LAP receber um pacote vizinho de RRM)
Quanto tempo o LAP verifica os canais de RF durante o processo OTAP (os tempos de verificação típicos antes de o AP se mover para a fase de descoberta são de 18 a 35 segundos para todos os canais)
Quando o LAP entra na fase de Descoberta, ele envia solicitações de descoberta por meio de sua interface primária para cada um dos controladores nas listas com base em como aprendeu sobre eles. Para os controladores aprendidos através do OTAP, o LAP envia ao controlador um pacote de solicitação de descoberta com o conjunto de bits OTAP. Isso indica para a controladora que o AP aprendeu seu endereço IP de gerenciamento através do OTAP. Outros métodos de descoberta, como DNS ou DHCP opção 43, não são diferenciados no pacote de solicitação de descoberta porque são aprendidos através de conexões com fio.
Esse controlador pode rejeitar solicitações de descoberta pelos seguintes motivos:
O bit OTAP é definido no pacote Discovery Request e o OTAP é desativado no controlador.
O pacote de Solicitação de Descoberta é muito grande.
O pacote de Solicitação de Descoberta não foi recebido na interface de gerenciamento.
Os LAPs suportam o OTAP somente quando têm uma imagem completa do Cisco IOS com LWAPP. O OTAP não é suportado pela imagem do Cisco IOS de recuperação do LWAPP. A imagem de recuperação do LWAPP é enviada da fábrica e carregada pela ferramenta de atualização. As imagens de recuperação (cXXXX-rcvk9w8-mx), fornecidas com novos LAPs prontos para uso, não contêm nenhum firmware de rádio e não ativam nenhuma interface de rádio durante o processo de inicialização. Portanto, o OTAP não funciona com LAPs prontos para uso. As exceções são APs 1510s e 1520 prontos para uso, que têm uma imagem completa instalada na memória flash.
Observação: o OTAP ativado no controlador indica ao controlador se ele deve ou não responder às solicitações de descoberta com o conjunto de bits OTAP. Isso não impede que os LAPs já unidos à controladora transmitam o endereço IP de gerenciamento da controladora na limpeza nos pacotes vizinhos RRM. Assim, se você desabilitar o OTAP no controlador, isso não o desabilitará no ponto de acesso. Não é possível desabilitar o OTAP no ponto de acesso.
O OTAP utiliza pacotes de vizinhos RRM. Esta seção fornece um breve histórico dos pacotes vizinhos de RRM. Os LAPs já unidos a uma controladora transmitem pacotes vizinhos de RRM para o endereço multicast de RRM 01:0b:85:00:00:00. Cada LAP deve transmitir um pacote Neighbor Discovery uma vez a cada 60 segundos em cada um dos canais AutoRF configurados para 802.11b/g e 802.11a. Os pacotes vizinhos de RRM são transmitidos sem qualquer criptografia semelhante a outros pacotes de gerenciamento de RF, como solicitações de sonda e respostas de sonda. Os pacotes vizinhos do RRM contêm mensagens de controle de vizinhos. Consulte a seção Pacote de Vizinhos RRM para 802.11a para obter mais informações. Cada mensagem de controle de vizinho consiste em:
ID do rádio
ID do grupo
Endereço IP de gerenciamento (da controladora)
Contagem de canais
Padrão de antena (omni, esquerda, diversidade, direita)
Intervalo de medição
Chave
Canais
Alimentação
Os LAPs encapsulam e encaminham para a controladora todos os pacotes vizinhos de RRM que recebem. Isso permite que o controlador forme grupos de RF para o ajuste da potência e dos canais entre LAPs que podem ver um ao outro. Os LAPs que estão sendo inicializados podem usar esses pacotes vizinhos de RRM para descobrir o controlador ao qual os LAPs vizinhos já estão unidos.
Aqui está um exemplo de pacote de vizinho RRM para 802.11a:
No. Time Source Destination 8313 23:39:20.169855117 00:14:1b:5a:40:10 01:0b:85:00:00:00 Protocol Info LLC U, func=UI; SNAP, OUI 0x000B85 (Unknown), PID 0xCCCD Frame 8313 (80 bytes on wire, 80 bytes captured) [Protocols in frame: wlan:llc:data] IEEE 802.11 Data Rate: 6.0 Mb/s Channel: 60 Signal Strength: 0% Type/Subtype: Data (32) Frame Control: 0x0308 (Normal) Version: 0 Type: Data frame (2) Subtype: 0 Flags: 0x3 DS status: Frame part of WDS from one AP to another AP (To DS: 1 From DS: 1) (0x03) .... .0.. = More Fragments: This is the last fragment .... 0... = Retry: Frame is not being retransmitted ...0 .... = PWR MGT: STA will stay up ..0. .... = More Data: No data buffered .0.. .... = Protected flag: Data is not protected 0... .... = Order flag: Not strictly ordered Duration: 0 Receiver address: 01:0b:85:00:00:00 (01:0b:85:00:00:00) Transmitter address: 00:14:1b:5a:40:1f (00:14:1b:5a:40:1f) Destination address: 01:0b:85:00:00:00 (01:0b:85:00:00:00) Fragment number: 0 Sequence number: 487 Source address: 00:14:1b:5a:40:10 (00:14:1b:5a:40:10) Frame check sequence: 0x84bab9b3 [correct] Logical-Link Control DSAP: SNAP (0xaa) SSAP: SNAP (0xaa) Control field: U, func=UI (0x03) 000. 00.. = Command: Unnumbered Information (0x00) .... ..11 = Frame type: Unnumbered frame (0x03) Organization Code: Airespace (0x000b85) Protocol ID: 0xcccd Data (38 bytes) 0000 08 03 00 00 01 0b 85 00 00 00 00 14 1b 5a 40 1f .............Z@. 0010 01 0b 85 00 00 00 70 1e 00 14 1b 5a 40 10 aa aa ......p....Z@... 0020 03 00 0b 85 cc cd 01 1b 00 1a 6c 91 80 80 00 04 ..........l..... 0030 0a 01 00 0f 3c 01 01 3c 04 ff ff 00 4e 40 fd ec ....<..<....N@.. 0040 a7 4a f4 c4 d3 7b 19 be 10 92 50 91 84 ba b9 b3 .J...{....P.....
O endereço multicast do vizinho RRM e o endereço IP de gerenciamento do controlador são destacados.
Revisão | Data de publicação | Comentários |
---|---|---|
1.0 |
14-Jan-2008 |
Versão inicial |