Introduction

Ce document donne une présentation du processus de détection et de jointure d'un contrôleur de réseau local sans fil (WLC). Il fournit également des informations sur certains des problèmes en raison desquels un point d'accès léger (LAP) ne parvient pas à joindre un WLC et sur la façon de dépanner ces problèmes.

Conditions préalables

Exigences

Cisco vous recommande de prendre connaissance des rubriques suivantes :

• Connaissance de base de la configuration des LAP et des WLC Cisco

• Connaissance de base de point d'accès léger Protocol (CAPWAP)

Conventions

Pour plus d'informations sur les conventions utilisées dans ce document, reportez-vous à Conventions relatives aux conseils techniques Cisco.

Présentation du processus de détection et de jointure d'un contrôleur de réseau local sans fil (WLC)

Dans un réseau sans fil unifié Cisco, les LAP doivent d'abord détecter et joindre un WLC avant de pouvoir prendre en charge des clients sans fil.

Cependant, ceci présente une question : comment les recouvrements ont-ils trouvé l'adresse IP de Gestion du contrôleur quand elle est sur un différent sous-réseau ?

Si vous ne dites pas au RECOUVREMENT où le contrôleur est par l'intermédiaire de l'option 43 DHCP, résolution de DN de « Cisco-capwap-controller.local_domain », ou la configurer statiquement, le RECOUVREMENT ne sait pas où dans le réseau trouver l'interface de gestion du contrôleur.

En plus de ces méthodes, le LAP recherche automatiquement sur le sous-réseau local les contrôleurs ayant la diffusion locale 255.255.255.255. En outre, le LAP se souvient, après les redémarrages, de l'adresse IP de gestion de tout contrôleur qu'il joint. Par conséquent, si vous mettez d'abord le LAP sur le sous-réseau local de l'interface de gestion, il recherchera l'interface de gestion du contrôleur et se souviendra de l'adresse. Cela est appelé « priming ». Cela ne permet pas de trouver le contrôleur si vous remplacez un LAP par la suite. Par conséquent, Cisco recommande d'utiliser l'option DHCP 43 ou des méthodes DNS.

Les recouvrements se connectent toujours à l'adresse d'interface de gestion du contrôleur d'abord à une demande de détection. Le contrôleur indique alors au RECOUVREMENT l'adresse IP d'interface d'AP-gestionnaire de la couche 3 (ce qui peut également être la Gestion par défaut) ainsi le RECOUVREMENT peut envoyer une demande de jonction à l'interface d'AP-gestionnaire ensuite.

AP passe par ce processus sur le startup :

1. Le LAP démarre et applique DHCP à une adresse IP si aucune adresse IP statique ne lui a été précédemment assignée.

