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

Conditions requises

Cisco vous recommande de prendre connaissance des rubriques suivantes :

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

• Connaissances de base du protocole CAPWAP (Lightweight Access Point Protocol)

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 pose une question : comment les LAP ont-ils trouvé l'adresse IP de gestion du contrôleur lorsqu'il se trouve sur un sous-réseau différent ?

Si vous ne dites pas au LAP où se trouve le contrôleur via l'option DHCP 43, la résolution DNS de « Cisco-capwap-controller.local_domain », ou si vous ne le configurez pas de manière statique, le LAP 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 LAP se connectent toujours à l'adresse de l'interface de gestion du contrôleur d'abord avec une demande de détection. Le contrôleur indique ensuite au LAP l'interface du gestionnaire AP de couche 3 (qui peut également être l'adresse IP de gestion par défaut)afin que le LAP puisse envoyer une demande de jointure à l'interface du gestionnaire AP suivante.

Le point d'accès suit ce processus au démarrage :

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 existe 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 présents dans le groupe de mobilité du WLC le point d'accès a rejoint la dernière

   À partir de cette liste, la méthode la plus simple à utiliser pour le déploiement est d'avoir les LAP sur le même sous-réseau que l'interface de gestion du contrôleur et de permettre à la diffusion de couche 3 des LAP de 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 configurer de manière statique les informations nécessaires pour rejoindre un contrôleur via le port de console et l'interface de ligne de commande des points d'accès. Pour plus d'informations sur la configuration statique des informations de contrôleur à l'aide de l'interface de ligne de commande du point d'accès, utilisez la commande suivante :

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

   Pour plus d'informations sur la configuration de l'option DHCP 43 sur un serveur DHCP, reportez-vous à l'exemple de configuration de l'option DHCP 43

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.

• debug capwap events enable - ” Affiche les paquets de détection et de jointure.

• debug capwap packet enable†” Affiche les informations de niveau paquet des paquets de détection et de jointure.

• debug pm pki enable†” Affiche le processus de validation du certificat.

• debug disable-all†” Désactive les 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  
       
    (in xx:xx:xx:xx:xx format)
    debug client  
       

    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.

debug capwap events enable

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

Il s'agit de la sortie de commande debug capwap events enable pour un LAP qui a la même image que celle du WLC :

Remarque : Certaines lignes du résultat ont été déplacées vers 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 la sortie de commande debug capwap events enable si le LAP télécharge une image à partir du contrôleur dans le cadre du processus 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.

Lorsque le point d'accès envoie la demande de connexion CAPWAP au WLC, il incorpore son certificat X.509 dans le message CAPWAP. Le point d'accès génère également un ID de session aléatoire qui est également inclus dans la demande de jointure CAPWAP. Lorsque le WLC reçoit la demande de connexion CAPWAP, il valide la signature du certificat X.509 à l'aide de la clé publique du point d'accès et vérifie que le certificat a été émis par une autorité de certification de confiance.

Il examine également la date et l'heure de début de l'intervalle de validité du certificat AP et compare cette date et cette heure à sa propre date et heure (d'où la valeur de l'horloge du contrôleur doit être proche de la date et de l'heure actuelles). Si le certificat X.509 est validé, le WLC génère une clé de chiffrement AES aléatoire. Le WLC plonge la clé AES dans son moteur de chiffrement afin de pouvoir chiffrer et déchiffrer les futurs messages de contrôle CAPWAP échangés avec le point d'accès. Notez que les paquets de données sont envoyés en clair dans le tunnel CAPWAP entre le LAP 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 points d'accès fabriqués après juin 2006 ont une carte 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 du résultat ont été déplacées vers 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éboguer à partir du point d'accès

Si les débogages du contrôleur n'indiquent pas de demande de jointure, vous pouvez déboguer le processus à partir de l'AP tant que l'AP a un port de console.  Vous pouvez voir le processus de démarrage de l'AP avec ces commandes, mais vous devez d'abord passer en mode enable (le mot de passe par défaut est Cisco) :

• debug dhcp detail : Affiche les informations de l'option DHCP 43.

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

• debug capwap client event : Affiche les événements capwap pour le point d'accès.

• debug capwap client error : Affiche les erreurs capwap pour AP.
• debug dtls client event : Affiche les événements DTLS pour l'AP.
• debug dtls error enable : Affiche les erreurs DTLS pour l'AP.

• undebug all : Désactive les débogages sur l'AP.

Voici un exemple des résultats des commandes debug capwap. Cette sortie partielle donne une idée des paquets qui sont envoyés par le point d'accès 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 que le point d'accès reçoit une adresse de DHCP (vérifiez l'adresse MAC du point d'accès dans les baux du serveur DHCP).

• 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 : FN - 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.  Émettez les commandes debug dtls client error + debug dtls client event sur l'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. L'heure du contrôleur doit être définie de telle manière qu'elle se trouve dans l'intervalle de validité du certificat du point d'accès.

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 Commandes > Définir l'heure en mode GUI du contrôleur, ou émettez la commande config time dans l'interface CLI du contrôleur afin de définir l'heure du contrôleur.

3. Sur les points d'accès avec accès CLI, vérifiez les certificats avec la commande show crypto ca certificate à partir de l'interface CLI de l'AP.

   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. reportez-vous à CSCuq19142 L'expiration de la durée de vie de la MIC LAP/WLC ou de la SSC entraîne l'échec de DTLS :

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

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

Ce message apparaît dans la sortie de commande debug capwap events enable :

*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. Le WLC prend en charge plusieurs domaines réglementaires, mais chaque domaine réglementaire doit être sélectionné avant qu'un point d'accès puisse se joindre à partir 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.). Lorsque vous achetez des points d'accès , 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 : Les radios 802.1b/g et 802.11a doivent être dans le même domaine réglementaire pour un point d'accès unique.

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

Dans de tels cas, vous verrez ce message sur le contrôleur dans la sortie de la commande debug capwap events enable :

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 LAP qui a un port de console, ce message s'affiche lorsque vous émettez la commande debug 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.

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 debug capwap errors enable et debug pm pki enable. Vous voyez des messages qui indiquent que des certificats ou des clés sont altérés.

Remarque : Certaines lignes du résultat ont été déplacées vers les lignes secondaires 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 :

• Point d'accès MIC - Demander une autorisation de retour de matériel (RMA).

• Point d'accès LSC - Réapprovisionner 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)

Ce message apparaît dans la sortie de commande debug capwap events enable :

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 : Les LAP avec image maillée ne peuvent pas joindre le WLC

Le point d'accès léger ne s'enregistre pas auprès du WLC. Le journal affiche ce message d'erreur

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

Cela peut se produire si le point d'accès léger a été livré avec une image maillée et est en mode Pont. Si le LAP a été commandé avec un logiciel de maillage dessus, vous devez ajouter le LAP à la liste d'autorisation du point d'accès. Choisissez Security > AP Policies et ajoutez AP à la liste d'autorisations. Le point d'accès doit alors se joindre, télécharger l'image à partir du contrôleur, puis s'inscrire auprès du WLC en mode pont. Ensuite, vous devez changer l'AP en mode local. Le LAP télécharge l'image, redémarre et s'enregistre à nouveau sur le contrôleur en mode local.

Problème 9 : Adresse incorrecte « DHCP Microsoft ».

Les points d'accès peuvent renouveler leurs adresses IP assez rapidement lors d'une tentative de connexion à un WLC, ce qui peut faire que les serveurs DHCP Windows marquent ces adresses IP comme « BAD_ADDRESS », ce qui pourrait rapidement affaiblir le pool DHCP.

Pour 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