Los Lightweight Access Points (LAP) pueden detectar la dirección IP de administración del controlador a través de la técnica Over-the-Air Provisioning (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 conocimientos básicos de LWAPP/CAPWAP.
Este documento no tiene restricciones específicas en cuanto a versiones de software y de hardware.
Durante el proceso de arranque LAP, el LAP utiliza diferentes mecanismos para descubrir los controladores a los que puede unirse. El LAP guarda cada uno del controlador que las direcciones IP que aprendió a través de los diversos métodos en diversas listas para reflejar cómo el LAP aprendió sobre ellos. Por ejemplo, el LAP puede aprender direcciones IP de administración de múltiples controladores a través de la entrada DNS para CISCO-LWAPP-CONTROLLER.localdomain, opción DHCP 43, a través de difusiones 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 detección del WLC del LWAPP, elige un WLC de la lista del WLC candidato y envía ese WLC una solicitud de unión del LWAPP.
El registro del Lightweight AP (LAP) a un Wireless LAN Controller (WLC) discute los diversos métodos que el LAP utiliza para descubrir 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 el comando config 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 pone momentáneamente las interfaces de radio en funcionamiento antes de la fase de detección y explora los diferentes canales 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 la RF automática (cuantos más canales, menos probable es que el LAP reciba un paquete vecino RRM)
Cuánto tiempo el LAP explora los canales RF durante el proceso OTAP (los tiempos de escaneo típicos antes de que el AP se mueva en la fase de detección son de 18 a 35 segundos para todos los canales)
Cuando el LAP entra en la fase de detección, envía las solicitudes de detección a través de su interfaz primaria a cada uno de los controladores en las listas según cómo se enteró de ellos. Para los controladores que se aprenden a través de OTAP, el LAP envía al controlador un paquete de solicitud de detección con el bit OTAP configurado. 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 la opción 43 de DNS o DHCP, no se diferencian en el paquete de solicitud de detección porque se aprenden a través de conexiones cableadas.
Este controlador puede rechazar las solicitudes de detección por las siguientes razones:
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 IOS de Cisco LWAPP. La imagen de Cisco IOS de recuperación de LWAPP no admite OTAP. La imagen de recuperación de LWAPP se envía de fábrica y se carga mediante la herramienta de actualización. Las imágenes de recuperación (cXXXX-rcvk9w8-mx), incluidas con los nuevos LAP listos para usar, no contienen ningún firmware de radio y no activan ninguna interfaz de radio durante el proceso de arranque. Por lo tanto, OTAP no funciona con LAP 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 debe responder o no a las solicitudes de detección con el bit OTAP configurado. No evita que los LAPs ya unidos al controlador de la transmisión de la dirección IP de administración del controlador en los paquetes vecinos de RRM claros. Por lo tanto, si inhabilita OTAP en el controlador, esto no lo inhabilita en el punto de acceso. OTAP no se puede desactivar en el punto de acceso.
OTAP utiliza paquetes vecinos RRM. Esta sección proporciona un breve contexto sobre los paquetes vecinos RRM. Los LAPs ya unidos 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 vecino una vez cada 60 segundos en cada uno de los canales de RF automática configurados para 802.11b/g y 802.11a. Los paquetes vecinos RRM se transmiten sin ningún tipo de cifrado similar a otros paquetes de administración de RF, como solicitudes de sondeo y respuestas de sondeo. Los paquetes de vecino RRM contienen mensajes de control de vecino. Vea la sección Paquete 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 gestió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 vecino RRM que reciban. Esto permite que el controlador forme grupos de RF para el ajuste de la potencia y los canales entre los LAP que pueden verse entre sí. Los LAPs que se están iniciando pueden utilizar estos paquetes vecinos RRM para descubrir el controlador al cual los LAPs vecinos ya están unidos.
Aquí hay un paquete vecino RRM de ejemplo 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.
Revisión | Fecha de publicación | Comentarios |
---|---|---|
1.0 |
14-Jan-2008 |
Versión inicial |