La documentazione per questo prodotto è stata redatta cercando di utilizzare un linguaggio senza pregiudizi. Ai fini di questa documentazione, per linguaggio senza di pregiudizi si intende un linguaggio che non implica discriminazioni basate su età, disabilità, genere, identità razziale, identità etnica, orientamento sessuale, status socioeconomico e intersezionalità. Le eventuali eccezioni possono dipendere dal linguaggio codificato nelle interfacce utente del software del prodotto, dal linguaggio utilizzato nella documentazione RFP o dal linguaggio utilizzato in prodotti di terze parti a cui si fa riferimento. Scopri di più sul modo in cui Cisco utilizza il linguaggio inclusivo.
Cisco ha tradotto questo documento utilizzando una combinazione di tecnologie automatiche e umane per offrire ai nostri utenti in tutto il mondo contenuti di supporto nella propria lingua. Si noti che anche la migliore traduzione automatica non sarà mai accurata come quella fornita da un traduttore professionista. Cisco Systems, Inc. non si assume alcuna responsabilità per l’accuratezza di queste traduzioni e consiglia di consultare sempre il documento originale in inglese (disponibile al link fornito).
In questo documento viene descritto il processo di rilevamento e unione di AireOS Wireless LAN Controller (WLC).
Cisco raccomanda la conoscenza dei seguenti argomenti:
Conoscenze base della configurazione dei Lightweight Access Point (LAP) e dei Cisco AireOS WLC
Nozioni base sul protocollo Lightweight Access Point Protocol (CAPWAP)
Questo documento è incentrato sui WLC di AireOS e non copre Catalyst 9800, anche se il processo di join è per lo più simile.
Le informazioni discusse in questo documento fanno riferimento a dispositivi usati in uno specifico ambiente di emulazione. Su tutti i dispositivi menzionati nel documento la configurazione è stata ripristinata ai valori predefiniti. Se la rete è operativa, valutare attentamente eventuali conseguenze derivanti dall'uso dei comandi.
Per ulteriori informazioni sulle convenzioni usate, consultare il documento Cisco sulle convenzioni nei suggerimenti tecnici.
In una Cisco Unified Wireless Network, i LAP devono individuare e collegarsi a un WLC prima di poter servire i client wireless.
Tuttavia, la domanda è: come hanno fatto i LAP a trovare l'indirizzo IP di gestione del controller quando si trova su una subnet diversa?
Se non si indica al LAP dove si trova il controller con l'opzione DHCP 43, la risoluzione DNS (Domain Name System) di
o la configurazione statica, il LAP non sa dove trovare l'interfaccia di gestione del controller nella rete.Cisco-capwap-controller.local_domain
Oltre a questi metodi, il LAP cerca automaticamente i controller con indirizzo di broadcast locale 255.255.255.255 nella subnet locale. Inoltre, il LAP memorizza l'indirizzo IP di gestione di tutti i controller a cui si collega durante i riavvii. Pertanto, se si posiziona il LAP per primo sulla subnet locale dell'interfaccia di gestione, questo trova l'interfaccia di gestione del controller e ricorda l'indirizzo. Questa operazione è chiamata priming. Tuttavia, se il LAP viene in seguito sostituito, ciò non sarà sufficiente a trovare il controller. Cisco consiglia pertanto di utilizzare l'opzione DHCP 43 o i metodi DNS.
I LAP si connettono sempre all'indirizzo dell'interfaccia di gestione del controller con una richiesta di rilevamento. Il controller quindi comunica al LAP l'indirizzo IP dell'interfaccia AP-manager di layer 3 (che può coincidere con l'interfaccia di gestione predefinita) in modo che il LAP possa inviare una richiesta di collegamento all'interfaccia AP-manager in un secondo momento.
L'access point esegue questo processo all'avvio:
cisco-capwap-controller
(utile per le aziende locali - può essere utilizzata anche per trovare dove si uniscono i nuovi access point) Se si utilizza CAPWAP, assicurarsi che esista una voce DNS per cisco-capwap-controller
.Tra i metodi elencati, il più semplice da adottare per l'implementazione è avere i LAP sulla stessa subnet dell'interfaccia di gestione del controller in modo che i LAP possano trovare il controller usando l'indirizzo di broadcast di layer 3. Questo metodo deve essere utilizzato per le società che dispongono di una rete di piccole dimensioni e non dispongono di un server DNS locale.
Il secondo metodo di implementazione consigliato consiste nell'utilizzare una voce DNS con DHCP. È possibile avere più voci con lo stesso nome DNS. Ciò consente al LAP di rilevare più controller. Questo metodo deve essere utilizzato dalle società che dispongono di tutti i controller in un'unica posizione e sono proprietarie di un server DNS locale. Oppure, da aziende con più suffissi DNS e controller separati dal suffisso.
L'opzione DHCP 43 viene utilizzata dalle aziende di grandi dimensioni per localizzare le informazioni tramite DHCP. Questo metodo viene utilizzato dalle grandi aziende che hanno un solo suffisso DNS. Ad esempio, Cisco ha sedi in Europa, Australia e Stati Uniti. Per garantire che i LAP si colleghino solo ai controller locali, Cisco non può utilizzare una voce DNS e deve usare le informazioni dell'opzione DHCP 43 per comunicare ai LAP qual è l'indirizzo IP di gestione del controller locale.
Infine, la configurazione statica viene utilizzata per una rete senza server DHCP. È possibile configurare in modo statico le informazioni necessarie per collegarsi a un controller tramite la porta della console e la CLI degli access point. Per informazioni su come configurare in modo statico le informazioni sui controller tramite la CLI dell'access point, utilizzare questo comando:
AP#capwap ap primary-base <WLCName> <WLCIP>Per informazioni su come configurare l'opzione DHCP 43 su un server DHCP, consultare l'esempio di configurazione dell'opzione DHCP 43
Se due controller hanno la stessa capacità in eccesso, inviare la richiesta di collegamento al primo controller che ha risposto alla richiesta di rilevamento. Se un singolo controller ha più AP-manager su più interfacce, scegliere l'interfaccia AP-manager con il minor numero di access point.
Il controller risponde a tutte le richieste di individuazione senza un controllo certificato o credenziali AP. Le richieste di join devono tuttavia disporre di un certificato valido per ottenere una risposta di join dal controller. Se il LAP non riceve una risposta di join a sua scelta, prova a usare il controller successivo nell'elenco, a meno che il controller non sia configurato (Primario/Secondario/Terziario).
Dopo aver scaricato la configurazione, l'access point può ricaricarsi di nuovo per applicare la nuova configurazione. Pertanto, può verificarsi un ulteriore caricamento, ma è un comportamento normale.
Sul controller sono disponibili alcuni debug
comandi per visualizzare l'intero processo sulla CLI:
debug capwap events enable
:mostra i pacchetti di rilevamento e i pacchetti di collegamento.
debug capwap packet enable
:mostra le informazioni sul livello dei pacchetti di rilevamento e collegamento.
debug pm pki enable
:mostra il processo di convalida del certificato.
debug disable-all
:disattiva il debug.
Da un'applicazione terminale in grado di acquisire l'output in un file di log, accedere alla console o alla Secure Shell (SSH) / Telnet del controller e immettere i seguenti comandi:
config session timeout 120 config serial timeout 120 show run-config (and spacebar thru to collect all) debug mac addr(in xx:xx:xx:xx:xx format) debug client debug capwap events enable debug capwap errors enable debug pm pki enable
Dopo aver acquisito i debug, usare il comandodebug disable-all
per disabilitare tutti i debug.
Le sezioni seguenti mostrano l'output di questi debug
comandi quando il LAP si registra con il controller.
Questo comando fornisce informazioni sugli eventi e sugli errori CAPWAP che si verificano durante il processo di individuazione e unione di CAPWAP.
Questo è l'output del debug capwap events enable
comando per un LAP con la stessa immagine del WLC:
Nota: alcune righe dell'output sono state spostate nella seconda riga a causa di vincoli di spazio.
debug capwap events enable *spamApTask7: Jun 16 12:37:36.038: 00:62:ec:60:ea:20 Discovery Request from 172.16.17.99:46317 !--- CAPWAP discovery request sent to the WLC by the LAP. *spamApTask7: Jun 16 12:37:36.039: 00:62:ec:60:ea:20 Discovery Response sent to 172.16.17.99 port 46317 !--- WLC responds to the discovery request from the LAP. *spamApTask7: Jun 16 12:38:43.469: 00:62:ec:60:ea:20 Join Request from 172.16.17.99:46317
!--- LAP sends a join request to the WLC.
*spamApTask7: Jun 16 12:38:33.039: 00:62:ec:60:ea:20 Join Priority Processing status = 0, Incoming Ap's Priority 1, MaxLrads = 75, joined Aps =0
*spamApTask7: Jun 16 12:38:43.469: 00:62:ec:60:ea:20 Join Request from 172.16.17.99:46317
*spamApTask7: Jun 16 12:38:43.472: 00:62:ec:60:ea:20 Join Version: = 134256640
*spamApTask7: Jun 16 12:38:43.473: 00:62:ec:60:ea:20 apType = 46 apModel: AIR-CAP2702I-E-K9
*spamApTask7: Jun 16 12:38:43.473: 00:62:ec:60:ea:20 Join resp: CAPWAP Maximum Msg element len = 90
*spamApTask7: Jun 16 12:38:43.473: 00:62:ec:60:ea:20 Join Response sent to 172.16.17.99:46317
*spamApTask7: Jun 16 12:38:43.473: 00:62:ec:60:ea:20 CAPWAP State: Join
!--- WLC responds with a join reply to the LAP.
*spamApTask7: Jun 16 12:38:43.964: 00:62:ec:60:ea:20 Configuration Status from 172.16.17.99:46317
*spamApTask7: Jun 16 12:38:43.964: 00:62:ec:60:ea:20 CAPWAP State: Configure !--- LAP requests for the configuration information from the WLC.
*spamApTask7: Jun 16 12:38:43.964: 00:62:ec:60:ea:20 Updating IP info for AP 00:62:ec:60:ea:20 -- static 0, 172.16.17.99/255.255.254.0, gtw 172.16.16.1
*spamApTask7: Jun 16 12:38:43.964: 00:62:ec:60:ea:20 Updating IP 172.16.17.99 ===> 172.16.17.99 for AP 00:62:ec:60:ea:20
*spamApTask7: Jun 16 12:38:43.964: 00:62:ec:60:ea:20 Running spamDecodeVlanProfMapPayload for00:62:ec:60:ea:20
*spamApTask7: Jun 16 12:38:43.964: 00:62:ec:60:ea:20 Setting MTU to 1485
*spamApTask7: Jun 16 12:38:44.019: 00:62:ec:60:ea:20 Configuration Status Response sent to 172:16:17:99
!--- WLC responds by providing all the necessary configuration information to the LAP. *spamApTask7: Jun 16 12:38:46.882: 00:62:ec:60:ea:20 Change State Event Request from 172.16.17.99:46317
*spamApTask7: Jun 16 12:38:46.883: 00:62:ec:60:ea:20 Radio state change for slot: 0 state: 2 cause: 0 detail cause: 69
*spamApTask7: Jun 16 12:38:46.883: 00:62:ec:60:ea:20 Change State Event Response sent to 172.16.17.99:46317
.
.
.
.
*spamApTask7: Jun 16 12:38:46.883: 00:62:ec:60:ea:20 CAPWAP State: Run
*spamApTask7: Jun 16 12:38:46.883: 00:62:ec:60:ea:20 Sending the remaining config to AP 172.16.17.99:46317!
.
.
.
. !--- LAP is up and ready to service wireless clients. *spamReceiveTask: Jun 16 12:38:46.897: 00:62:ec:60:ea:20 Configuration update request for RrmInterferenceCtrl payload sent to 172:16:17:99
*spamReceiveTask: Jun 16 12:38:46.897: 00:62:ec:60:ea:20 Configuration update request for RrmNeighbourCtrl payload sent to 172.16.17.99
*spamReceiveTask: Jun 16 12:38:46.897: 00:62:ec:60:ea:20 Configuration update request for RrmReceiveCtrl payload sent to 172:16:17:99
*spamReceiveTask: Jun 16 12:38:46.897: 00:62:ec:60:ea:20 Configuration update request for CcxRmMeas payload sent to 172.16.17.99
!--- WLC sends all the RRM and other configuration parameters to the LAP.
Come accennato nella sezione precedente, una volta che un LAP si registra sul WLC, controlla se ha la stessa immagine del controller. Se le immagini sul LAP e sul WLC sono diverse, i LAP scaricano per prima cosa la nuova immagine dal WLC. Se il LAP ha la stessa immagine, continua a scaricare la configurazione e gli altri parametri dal WLC.
Questi messaggi vengono visualizzati nell'output del debug capwap events enable
comando se il LAP scarica un'immagine dal controller come parte del processo di registrazione:
*spamApTask6: Jun 17 14:23:28.677: 00:62:ec:60:ea:20 Sending image data block of length 1324 and msgLength = 1327
*spamApTask6: Jun 17 14:23:28.677: 00:62:ec:60:ea:20 Image Data Request sent to 172.16.17.201:46318
*spamApTask6: Jun 17 14:23:28.693: 00:62:ec:60:ea:20 Image data Response from 172.16.17.201:46318
Una volta completato il download dell'immagine, il LAP si riavvia, esegue il rilevamento e si unisce di nuovo all'algoritmo.
Come parte del processo di join, il WLC autentica ogni LAP confermando la validità del relativo certificato.
Quando l'access point invia la richiesta di collegamento CAPWAP al WLC, incorpora il certificato X.509 nel messaggio CAPWAP. L'access point genera anche un ID di sessione casuale incluso nella richiesta di collegamento CAPWAP. Quando il WLC riceve la richiesta di aggiunta CAPWAP, convalida la firma del certificato X.509 con la chiave pubblica dell'access point e verifica che il certificato sia stato rilasciato da un'autorità di certificazione attendibile.
Vengono inoltre analizzate la data e l'ora di inizio per l'intervallo di validità del certificato AP e vengono confrontate la data e l'ora con la data e l'ora corrispondenti (pertanto è necessario impostare l'orologio del controller in prossimità della data e dell'ora correnti). Se il certificato X.509 è convalidato, il WLC genera una chiave di crittografia AES casuale. Il WLC inserisce le chiavi AES nel suo motore di crittografia in modo da poter crittografare e decrittografare i futuri messaggi di controllo CAPWAP scambiati con l'AP. Tenere presente che i pacchetti di dati vengono inviati in chiaro nel tunnel CAPWAP tra il LAP e il controller.
Il comando debug pm pki enable
mostra il processo di convalida della certificazione che si verifica nella fase di join sul controller. Il debug pm pki enable
comando visualizza anche la chiave hash AP al processo di join, se l'access point ha un certificato autofirmato (SSC) creato dal programma di conversione LWAPP. Se il punto di accesso dispone di un certificato di installazione prodotto (MIC), non verrà visualizzata alcuna chiave hash.
Nota: tutti gli access point prodotti dopo giugno 2006 hanno un certificato MIC.
Di seguito è riportato l'output del debug pm pki enable
comando quando il LAP con un MIC si unisce al controller:
Nota: alcune righe dell'output sono state spostate nella seconda riga a causa di vincoli di spazio.
*spamApTask4: Mar 20 11:05:15.687: [SA] OpenSSL Get Issuer Handles: locking ca cert table
*spamApTask4: Mar 20 11:05:15.688: [SA] OpenSSL Get Issuer Handles: x509 subject_name /C=US/ST=California/L=San Jose/O=Cisco Systems/
CN=AP3G2-1005cae83a42/emailAddress=support@cisco.com
*spamApTask4: Mar 20 11:05:15.688: [SA] OpenSSL Get Issuer Handles: issuer_name /O=Cisco Systems/CN=Cisco Manufacturing CA
*spamApTask4: Mar 20 11:05:15.688: [SA] OpenSSL Get Issuer Handles: CN AP3G2-1005cae83a42
*spamApTask4: Mar 20 11:05:15.688: [SA] OpenSSL Get Issuer Handles: issuerCertCN Cisco Manufacturing CA
*spamApTask4: Mar 20 11:05:15.688: [SA] GetMac: MAC: 1005.cae8.3a42
*spamApTask4: Mar 20 11:05:15.688: [SA] OpenSSL Get Issuer Handles: openssl Mac Address in subject is 10:05:ca:e8:3a:42
*spamApTask4: Mar 20 11:05:15.688: [SA] OpenSSL Get Issuer Handles: CN AP3G2-1005cae83a42
*spamApTask4: Mar 20 11:05:15.688: [SA] OpenSSL Get Issuer Handles: issuerCertCN Cisco Manufacturing CA
*spamApTask4: Mar 20 11:05:15.688: [SA] GetMac: MAC: 1005.cae8.3a42
*spamApTask4: Mar 20 11:05:15.688: [SA] OpenSSL Get Issuer Handles: openssl Mac Address in subject is 10:05:ca:e8:3a:42
*spamApTask4: Mar 20 11:05:15.688: [SA] OpenSSL Get Issuer Handles: Cert Name in subject is AP3G2-1005cae83a42
*spamApTask4: Mar 20 11:05:15.688: [SA] OpenSSL Get Issuer Handles: Extracted cert issuer from subject name.
*spamApTask4: Mar 20 11:05:15.688: [SA] OpenSSL Get Issuer Handles: Cert is issued by Cisco Systems.
*spamApTask4: Mar 20 11:05:15.688: [SA] Retrieving x509 cert for CertName cscoDefaultMfgCaCert
*spamApTask4: Mar 20 11:05:15.688: [SA] sshpmGetCID: called to evaluate <cscoDefaultMfgCaCert>
*spamApTask4: Mar 20 11:05:15.688: [SA] sshpmGetCID: Found matching CA cert cscoDefaultMfgCaCert in row 5
*spamApTask4: Mar 20 11:05:15.688: [SA] Found CID 260e5e69 for certname cscoDefaultMfgCaCert
*spamApTask4: Mar 20 11:05:15.688: [SA] CACertTable: Found matching CID cscoDefaultMfgCaCert in row 5 x509 0x2cc7c274
*spamApTask4: Mar 20 11:05:15.688: [SA] Retrieving x509 cert for CertName cscoDefaultNewRootCaCert
*spamApTask4: Mar 20 11:05:15.688: [SA] sshpmGetCID: called to evaluate <cscoDefaultNewRootCaCert>
*spamApTask4: Mar 20 11:05:15.688: [SA] sshpmGetCID: Found matching CA cert cscoDefaultNewRootCaCert in row 4
*spamApTask4: Mar 20 11:05:15.688: [SA] Found CID 28d7044e for certname cscoDefaultNewRootCaCert
*spamApTask4: Mar 20 11:05:15.688: [SA] CACertTable: Found matching CID cscoDefaultNewRootCaCert in row 4 x509 0x2cc7c490
*spamApTask4: Mar 20 11:05:15.691: [SA] Verify User Certificate: X509 Cert Verification return code: 1
*spamApTask4: Mar 20 11:05:15.691: [SA] Verify User Certificate: X509 Cert Verification result text: ok
*spamApTask4: Mar 20 11:05:15.691: [SA] sshpmGetCID: called to evaluate <cscoDefaultMfgCaCert>
*spamApTask4: Mar 20 11:05:15.691: [SA] sshpmGetCID: Found matching CA cert cscoDefaultMfgCaCert in row 5
*spamApTask4: Mar 20 11:05:15.691: [SA] Verify User Certificate: OPENSSL X509_Verify: AP Cert Verfied Using >cscoDefaultMfgCaCert<
*spamApTask4: Mar 20 11:05:15.691: [SA] OpenSSL Get Issuer Handles: Check cert validity times (allow expired NO)
*spamApTask4: Mar 20 11:05:15.691: [SA] sshpmGetCID: called to evaluate <cscoDefaultIdCert>
*spamApTask4: Mar 20 11:05:15.691: [SA] sshpmGetCID: Found matching ID cert cscoDefaultIdCert in row 2
*spamApTask4: Mar 20 11:05:15.691: [SA] sshpmFreePublicKeyHandle: called with 0x1b0b9380
*spamApTask4: Mar 20 11:05:15.691: [SA] sshpmFreePublicKeyHandle: freeing public key
Se i debug del controller non indicano una richiesta di join, è possibile eseguire il debug del processo dall'access point se quest'ultimo dispone di una porta console. È possibile visualizzare il processo di avvio dell'access point con questi comandi, a condizione che venga prima attivata la modalità di abilitazione (la password predefinita è Cisco).
debug dhcp detail
:mostra le informazioni DHCP opzione 43.
debug ip udp
: visualizza tutti i pacchetti UDP ricevuti e trasmessi dall'access point. debug capwap client event
:mostra gli eventi capwap dell'access point.
debug capwap client error
:mostra gli errori capwap dell'access point. debug dtls client event
:mostra gli eventi DTLS dell'access point. debug dtls error enable
:mostra gli errori DTLS dell'access point. undebug all
:disabilita i debug sull'access point.
Di seguito è riportato un esempio dell'output deidebug capwap
comandi. Questo output parziale fornisce un'idea dei pacchetti inviati dall'access point durante il processo di avvio per individuare un controller e aggiungerlo.
AP can discover the WLC via one of these options :
!--- AP discovers the WLC via option 43
*Jun 28 08:43:05.839: %CAPWAP-5-DHCP_OPTION_43: Controller address 10.63.84.78 obtained through DHCP
*Jun 28 08:43:15.963: %CAPWAP-3-EVENTLOG: Discovery Request sent to 10.63.84.78 with discovery type set to 2
!--- capwap Discovery Request using the statically configured controller information.
*Jun 28 08:43:15.963: %CAPWAP-3-EVENTLOG: Discovery Request sent to 10.63.84.32 with discovery type set to 1
!--- Capwap Discovery Request sent using subnet broadcast.
*Jun 28 08:43:15.963: %CAPWAP-3-EVENTLOG: Discovery Request sent to 255.255.255.255 with discovery type set to 0
!--- capwap Join Request sent to AP-Manager interface on DHCP discovered controller.
*Jun 28 08:40:29.031: %CAPWAP-5-SENDJOIN: sending Join Request to 10.63.84.78
L'access point e il WLC possono comunicare?
Accertarsi che l'access point ottenga un indirizzo da DHCP (verificare che il server DHCP abbia in lease l'indirizzo MAC dell'access point).
Eseguire il ping tra l'access point e il controller.
Verificare che la configurazione STP sullo switch sia corretta, in modo che i pacchetti alle VLAN non vengano bloccati.
Se i ping hanno esito positivo, assicurarsi che l'access point abbia almeno un metodo con cui rilevare almeno una singola console WLC o telnet/ssh nel controller con cui eseguire i debug.
Ad ogni riavvio dell'access point, viene avviata la sequenza di rilevamento del WLC e si cerca di individuare l'access point. Riavviare l'access point e verificare se si collega al WLC.
Ecco alcuni dei problemi più comuni che impediscono il collegamento dei LAP al WLC.
I certificati integrati nell'hardware sono validi per un periodo di 10 anni dopo la produzione. Se i punti di accesso o il WLC hanno più di 10 anni, i certificati scaduti possono causare problemi di aggiunta ai punti di accesso. Ulteriori informazioni su questo problema sono disponibili nel seguente avviso: Notifica: FN63942.
Completare questa procedura per risolvere il problema:
debug dtls client error + debug dtls client event
nell'access point:
*Jun 28 09:21:25.011: DTLS_CLIENT_EVENT: dtls_process_Certificate: Processing...Peer certificate verification failed 001A
*Jun 28 09:21:25.031: DTLS_CLIENT_ERROR: ../capwap/base_capwap/capwap/base_capwap_wtp_dtls.c:509 Certificate verified failed!
*Jun 28 09:21:25.031: DTLS_CLIENT_EVENT: dtls_send_Alert: Sending FATAL : Bad certificate Alert
*Jun 28 09:21:25.031: DTLS_CLIENT_EVENT: dtls_client_process_record: Error processing Certificate.
*Jun 28 09:21:25.031: DTLS_CLIENT_EVENT: dtls_disconnect: Disconnecting DTLS connection 0x8AE7FD0
*Jun 28 09:21:25.031: DTLS_CLIENT_EVENT: dtls_free_connection: Free Called... for Connection 0x8AE7FD0
*Jun 28 09:21:25.031: DTLS_CLIENT_EVENT: dtls_send_Alert: Sending FATAL : Close notify Alert
Queste informazioni indicano chiaramente che l'ora del controller non rientra nell'intervallo di validità del certificato del punto di accesso. Pertanto, l'access point non può registrarsi sul controller. I certificati installati nell'access point hanno un intervallo di validità predefinito. È necessario impostare l'ora del controller in modo che rientri nell'intervallo di validità del certificato del punto di accesso.
show time
comando dalla CLI del controller per verificare che la data e l'ora impostate sul controller rientrino in questo intervallo di validità. Se la data e l'ora del controller non rientrano nell'intervallo di validità del certificato, modificarle opportunamente.Nota: se l'ora non è impostata correttamente sul controller, scegliereCommands > Set Time
in modalità GUI del controller o usare il comando config time nella CLI del controller per impostare l'ora del controller.
show crypto ca certificates
comando da AP CLI. Questo comando consente di verificare l'intervallo di validità del certificato impostato nell'access point. Ecco un esempio:
AP00c1.649a.be5c#show crypto ca cert
............................................
............................................
.............................................
................................................
Certificate
Status: Available
Certificate Serial Number (hex): 7D1125A900000002A61A
Certificate Usage: General Purpose
Issuer:
cn=Cisco Manufacturing CA SHA2
o=Cisco
Subject:
Name: AP1G2-00c1649abe5c
e=support@cisco.com
cn=AP1G2-00c1649abe5c
o=Cisco Systems
l=San Jose
st=California
c=US
CRL Distribution Points:
http://www.cisco.com/security/pki/crl/cmca2.crl
Validity Date:
start date: 01:05:37 UTC Mar 24 2016
end date: 01:15:37 UTC Mar 24 2026
Associated Trustpoints: Cisco_IOS_M2_MIC_cert
Storage:
..................................
....................................
......................................
L'intero output non è elencato perché all'output di questo comando possono essere associati molti intervalli di validità. Prendere in considerazione solo l'intervallo di validità specificato dal Trustpoint associato: Cisco_IOS_MIC_cert con il nome dell'access point appropriato nel campo del nome. In questo output di esempio, è Nome: C1200-001563e50c7e. Questo è l'intervallo di validità del certificato effettivo da prendere in considerazione.
Questo messaggio viene visualizzato nell'output del debug capwap events enable
comando:
*spamApTask7: Jun 28 11:56:49.177: 00:cc:fc:13:e5:e0 AP 00:cc:fc:13:e5:e0: Country code is not configured(BE ).
*spamApTask7: Jun 28 11:56:49.177: 00:cc:fc:13:e5:e0 AP 00:cc:fc:13:e5:e0: Country code is not configured(BE ).
*spamApTask7: Jun 28 11:56:49.177: 00:cc:fc:13:e5:e0 Setting MTU to1485
*spamApTask7: Jun 28 11:56:49.177: 00:cc:fc:13:e5:e0 AP 00:cc:fc:13:e5:e0: Country code is not configured(BE ).
*spamApTask7: Jun 28 11:56:49.177: 00:cc:fc:13:e5:e0 Regulatory Domain Mismatch: AP 00:cc:fc:13:e5:e0 not allowed to join. Allowed domains: 802.11bg:-A
*spamApTask7: Jun 28 11:56:49.177: 00:cc:fc:13:e5:e0 Finding DTLS connection to delete for AP (192:168:47:29/60390)
*spamApTask7: Jun 28 11:56:49.177: 00:cc:fc:13:e5:e0 Disconnecting DTLS Capwap-Ctrl session 0x1d4df620 for AP (192:168:47:29/60390). Notify(true)
*spamApTask7: Jun 28 11:56:49.177: 00:cc:fc:13:e5:e0 acDtlsPlumbControlPlaneKeys: lrad:192.168.47.29(60390) mwar:10.63.84.78(5246)
WLC msglog show these messages :
*spamApTask5: Jun 28 11:52:06.536: %CAPWAP-3-DTLS_CLOSED_ERR: capwap_ac_sm.c:7095 00:cc:fc:13:e5:e0: DTLS connection
closed forAP 192:168:47:28 (60389), Controller: 10:63:84:78 (5246) Regulatory Domain Mismatch
Il messaggio indica chiaramente che c'è una mancata corrispondenza nel dominio normativo del LAP e del WLC. Il WLC supporta più domini normativi, ma ogni dominio normativo deve essere selezionato prima che un access point possa essere aggiunto da quel dominio. Ad esempio, il WLC che usa il dominio normativo -A può essere usato solo con gli access point che usano il dominio normativo -A (e così via). Quando si acquistano access point, assicurarsi che condividano lo stesso dominio normativo. Solo in questo modo gli l'access point possono registrarsi sul WLC.
Nota: le onde radio 802.1b/g e 802.11a devono trovarsi nello stesso dominio normativo di un unico access point.
In questi casi, il messaggio seguente viene visualizzato sul controller nell'output deldebug capwap events enable
comando:
Wed Sep 12 17:42:39 2007: 00:0b:85:51:5a:e0 Received CAPWAP DISCOVERY REQUEST from AP 00:0b:85:51:5a:e0 to 00:0b:85:33:52:80 on port '1' Wed Sep 12 17:42:39 2007: 00:0b:85:51:5a:e0 Successful transmission of CAPWAP Discovery-Response to AP 00:0b:85:51:5a:e0 on Port 1 Wed Sep 12 17:42:39 2007: 00:0b:85:51:5a:e0 Received LWAPP DISCOVERY REQUEST from AP 00:0b:85:51:5a:e0 to ff:ff:ff:ff:ff:ff on port '1' Wed Sep 12 17:42:39 2007: 00:0b:85:51:5a:e0 Successful transmission of CAPWAP Discovery-Response to AP 00:0b:85:51:5a:e0 on Port 1 Wed Sep 12 17:42:50 2007: 00:0b:85:51:5a:e0 Received CAPWAP JOIN REQUEST from AP 00:0b:85:51:5a:e0 to 00:0b:85:33:52:80 on port '1' Wed Sep 12 17:42:50 2007: 00:0b:85:51:5a:e0 AP ap:51:5a:e0: txNonce 00:0B:85:33:52:80 rxNonce 00:0B:85:51:5A:E0 Wed Sep 12 17:42:50 2007: 00:0b:85:51:5a:e0 CAPWAP Join-Request MTU path from AP 00:0b:85:51:5a:e0 is 1500, remote debug mode is 0 Wed Sep 12 17:42:50 2007: spamRadiusProcessResponse: AP Authorization failure for 00:0b:85:51:5a:e0
Se si usa un LAP con una porta console, quando si usa il comando viene visualizzato questo messaggiodebug capwap client error
:
AP001d.a245.a2fb# *Mar 1 00:00:52.267: LWAPP_CLIENT_ERROR_DEBUG: spamHandleJoinTimer: Did not receive the Join response *Mar 1 00:00:52.267: LWAPP_CLIENT_ERROR_DEBUG: No more AP manager IP addresses remain.
Anche in questo caso, è chiaro che il LAP non fa parte dell'elenco di autorizzazioni dei punti di accesso sul controller.
È possibile visualizzare lo stato dell'elenco di autorizzazioni AP con questo comando:
(Cisco Controller) >show auth-list Authorize APs against AAA ....................... enabled Allow APs with Self-signed Certificate (SSC) .... disabled
Per aggiungere un LAP all'elenco delle autorizzazioni dei punti di accesso, usare ilconfig auth-list add mic
comando. Per ulteriori informazioni su come configurare l'autorizzazione del LAP, fare riferimento alla configurazione di esempio dell'autorizzazione del Lightweight Access Point (LAP) in una Cisco Unified Wireless Network.
Il LAP non può collegarsi al controller a causa di un problema nel certificato.
Eseguire i comandidebug capwap errors enable
e debug pm pki enable
. Vengono visualizzati dei messaggi che indicano le chiavi o i certificati danneggiati.
Nota: a causa dei limiti di spazio, in alcuni punti l'output è stato suddiviso su due righe.
Tue Aug 12 17:36:09 2008: 00:0f:24:a9:52:e0 CAPWAP Join Request does not include valid certificate in CERTIFICATE_PAYLOAD from AP 00:0f:24:a9:52:e0. Tue Aug 12 17:36:09 2008: 00:0f:24:a9:52:e0 Deleting and removing AP 00:0f:24:a9:52:e0 from fast path Tue Aug 12 17:36:09 2008: 00:0f:24:a9:52:e0 Unable to free public key for AP
Per risolvere il problema, usare una di queste due opzioni:
Questo messaggio viene visualizzato nell'output deldebug capwap events enable
comando:
Received a Discovery Request with subnet broadcast with wrong AP IP address (A.B.C.D)!
Questo messaggio indica che il controller ha ricevuto una richiesta di individuazione da parte di un indirizzo IP di trasmissione con un indirizzo IP di origine che non si trova in alcuna subnet configurata sul controller. Ciò significa anche che il controller è quello che scarta il pacchetto.
Il problema è che l'access point non è quello che ha inviato la richiesta di rilevamento all'indirizzo IP di gestione. Il controller segnala una richiesta di rilevamento broadcast da una VLAN non configurata sul controller. Questo si verifica in genere quando i trunk permettono le VLAN e non le restringono alle VLAN wireless.
Completare questa procedura per risolvere il problema:
Se nella rete aziendale viene utilizzato un firewall, verificare che queste porte siano abilitate sul firewall in modo che il LAP si colleghi e comunichi con il controller.
È necessario abilitare queste porte:
Abilitare queste porte UDP per il traffico CAPWAP:
Dati - 5247
Controllo - 5246
Abilitare queste porte UDP per il traffico di mobilità:
16666 - 16666
16667 - 16667
Abilitare le porte UDP 5246 e 5247 per il traffico CAPWAP.
TCP 161 e 162 per SNMP (per Wireless Control System [WCS])
Queste porte sono facoltative (a seconda dei requisiti):
UDP 69 per TFTP
TCP 80 e/o 443 per HTTP o HTTPS per l'accesso GUI
TCP 23 e/o 22 per Telnet o SSH per l'accesso CLI
Si tratta di un altro problema comune che si verifica quando l'AP tenta di unirsi al WLC. È possibile visualizzare questo messaggio di errore quando l'access point tenta di collegarsi al controller.
No more AP manager IP addresses remain
Uno dei motivi di questo messaggio di errore è la presenza di un indirizzo IP duplicato sulla rete che corrisponde all'indirizzo IP dell'AP-manager. In questo caso, il LAP mantiene le avviazioni del ciclo di alimentazione e non può unirsi al controller.
I debug mostrano che il WLC riceve le richieste di rilevamento LWAPP dagli access point e trasmette una risposta di rilevamento LWAPP agli access point.
Tuttavia, i WLC non ricevono le richieste di collegamento LWAPP dagli access point.
Per risolvere questo problema, eseguire il ping del gestore AP da un host cablato sulla stessa subnet IP dell'AP-manager. Quindi, controllare la cache ARP. Se viene rilevato un indirizzo IP duplicato, rimuovere il dispositivo con l'indirizzo IP duplicato o modificare l'indirizzo IP sul dispositivo in modo che abbia un indirizzo IP univoco sulla rete.
L'access point potrà quindi collegarsi al WLC.
Il Lightweight Access Point non si registra sul WLC. Il registro visualizza il seguente messaggio di errore:
AAA Authentication Failure for UserName:5475xxx8bf9c User Type: WLAN USER
Ciò può accadere se il Lightweight Access Point è stato fornito con un'immagine mesh ed è in modalità bridge. Se il LAP è stato ordinato con un software mesh, è necessario aggiungerlo all'elenco degli access point autorizzati. Selezionare Security > AP Policies (Sicurezza > Policy AP) e aggiungere l'access point all'elenco degli access point autorizzati. L'access point deve quindi unirsi, scaricare l'immagine dal controller, quindi registrare il WLC in modalità bridge. Infine, è necessario selezionare la modalità locale sull'access point. Il LAP scarica l'immagine, si riavvia e si registra nuovamente sul controller in modalità locale.
I punti di accesso possono rinnovare rapidamente i propri indirizzi IP quando viene effettuato un tentativo di connessione a un WLC, il che può causare ai server DHCP Windows di contrassegnare questi IP come BAD_ADDRESS che potrebbe rapidamente ridurre il pool DHCP. Per ulteriori informazioni, consultare il capitolo Client Roaming della guida alla configurazione di Cisco Wireless Controller, versione 8.2.
Revisione | Data di pubblicazione | Commenti |
---|---|---|
7.0 |
12-Jan-2024 |
Aggiunto un riferimento a 9800 ap join |
6.0 |
11-Dec-2023 |
Certificazione finale |
5.0 |
03-Nov-2022 |
Aggiornati gli stili e il contenuto dei documenti per garantire la conformità agli standard di pubblicazione Cisco.com correnti. |
1.0 |
31-Jul-2015 |
Versione iniziale |