I Lightweight Access Point (LAP) possono rilevare l'indirizzo IP di gestione del controller tramite la tecnica di over-the-Air Provisioning (OTAP). Questa funzione è supportata dai controller Cisco serie 5500 e 4400. Questo documento spiega alcuni dettagli di questo processo.
Cisco raccomanda la conoscenza base di LWAPP/CAPWAP.
Il documento può essere consultato per tutte le versioni software o hardware.
Per ulteriori informazioni sulle convenzioni usate, consultare il documento Cisco sulle convenzioni nei suggerimenti tecnici.
Durante il processo di avvio, il LAP usa meccanismi diversi per rilevare i controller a cui può unirsi. Il LAP conserva ciascuno dei controller con indirizzo IP appreso attraverso i diversi metodi in diversi elenchi, in modo da riflettere come il LAP ne sia venuto a conoscenza. Ad esempio, il LAP può conoscere gli indirizzi IP di gestione di più controller tramite la voce DNS per CISCO-LWAPP-CONTROLLER.localdomain, l'opzione DHCP 43, le trasmissioni nella subnet locale, il rilevamento degli indirizzi IP dei controller archiviati localmente e l'OTAP. Una volta completati i passaggi di rilevamento del WLC di LWAPP, il punto di accesso sceglie un WLC dall'elenco dei WLC candidati e invia a tale WLC una richiesta di accesso LWAPP.
Registrazione di un Lightweight AP (LAP) su un Wireless LAN Controller (WLC) vengono illustrati i diversi metodi utilizzati dai LAP per rilevare i controller.
In questo documento vengono fornite informazioni sul processo OTAP.
La funzionalità OTAP è abilitata nell'interfaccia utente del controller dalla pagina Generale del controller o tramite la CLI con la modalità di accesso rapido configurazione di rete {enable | disable}.
Nota: questa funzione è disabilitata per impostazione predefinita e deve rimanere disabilitata quando tutti i punti di accesso sono installati.
Il processo OTAP ha inizio quando il LAP sposta momentaneamente le interfacce radio prima della fase di rilevamento ed esegue la scansione dei diversi canali RF in ascolto dei pacchetti RRM adiacenti. È possibile che il LAP riceva o non riceva un pacchetto RRM adiacente al primo avvio. Dipende da:
Quanti LAP ci sono nell'area (maggiore è il numero di LAP nell'area, maggiori sono le probabilità che il LAP riceva un pacchetto RRM adiacente)
Quanti canali vengono utilizzati dalla funzione Auto-RF (maggiore è il numero dei canali, minore è la probabilità che il LAP riceva un pacchetto RRM adiacente)
Durata della scansione dei canali RF da parte del LAP durante il processo OTAP (i tempi di scansione tipici prima che l'access point passi alla fase di rilevamento sono compresi tra 18 e 35 secondi per tutti i canali)
Quando il LAP entra nella fase di rilevamento, invia le richieste di rilevamento attraverso l'interfaccia principale a ciascuno dei controller presenti negli elenchi in base a quanto appreso. Per i controller appresi tramite OTAP, il LAP invia al controller un pacchetto di richiesta di individuazione con il bit OTAP impostato. Ciò indica al controller che l'access point ha imparato il proprio indirizzo IP di gestione tramite OTAP. Altri metodi di rilevamento, ad esempio DNS o l'opzione DHCP 43, non vengono differenziati nel pacchetto della richiesta di rilevamento in quanto vengono appresi tramite connessioni cablate.
Questo controller può rifiutare le richieste di individuazione per i motivi seguenti:
Il bit OTAP viene impostato nel pacchetto Discovery Request e OTAP viene disabilitato sul controller.
Il pacchetto della richiesta di individuazione è troppo grande.
Il pacchetto di richiesta di individuazione non viene ricevuto sull'interfaccia di gestione.
I LAP supportano l'OTAP solo quando hanno un'immagine LWAPP Cisco IOS completa. OTAP non è supportato dall'immagine Cisco IOS di ripristino LWAPP. L'immagine di ripristino LWAPP viene spedita dalla fabbrica e caricata dallo strumento di aggiornamento. Le immagini di ripristino (cXXXX-rcvk9w8-mx), fornite con i nuovi LAP preconfigurati, non contengono firmware radio e non attivano interfacce radio durante il processo di avvio. Pertanto, OTAP non funziona con i LAP preconfigurati. Fanno eccezione i punti di accesso predefiniti 1510 e 1520, che dispongono di un'immagine completa installata nella memoria flash.
Nota: OTAP abilitato sul controller indica al controller se rispondere o meno alle richieste di individuazione con il bit OTAP impostato. Ciò non impedisce ai LAP già collegati al controller di trasmettere l'indirizzo IP di gestione del controller in chiaro nei pacchetti adiacenti RRM. Pertanto, se si disabilita OTAP sul controller, non lo disabilita sul punto di accesso. Impossibile disabilitare OTAP sul punto di accesso.
OTAP utilizza pacchetti RRM adiacenti. In questa sezione viene fornito un breve sfondo sui pacchetti RRM adiacenti. I LAP già aggiunti a un controller trasmettono i pacchetti adiacenti RRM all'indirizzo multicast RRM 01:0b:85:00:00:00. Ogni LAP deve trasmettere un pacchetto Neighbor Discovery ogni 60 secondi su ciascuno dei canali Auto-RF configurati per 802.11b/g e 802.11a. I pacchetti dei router adiacenti RRM vengono trasmessi senza crittografia simile ad altri pacchetti di gestione RF, quali richieste di probe e risposte di probe. I pacchetti RRM adiacenti contengono messaggi di controllo adiacenti. Per ulteriori informazioni, vedere la sezione RRM Neighbor Packet for 802.11a. Ogni messaggio di controllo relativo ai nodi adiacenti è costituito da:
ID radio
ID gruppo
Indirizzo IP di gestione (del controller)
Conteggio canali
Motivo Antenna (Omni, Sinistra, Diversità, Destra)
Intervallo di misurazione
Chiave
Canali
Alimentazione
I LAP incapsulano e inoltrano al controller tutti i pacchetti RRM adiacenti che ricevono. Ciò consente al controller di formare gruppi RF per la regolazione dell'alimentazione e dei canali tra i LAP che possono vedersi. I LAP in fase di avvio possono utilizzare questi pacchetti RRM adiacenti per individuare il controller a cui sono già stati aggiunti i LAP adiacenti.
Di seguito è riportato un esempio di pacchetto RRM per router adiacenti per 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.....
Vengono evidenziati l'indirizzo multicast del router adiacente RRM e l'indirizzo IP di gestione del controller.
Revisione | Data di pubblicazione | Commenti |
---|---|---|
1.0 |
14-Jan-2008 |
Versione iniziale |