2. Le LAP envoie des demandes de détection aux contrôleurs via les divers algorithmes de détection et établit une liste de contrôleurs. En fait, le LAP apprend autant d'adresses d'interface de gestion que possible pour la liste de contrôleurs via :

   1. L'option DHCP 43 (appropriée pour les sociétés mondiales dont les bureaux et les contrôleurs se trouvent sur des continents différents)

   2. L'entrée DNS pour cisco-capwap-controller (appropriée pour les entreprises locales - peut également être utilisée pour rechercher où les tout nouveaux AP établissent une jointure)

      Remarque: Si vous utilisez CAPWAP, assurez-vous qu'il y a une entrée DNS pour cisco-capwap-controller.

   3. Les adresses IP de gestion des contrôleurs dont le LAP se souvient précédemment

   4. Une diffusion de couche 3 sur le sous-réseau

   5. Les informations configurées statiquement

   6. Contrôleurs actuels au groupe de mobilité du WLC AP pour la dernière fois joint

   De cette liste, la méthode facile à l'utiliser pour le déploiement est d'avoir les recouvrements sur le même sous-réseau que l'interface de gestion du contrôleur et de permettre à l'émission de la couche 3 de recouvrements pour trouver le contrôleur. Cette méthode doit être utilisée pour les sociétés qui ont un petit réseau et ne possèdent pas un serveur DNS local.

   La méthode la plus facile suivante du déploiement consiste à utiliser une entrée DNS avec DHCP. Vous pouvez avoir plusieurs entrées du même nom DNS. Cela permet au LAP de détecter plusieurs contrôleurs. Cette méthode doit être utilisée par les sociétés qui ont tous leurs contrôleurs dans un emplacement unique et qui possèdent un serveur DNS local. Elle doit être utilisée également si la société a plusieurs suffixes DNS et que les contrôleurs sont isolés par suffixe.

   L'option DHCP 43 est utilisée par les grandes sociétés pour localiser les informations via DHCP. Cette méthode est utilisée par les grandes entreprises qui ont un suffixe DNS unique. Par exemple, Cisco possède des locaux en l'Europe, en Australie et aux États-Unis. Afin de garantir que les LAP joignent les contrôleurs uniquement localement, Cisco ne peut pas utiliser une entrée DNS et doit utiliser les informations de l'option DHCP 43 pour indiquer aux LAP quelle est l'adresse IP de gestion de leur contrôleur local.

   Enfin, la configuration statique est utilisée pour un réseau qui n'a pas de serveur DHCP. Vous pouvez statiquement configurer les informations nécessaires pour joindre un contrôleur par l'intermédiaire du port de console et des aps CLI. Pour les informations sur la façon dont configurer statiquement les informations de contrôleur utilisant AP CLI, utilisez la commande suivante :

   AP#capwap ap primary-base <WLCName> <WLCIP>

   Pour les informations sur configurer l'option 43 DHCP sur un serveur DHCP, référez-vous à l'exemple de configuration de l'option 43 DHCP

3. Envoyez une demande de détection à chaque contrôleur de la liste et attendez la réponse de détection du contrôleur qui contient le nom du système, les adresses IP du gestionnaire d'AP, le nombre d'AP déjà attachés à chaque interface de gestionnaire d'AP et la surcapacité globale pour le contrôleur.

