Los Lightweight Access Points (LAP) pueden detectar la dirección IP de gestión del controlador mediante la técnica de aprovisionamiento aéreo (OTAP). Esta función es compatible con los controladores de las series 5500 y 4400 de Cisco. Este documento explica algunos de los detalles de este proceso.
Cisco recomienda que tenga conocimiento básico del LWAPP/CAPWAP.
Este documento no tiene restricciones específicas en cuanto a versiones de software y de hardware.
Durante el proceso de inicio del LAP, el LAP utiliza diferentes mecanismos para detectar los controladores a los que puede unirse. El LAP mantiene cada uno de los controladores que las direcciones IP aprendieron a través de los diferentes métodos en diferentes listas para reflejar cómo el LAP aprendió acerca de ellos. Por ejemplo, el LAP puede aprender las direcciones IP de administración de varios controladores a través de la entrada DNS para CISCO-LWAPP-CONTROLLER.localdomain, opción DHCP 43, a través de broadcasts en la subred local, detección de direcciones IP del controlador almacenado localmente y a través de OTAP. Una vez que el punto de acceso ha completado los pasos de la Detección del WLC del LWAPP, elige un WLC de la lista del WLC candidato y envía ese WLC y el LWAPP Join Request.
El registro de Lightweight AP (LAP) en un controlador de LAN inalámbrica (WLC) trata los diferentes métodos que el LAP utiliza para detectar los controladores.
Este documento proporciona información sobre el proceso OTAP.
La función OTAP se habilita en la GUI del controlador desde la página General del controlador o a través de la CLI con la configuración network otap-mode {enable | disable}.
Nota: Esta función está desactivada de forma predeterminada y debe permanecer desactivada cuando se instalan todos los puntos de acceso.
El proceso OTAP comienza cuando el LAP activa momentáneamente las interfaces de radio antes de la fase Discovery y escanea los diferentes canales de RF que escuchan los paquetes vecinos RRM. Es posible que el LAP reciba o no reciba un paquete vecino RRM en el primer arranque. Esto depende de:
Cuántos LAP hay en el área (cuanto mayor sea el número de LAP en el área, mayor será la probabilidad de que el LAP reciba un paquete vecino RRM)
Cuántos canales está utilizando Auto-RF (cuantos más canales, menos probabilidades hay de que el LAP reciba un paquete vecino RRM)
Cuánto tiempo el LAP escanea los canales de RF durante el proceso OTAP (los tiempos de escaneo típicos antes de que el AP pase a la fase de detección son de 18 a 35 segundos para todos los canales)
Cuando el LAP se traslada a la fase de detección, envía solicitudes de detección a través de su interfaz principal a cada uno de los controladores de las listas basándose en cómo se enteró de ellos. Para los controladores aprendidos a través de OTAP, el LAP envía al controlador un paquete de Solicitud de detección con el conjunto de bits OTAP. Esto indica al controlador que el AP aprendió su dirección IP de administración a través de OTAP. Otros métodos de detección, como DNS o la opción DHCP 43, no se diferencian en el paquete de solicitud de detección porque se aprenden a través de conexiones por cable.
Este controlador puede rechazar las solicitudes de detección por estos motivos:
El bit OTAP se configura en el paquete de Solicitud de detección y OTAP se inhabilita en el controlador.
El paquete de Solicitud de detección es demasiado grande.
El paquete de Solicitud de detección no se recibe en la interfaz de administración.
Los LAP soportan OTAP solamente cuando tienen una imagen completa del LWAPP Cisco IOS. La imagen del IOS de Cisco de recuperación de LWAPP no soporta OTAP. La imagen de recuperación del LWAPP se envía desde la fábrica y se carga mediante la herramienta de actualización. Las imágenes de recuperación (cXXXX-rcvk9w8-mx), enviadas con los LAPs nuevos y listos para usar, no contienen firmware de radio y no muestran interfaces de radio durante el proceso de inicio. Por lo tanto, OTAP no funciona con LAPs listos para usar. Las excepciones son los AP 1510 y 1520 listos para usar, que tienen una imagen completa instalada en la memoria flash.
Nota: OTAP habilitado en el controlador indica al controlador si responder o no a las solicitudes de detección con el bit OTAP configurado. No evita que los LAPs que ya se han unido al controlador transmitan la dirección IP de administración del controlador en el claro en los paquetes vecinos RRM. Por lo tanto, si inhabilita OTAP en el controlador, esto no lo inhabilita en el punto de acceso. OTAP no se puede inhabilitar en el punto de acceso.
OTAP utiliza paquetes de vecinos RRM. Esta sección proporciona un breve fondo sobre los paquetes vecinos RRM. Los LAPs ya se unieron a un controlador transmiten los paquetes vecinos RRM a la dirección multicast RRM 01:0b:85:00:00:00. Cada LAP debe transmitir un paquete de Detección de Vecinos una vez cada 60 segundos en cada uno de los canales de RF Automático configurados para 802.11b/g y 802.11a. Los paquetes vecinos RRM se transmiten sin ningún cifrado similar a otros paquetes de administración de RF, como solicitudes de sonda y respuestas de sonda. Los paquetes vecinos RRM contienen mensajes de control de vecino. Consulte la sección Paquete de vecino RRM para 802.11a para obtener más información. Cada mensaje de control de vecino consta de:
ID de radio
ID de grupo
Dirección IP de administración (del controlador)
Recuento de canales
Patrón de antena (Omni, Izquierda, Diversidad, Derecha)
Intervalo de medición
Clave
Canales
Energía
Los LAP encapsulan y reenvían al controlador cualquier paquete RRM vecino que reciban. Esto permite que el controlador forme grupos de RF para el ajuste de la potencia y los canales entre los LAPs que pueden verse entre sí. Los LAP que se inician pueden utilizar estos paquetes vecinos RRM para detectar el controlador al que los LAP vecinos ya están unidos.
Este es un ejemplo de paquete vecino 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.....
Se resaltan la dirección multicast del vecino RRM y la dirección IP de administración del controlador.