4. Consultez la liste de contrôleurs et envoyez une demande de jointure à un contrôleur, dans l'ordre suivant (seulement si l'AP a reçu une réponse de détection de lui) :

   1. Nom du système du contrôleur primaire (précédemment configuré sur le LAP)

   2. Nom du système du contrôleur secondaire (précédemment configuré sur le LAP)

   3. Nom du système du contrôleur tertiaire (précédemment configuré sur le LAP)

   4. Contrôleur principal (si le LAP n'a pas été précédemment configuré avec des noms de contrôleurs primaires, secondaires ou tertiaires. Utilisé pour toujours savoir à quel contrôleur les tout nouveaux LAP se joignent)

   5. Si aucune des options ci-dessus n'apparaît, équilibrez la charge entre les contrôleurs en utilisant la valeur de surcapacité dans la réponse de détection.

      Si deux contrôleurs ont la même surcapacité, envoyez la demande de jointure au premier contrôleur qui a répondu à la demande de détection avec une réponse de détection. Si un seul contrôleur a plusieurs gestionnaires d'AP sur plusieurs interfaces, choisissez l'interface de gestionnaire d'AP ayant avec le plus petit nombre d'AP.

      Le contrôleur répondra à toutes les demandes de détection sans vérifier les certificats ou des informations d'identification des AP. Cependant, les demandes de jointure doivent avoir un certificat valide pour obtenir une réponse de jointure du contrôleur. Si le LAP ne reçoit pas une réponse de jointure de son choix, il essayera le contrôleur suivant dans la liste, à moins que le contrôleur ne soit un contrôleur configuré (primaire/secondaire/tertiaire).

5. Quand il reçoit la réponse de jointure, l'AP vérifie qu'il a la même image que celle du contrôleur. Si ce n'est pas le cas, l'AP télécharge l'image à partir du contrôleur et redémarre pour charger la nouvelle image, puis recommence tout le processus depuis l'étape 1.

6. S'il a la même image logicielle, il demande la configuration à partir du contrôleur et passe dans l'état enregistré sur le contrôleur.

   Une fois la configuration téléchargée, l'AP peut se recharger de nouveau pour appliquer la nouvelle configuration. Par conséquent, un rechargement supplémentaire peut se produire, ce qui constitue un comportement normal.

Déboguer à partir du contrôleur

Il y a certaines commandes debug sur le contrôleur que vous pouvez utiliser pour afficher la totalité de ce processus sur la CLI.

• paquets de détection d'expositions déboguez de capwap d'événements enable†des » et joignez les paquets.

• informations de niveau de paquet d'expositions déboguez de capwap de paquet enable†les » de la détection et joignez les paquets.

• processus de validation de certificat d'expositions d'enable†de PKI de debug pm ».

• le débronchement-all†de débogage » arrête des débogages.

Avec une application du terminal qui peut capturer la sortie dans un fichier journal, connectez la console à votre contrôleur ou appliquez-lui Secure Shell (SSH)/Telnet, puis entrez les commandes suivantes :

    config session timeout 120
    config serial timeout 120
    show run-config     (and spacebar thru to collect all)
 
    debug mac addr <ap-radio-mac-address>
    (in xx:xx:xx:xx:xx format)
    debug client <ap-mac-address>

    debug capwap events enable
    debug capwap errors enable
    debug pm pki enable

Après avoir capturé les débogages, utilisez la commande debug disable-all pour désactiver tous les débogages.

Les sections suivantes montrent la sortie de ces commandes debug quand le LAP s'enregistre auprès du contrôleur.

enable d'événements de capwap de débogage

Cette commande fournit des informations sur les événements CAPWAP et erreurs qui se produisent pendant la détection et le processus de jonction CAPWAP.

C'est la sortie de commande d'enable d'événements de capwap de débogage pour un RECOUVREMENT qui a la même image que celle du WLC :

Remarque: Certaines lignes de la sortie ont été déplacées sur la deuxième ligne en raison de contraintes d'espace.

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.

Comme mentionné dans la section précédente, une fois qu'un LAP s'enregistre auprès du WLC, il vérifie s'il a la même image que le contrôleur. Si les images sur le LAP et le WLC sont différentes, les LAP commencent par télécharger la nouvelle image à partir du WLC. Si le LAP a la même image, il continue à télécharger la configuration et d'autres paramètres à partir du WLC.

Vous verrez ces messages dans les événements de capwap de débogage activer la sortie de commande si le RECOUVREMENT télécharge une image du contrôleur comme partie de la procédure d'enregistrement :

*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

Une fois le téléchargement de l'image terminé, le LAP redémarrera et exécutera de nouveau l'algorithme de détection et de jointure.

debug pm pki enable

Dans le cadre du processus de jointure, le WLC authentifie chaque LAP en vérifiant que son certificat est valide.

Quand AP envoie la demande de jonction CAPWAP au WLC, il encastre son certificat X.509 dans le message CAPWAP. AP génère également un ID de session aléatoire qui est également inclus dans la demande de jonction CAPWAP. Quand le WLC reçoit la demande de jonction CAPWAP, il valide la signature du certificat X.509 utilisant la clé publique et les contrôles d'AP que le certificat a été délivré par une autorité de certification de confiance.

Il également regarde la date et l'heure commençantes pour l'intervalle de la validité du certificat AP et compare que date et temps à sa propre date et temps (par conséquent l'horloge du contrôleur doit être réglée à près de la date et heure actuelles). Si le certificat X.509 est validé, le WLC génère une clé de chiffrement AES aléatoire. Le WLC met d'aplomb la clé AES dans son moteur de chiffrement de sorte qu'il puisse chiffrer et déchiffrer de futurs messages de contrôle CAPWAP permutés avec AP. Notez que des paquets de données sont envoyés en clair dans le tunnel CAPWAP entre le RECOUVREMENT et le contrôleur.

La commande debug pm pki enable présente le processus de validation de la certification qui se produit pendant la phase de jointure sur le contrôleur. La commande debug pm pki enable affichera également la clé de hachage de l'AP pendant le processus de jointure si l'AP a un certificat auto-signé (SSC) créé par le programme de conversion LWAPP. Si l'AP a un certificat installé manufacturé (MIC), vous ne verrez pas de clé de hachage.

Remarque: Tous les AP fabriqués après juin 2006 ont un certificat MIC.

Voici la sortie de la commande debug pm pki enable quand le LAP ayant un certificat MIC joint le contrôleur :

Remarque: Certaines lignes de la sortie ont été déplacées sur la deuxième ligne en raison de contraintes d'espace.

*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

Débogage d'AP

Si les débogages de contrôleur n'indiquent pas une demande de jonction, vous pouvez déboguer le processus d'AP tant que AP a un port de console.  Vous pouvez voir le processus d'amorce AP avec ces commandes, mais vous devez d'abord entrer dans le mode enable (le mot de passe par défaut est Cisco) :

• détail de debug dhcp : Les informations de l'option 43 DHCP d'expositions.

• debug ip udp : Affiche tous les paquets UDP reçus et transmis par AP

• événement de client de capwap de débogage : Affiche des événements de capwap pour AP.

• erreur de client de capwap de débogage :  Affiche des erreurs de capwap pour AP.
• événement de client de dtls de débogage : Événements des expositions DTLS pour AP.
• enable d'erreur de dtls de débogage : Erreurs des expositions DTLS pour AP.

• undebug all : Débogages de débronchements sur AP.

Voici un exemple de la sortie des commandes de capwap de débogage. Cette sortie partielle donne une idée des paquets qui sont envoyés par AP pendant le processus de démarrage pour découvrir et joindre un contrôleur.

AP can discover the WLC via one of the following 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

Raisons pour lesquelles le LAP ne joint pas le contrôleur

Effectuer tout d'abord les vérifications de base

• L'AP et le WLC peuvent-ils communiquer ?

• Assurez-vous qu'AP obtient une adresse de DHCP (vérifiez les baux de serveur DHCP pour l'adresse MAC d'AP).

• Essayez d'effectuer un test Ping sur l'AP à partir du contrôleur.

• Vérifiez si la configuration STP sur le commutateur est faite convenablement de sorte que des paquets vers les VLAN ne soient pas bloqués.

• Si les tests Ping sont effectués avec succès, vérifiez que l'AP a au moins une méthode permettant de détecter au moins une console de WLC ou d'appliquer Telnet/SSH dans le contrôleur pour exécuter les débogages.

• Chaque fois que l'AP redémarre, il lance la séquence de détection des WLC et essaie de localiser l'AP. Redémarrez l'AP et vérifiez s'il joint le WLC.

Voici certains des problèmes couramment rencontrés en raison de quoi les LAP ne joignent pas le WLC.

Avis sur le champ : F-N - 63942

https://www.cisco.com/c/en/us/support/docs/field-notices/639/fn63942.html

Problème 1 : L'heure du contrôleur est en dehors de l'intervalle de validité du certificat

Effectuez les étapes suivantes afin de résoudre ce problème :

1.  L'erreur de client de dtls de débogage de question + l'événement de client de dtls de débogage commande sur AP :
   
   

   
   *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
   
   

   Cette information montre clairement que le temps du contrôleur est en dehors de l'intervalle de validité du certificat d'AP. Par conséquent, AP ne peut pas enregistrer avec le contrôleur. Les certificats installés dans AP ont un intervalle de validité prédéfini. Le temps de contrôleur devrait être placé de telle manière qu'il soit dans l'intervalle de validité de certificat du certificat d'AP.

2. Émettez la commande show time du contrôleur CLI afin de vérifier que la date et l'heure définis sur votre contrôleur tombent dans cet intervalle de validité. Si l'heure du contrôleur est ultérieure ou antérieure à cet intervalle de validité du certificat, modifiez l'heure du contrôleur pour qu'elle soit dans cet intervalle.

   Remarque: Si l'heure n'est pas définie correctement sur le contrôleur, choisissez Commands > Set Time en mode GUI du contrôleur, ou émettez la commande config time dans la CLI du contrôleur afin de définir l'heure du contrôleur.

3. Sur des aps avec l'accès CLI, vérifiez les Certificats avec la commande de show crypto ca certificat d'AP CLI.

   Cette commande vous permet de vérifier l'intervalle de validité du certificat défini dans l'AP. Voici un exemple :

   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:
   ..................................
   ....................................
   ......................................

   La sortie entière n'est pas listée car il peut y avoir beaucoup d'intervalles de validité associés avec la sortie de cette commande. Vous devez considérer seulement l'intervalle de validité spécifié par le point de confiance associé : Cisco_IOS_MIC_cert avec le nom d'AP pertinent dans le champ de nom. Dans cet exemple de sortie, c'est Name: C1200-001563e50c7e. C'est l'intervalle réel de validité du certificat à considérer.

4. veuillez se référer à CSCuq19142 LAP/WLC MIC ou à expiration de vie de SSC entraîne la panne DTLS :

https://bst.cloudapps.cisco.com/bugsearch/bug/CSCuq19142

Problème 2 : Non-correspondance dans le domaine réglementaire

Vous voyez ce message dans les événements de capwap de débogage activer la sortie de commande :

*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 will show the following :

*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

Le message indique clairement qu'il y a une non-correspondance dans le domaine réglementaire du LAP et du WLC. Domaines réglementaires de supports WLC les plusieurs mais chaque domaine réglementaire doivent être sélectionnés avant qu'AP puisse se joindre de ce domaine. Par exemple, le WLC qui utilise le domaine réglementaire -A peut uniquement être utilisé avec les AP qui utilisent le domaine réglementaire -A (etc.). Quand vous achetez des aps, assurez-vous qu'ils partagent le même domaine réglementaire. C'est la condition nécessaire pour que l'AP s'enregistre auprès du WLC.

Remarque: 802.1b/g et les radios 802.11a doivent être dans le même domaine réglementaire pour AP simple.

Problème 3 : Liste des autorisations d'AP activée sur le WLC ; LAP non présent dans la liste des autorisations

En pareil cas, vous verrez ce message sur le contrôleur dans la sortie de l'enable d'événements de capwap de débogage commander :

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

Si vous utilisez un RECOUVREMENT qui a un port de console, vous verrez ce message quand vous émettez la commande d'erreur de client de capwap de débogage :

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.

Cela indique à nouveau clairement que le LAP ne fait pas partie de la liste des autorisations d'AP sur le contrôleur.

Vous pouvez afficher l'état de la liste des autorisations d'AP à l'aide de la commande suivante :

(Cisco Controller) >show auth-list

Authorize APs against AAA ....................... enabled
Allow APs with Self-signed Certificate (SSC) .... disabled

Afin d'ajouter un LAP à la liste des autorisations d'AP, utilisez la commande config auth-list add mic <AP MAC Address>. Pour plus d'informations sur la façon de configurer l'autorisation d'AP, consultez l'Exemple de configuration de l'autorisation de points d'accès légers (LAP) dans un réseau sans fil unifié Cisco.

Problème 4 : Il y a corruption d'un certificat ou d'une clé publique sur l'AP

Le LAP ne joint pas de contrôleur en raison d'un problème de certificat.

Émettez les commandes d'enable d'erreurs de capwap de débogage et d'enable de PKI de debug pm. Vous voyez des messages qui indiquent que des certificats ou des clés sont altérés.

Remarque: Certaines lignes de la sortie ont été déplacées sur la deuxième ligne en raison de contraintes d'espace.

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

Employez l'une de ces deux options afin de résoudre le problème :

• MIC AP - Demandez une autorisation de matériaux de retour (RMA).

• LSC AP au sujet de disposition votre certificat LSC

Problème 5 : Le contrôleur reçoit le message de détection de l'AP sur le VLAN incorrect (vous voyez le débogage de message de détection, mais pas de réponse)

Vous voyez ce message dans les événements de capwap de débogage activer la sortie de commande :

Received a Discovery Request with subnet broadcast with wrong AP IP address (A.B.C.D)!

Ce message signifie que le contrôleur a reçu une demande de détection via une adresse IP de diffusion qui a une adresse IP source, laquelle n'est dans aucun sous-réseau configuré sur le contrôleur. Cela signifie également que le contrôleur supprime le paquet.

Le problème est que l'AP n'envoie pas la demande de détection à l'adresse IP de gestion. Le contrôleur signale une demande de détection de diffusion à partir d'un VLAN qui n'est pas configuré sur le contrôleur. Cela se produit généralement quand le client effectue une agrégation de tous les VLAN autorisés au lieu de les restreindre aux VLAN sans fil.

Complétez les étapes suivantes pour résoudre ce problème :

1. Si le contrôleur se trouve sur un autre sous-réseau, les AP doivent faire l'objet d'un priming pour l'adresse IP des contrôleurs, ou les AP doivent recevoir l'adresse IP des contrôleurs en utilisant n'importe laquelle des méthodes de détection.

2. Le commutateur est configuré pour autorisé certains VLAN qui ne se trouvent pas sur le contrôleur. Restreignez les VLAN autorisés sur les agrégations.

Problème 6 : L'AP ne peut pas joindre le WLC, car le pare-feu bloque des ports nécessaires

Si un pare-feu est utilisé dans le réseau d'entreprise, assurez-vous que les ports suivants sont activés sur le pare-feu pour que le LAP puisse joindre le contrôleur et communiquer avec lui.

Vous devez activer les ports suivants :

• Activez ces ports UDP pour le trafic CAPWAP :

  • Données - 5247

  • Contrôle - 5246

• Activez les ports UDP suivants pour le trafic de mobilité :

  • 16666 - 16666

  • 16667 - 16667

• Activez les ports UDP 5246 et 5247 pour le trafic CAPWAP.

• TCP 161 et 162 pour SNMP (pour le système de contrôle sans fil [WCS])

Les ports suivants sont facultatifs (selon vos besoins) :

• UDP 69 pour TFTP

• TCP 80 et/ou 443 pour le HTTP ou HTTPS pour l'accès à la GUI

• TCP 23 et/ou 22 pour Telnet ou SSH pour l'accès à la CLI

Problème 7 : Adresse IP en double dans le réseau

C'est un autre problème fréquent qui est constaté quand l'AP essaye de joindre le WLC. Le message d'erreur suivant peut s'afficher quand l'AP essaie de joindre le contrôleur.

No more AP manager IP addresses remain

Une des raisons pour lesquelles ce message d'erreur apparaît est qu'il y a une adresse IP en double sur le réseau qui correspond à l'adresse IP du gestionnaire d'AP. En pareil cas, le LAP se met sans cesse hors tension et ne peut pas joindre le contrôleur.

Les débogages montreront que le WLC reçoit des demandes de détection LWAPP des AP et qu'il transmet une réponse de détection LWAPP aux AP. Cependant, les WLC ne reçoivent pas les demandes de jointure LWAPP en provenance des AP.

Afin de résoudre ce problème, effectuez un test Ping sur le gestionnaire d'AP à partir d'un hôte câblé sur le même sous-réseau IP que le gestionnaire d'AP. Vérifiez ensuite le cache ARP. Si une adresse IP en double est trouvée, supprimez le périphérique avec l'adresse IP en double ou modifiez l'adresse IP sur le périphérique de sorte qu'il ait une adresse IP unique sur le réseau.

L'AP peut alors joindre le WLC.

Problème 8 : Recouvrements avec l'image de maille non capable joindre WLC

Le point d'accès léger ne s'inscrit pas au WLC. Le log affiche ceci le message d'erreur

AAA Authentication Failure for UserName:5475xxx8bf9c User
	 Type: WLAN USER

Ceci peut se produire si le point d'accès léger était expédié avec une image de maille et est en mode de passerelle. Si le RECOUVREMENT était commandé avec le logiciel de maille là-dessus, vous devez ajouter le RECOUVREMENT à la liste d'autorisation AP. Choisissez le Security > AP Policies et ajoutez AP à la liste d'autorisation. AP devrait alors joindre, télécharger l'image à partir du contrôleur, puis de l'inscription au WLC en mode de passerelle. Alors vous devez changer AP au mode local. Le RECOUVREMENT télécharge l'image, les réinitialisations et les registres de nouveau au contrôleur en mode local.

Problème 9 : Mauvaise adresse « DHCP de Microsoft ».

Les Points d'accès peuvent renouveler leurs adresses IP assez rapidement en essayant pour joindre un WLC, qui peut faire marquer des serveurs DHCP de Windows ces IPS en tant que « BAD_ADDRESS » qui pourrait rapidement épuiser le pool DHCP.

Vérifiez plus d'informations : https://www.cisco.com/c/en/us/td/docs/wireless/controller/8-2/config-guide/b_cg82/b_cg82_chapter_0101000.html#dhcp-release-override-on-aps