Dépannage de la dissociation du point d'accès du contrôleur

Introduction

Ce document décrit des cas d'utilisation pour comprendre les ruptures de tunnel CAPWAP/LWAPP entre les points d'accès (AP) et le contrôleur LAN sans fil (WLC).

Conditions préalables

Exigences 

Cisco vous recommande de prendre connaissance des rubriques suivantes :

• Configuration des points d'accès (AP) et du contrôleur LAN sans fil (WLC)
• Routage et commutation.
• Contrôle et mise en service des points d'accès sans fil (CAPWAP)
• Protocole LWAPP (Lightweight Access Point Protocol)

Composants utilisés

Ce document n'est pas limité à des versions de matériel et de logiciel spécifiques.

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. Si votre réseau est en ligne, assurez-vous de bien comprendre l’incidence possible des commandes.

Informations générales

Ce document décrit des cas d'utilisation pour comprendre la raison de la rupture de tunnel Control and Provisioning of Wireless Access Points (CAPWAP)/Lightweight Access Point Protocol (LWAPP) entre les points d'accès (AP) et le contrôleur LAN sans fil (WLC).

Processus d'enregistrement des points d'accès basés sur contrôleur

Les AP passent par le processus mentionné pour s'enregistrer auprès du contrôleur :

1. Demande de message de détection CAPWAP au WLC à partir des AP.
2. Message de réponse de détection du WLC aux AP.
3. Les AP choisissent le WLC à joindre en fonction de la réponse CAPWAP reçue.
4. Requête de jonction envoyée au WLC à partir des AP.
5. Le contrôleur valide les AP et envoie la réponse de jonction.

Journaux capturés sur les AP lors de l'enregistrement avec WLC :

Press RETURN to get started!

Translating "CISCO-CAPWAP-CONTROLLER"...domain server (255.255.255.255)

<Date & time> %CAPWAP-5-CHANGED: CAPWAP changed state to DISCOVERY

<Date & time>  status of voice_diag_test from WLC is false

<Date & time> %SSH-5-ENABLED: SSH 2.0 has been enabled

<Date & time> Logging LWAPP message to 255.255.255.255.

<Date & time> %CDP_PD-4-POWER_OK: 15.4 W power - NEGOTIATED inline power source

<Date & time> %LINK-3-UPDOWN: Interface Dot11Radio1, changed state to up

<Date & time> %LINK-3-UPDOWN: Interface Dot11Radio0, changed state to up

<Date & time> %LINEPROTO-5-UPDOWN: Line protocol on Interface Dot11Radio1, changed state to up

<Date & time> %SYS-6-LOGGINGHOST_STARTSTOP: Logging to host 255.255.255.255 started - CLI initiated

<Date & time> %LINEPROTO-5-UPDOWN: Line protocol on Interface Dot11Radio0, changed state to up

Translating "CISCO-LWAPP-CONTROLLER"...domain server (255.255.255.255)

Translating "CISCO-CAPWAP-CONTROLLER"...domain server (255.255.255.255)

<Date & time> %CAPWAP-5-DTLSREQSEND: DTLS connection request sent peer_ip: <controller IP> peer_port: 5246

<Date & time> %CAPWAP-5-CHANGED: CAPWAP changed state to 

<Date & time> %CAPWAP-5-DTLSREQSUCC: DTLS connection created sucessfully peer_ip: <controller IP> peer_port: 5246

<Date & time> %CAPWAP-5-SENDJOIN: sending Join Request to <controller IP>

<Date & time> %CAPWAP-5-CHANGED: CAPWAP changed state to JOIN

<Date & time> %CAPWAP-5-CHANGED: CAPWAP changed state to CFG

<Date & time> %LWAPP-3-CLIENTERRORLOG: Operator changed mode for 802.11g. Rebooting.

<Date & time> %LINK-5-CHANGED: Interface Dot11Radio0, changed state to administratively down

<Date & time> %SYS-5-RELOAD: Reload requested by CAPWAP CLIENT. Reload Reason: Operator changed mode for 802.11g.

<Date & time> %LINEPROTO-5-UPDOWN: Line protocol on Interface Dot11Radio0, changed state to down

IOS Bootloader - Starting system.

Cas d'utilisation 1

1. Les AP sont dissociés du WLC et lorsqu'ils sont vérifiés à partir du commutateur, cela montre que les AP n'ont pas d'IP.

Journaux lorsqu'ils sont connectés aux points d'accès :

<Date & time>  LINEPROTO-5-UPDOWN: Line protocol on Interface Dot11Radio0, changed state to up

<Date & time>  %CAPWAP-3-ERRORLOG: Not sending discovery request AP does not have an Ip !!

Solution : 

Corrigez les problèmes d'accessibilité à l'adresse IP helper configurée sous le VLAN si le serveur DHCP est situé à distance. Si le DHCP est configuré localement, assurez-vous qu'il n'y a pas de conflit DHCP. Configurez l'adresse IP statique sur les points d'accès :

Connectez-vous aux points d'accès et tapez ces commandes :

capwap ap ip address <ip> <mask>

capwap ap ip default-gateway <ip> 

Vous pouvez également spécifier l'adresse IP du contrôleur :

capwap ap controller ip address <ip>

2. Notez qu’il existe des points d’accès avec des adresses IP, mais l’échec de la communication avec le WLC peut être une défaillance de résolution de l’IP du contrôleur.

Journaux des points d'accès avec un problème où la résolution DNS (Domain Name System) a échoué :

<Date & time>  %CAPWAP-3-ERRORLOG: Could Not resolve CISCO-CAPWAP-CONTROLLER.local doamin

Not in Bound state.

Solution :

Vérifiez l'accessibilité du serveur DNS interne, si elle est acceptable, assurez-vous que les adresses IP du contrôleur transmises via DHCP sont accessibles.

Break-fix : configurez manuellement le contrôleur sur les AP. 

"capwap ap {primary-base | secondary-base | tertiary-base}controller-name controller-ip-address"

3. Vous voyez que les points d'accès sont enregistrés sur le contrôleur et vous ne voyez toujours aucune diffusion de l'identifiant SSID (Service Set Identifier) requis.

(4402-d) >config wlan apgroup interface-mapping add <ap group name> <wlandi> <interfacename>

Solution :
Ajoutez le réseau local sans fil (WLAN) sous le groupe AP.

Cas d'utilisation 2

Notez que les points d'accès ne sont pas visibles sur le voisin CDP (Cisco Discovery Protocol) du commutateur, et que le commutateur connecté aux points d'accès est dans un état d'erreur désactivée. 

Journaux capturés à partir du commutateur :

Dec  9 08:42:35.836 UTC: RSTP(10): sending BPDU out Te3/0/47STP: pak->vlan_id: 10 Dec  9 08:42:35.836 UTC: %PM-4-ERR_DISABLE: bpduguard error detected on Te3/0/47, putting Te3/0/47 in err-disable stateSTP: pak->vlan_id: 1 Dec  9 09:47:32.651 UTC: %ILPOWER-5-DETECT: Interface Te3/0/47: Power Device detected: IEEE PD Dec  9 09:47:33.651 UTC: %ILPOWER-5-POWER_GRANTED: Interface Te3/0/47: Power granted Dec  9 09:47:53.545 UTC: %PM-4-ERR_DISABLE: bpduguard error detected on Te3/0/47, putting Te3/0/47 in err-disable state Dec  9 09:48:10.955 UTC: %ILPOWER-5-DETECT: Interface Te3/0/47: Power Device detected: IEEE PD Dec  9 09:48:11.955 UTC: %ILPOWER-5-POWER_GRANTED: Interface Te3/0/47: Power granted Dec  9 09:48:32.114 UTC: %PM-4-ERR_DISABLE: bpduguard error detected on Te3/0/47, putting Te3/0/47 in err-disable state

Solution :
Les points d’accès n’envoient pas la protection BPDU (Bridge Protocol Data Unit) en aucun cas, c’est un problème du côté du commutateur. Déplacez les points d'accès vers un autre port libre et répliquez la configuration d'interface avec les vérifications physiques nécessaires.

Cas d'utilisation 3

Dans la configuration des bureaux distants, vous voyez souvent le tunnel CAPWAP se démonter de manière aléatoire entre les points d'accès et le contrôleur et les paramètres les plus importants à vérifier sont la retransmission et l'intervalle entre les tentatives.

Les AP retransmit interval et retry interval peuvent être configurés à la fois au niveau global et au niveau des AP. Une configuration globale applique ces paramètres de configuration à tous les AP. En d'autres termes, l'intervalle de retransmission et le nombre de tentatives sont uniformes pour tous les points d'accès.

Journaux problématiques du WLC :

 *spamApTask6: Jun 01 17:17:55.426: %LWAPP-3-AP_DEL: spam_lrad.c:6088 1c:d1:e0:43:1d:20: Entry deleted for AP: 10.209.36.5 (5256) reason : AP Message Timeout. *spamApTask6: Jun 01 17:17:55.426: %CAPWAP-4-INVALID_STATE_EVENT: capwap_ac_sm.c:9292 The system detects an invalid AP(1c:d1:e0:43:1d:20) event (Capwap_configuration_update_request) and state (Capwap_dtls_teardown) combination -Traceback: 0xe69bba3a5f 0xe69b9b9446 0xe69bdc5e3b 0xe69b8f238c 0xe69bbaf33b 0xe69cc8041b 0xe69c71df97 0x7fef39282dff 0x7fef3869f98d *spamReceiveTask: Jun 01 17:17:55.426: %CAPWAP-4-INVALID_STATE_EVENT: capwap_ac_sm.c:9292 The system detects an invalid AP(1c:d1:e0:43:1d:20) event (Capwap_configuration_update_request) and state (Capwap_dtls_teardown) combination -Traceback: 0xe69bba3a5f 0xe69b981950 0xe69b76dd5c 0xe69cc757c2 0xe69c71df97 0x7fef39282dff 0x7fef3869f98d *spamApTask5: Jun 01 17:17:55.424: %CAPWAP-3-DTLS_CLOSED_ERR: capwap_ac_sm.c:7521 1c:d1:e0:43:1d:20: DTLS connection closed forAP 10:209:36:5 (5256), Controller: 10:176:92:53 (5246) AP Message Timeout *spamApTask5: Jun 01 17:17:55.423: %CAPWAP-3-MAX_RETRANSMISSIONS_REACHED: capwap_ac_sm.c:8073 Max retransmissions reached on AP(1c:d1:e0:43:1d:20),message (CAPWAP_CONFIGURATION_UPDATE_REQUEST ),number of pending messages(2)

Solution : si le problème concerne tous les sites, augmentez la Retransmit count et Retransmit interval sous la configuration globale sans fil. Option permettant d'augmenter les valeurs lorsque le problème concerne tous les AP.

Option de modification des paramètres de configuration de retransmission AP sous configuration globale

Si le problème est spécifique à un site distant, une augmentation de Retransmit count et Retransmit interval sur un AP particulier corrige le problème.

Possibilité de modifier le paramètre de configuration de retransmission AP sous un AP spécifique

Cas d'utilisation 4

Les AP sont complètement dissociés du WLC et ne peuvent pas rejoindre le contrôleur. Cela pourrait être lié aux certificats numériques.

Quelques faits rapides sur les certificats de périphérique en termes de WLC et AP Cisco :

•   Chaque périphérique qui sort de Cisco est livré avec un certificat par défaut avec une validité de 10 ans.
•   Ce certificat est utilisé pour effectuer l'authentification entre le WLC Cisco et les points d'accès.
•   Avec l'aide de certificats, les points d'accès et le WLC établissent un tunnel DTLS (Datagram Transport Layer Security) sécurisé.

Deux types de problèmes liés aux certificats ont été rencontrés :

Problème 1 : les AP plus anciens (ne veut pas rejoindre le WLC).

La console vers les points d'accès permet de déterminer le problème et les journaux se présentent comme suit :

*Sep 13 18:26:24.000: %CAPWAP-5-DTLSREQSEND: DTLS connection request sent peer_ip: 10.1.1.1 peer_port: 5246 *Sep 13 18:26:24.000: %CAPWAP-5-CHANGED: CAPWAP changed state to *Sep 13 18:26:24.099: %PKI-3-CERTIFICATE_INVALID_EXPIRED: Certificate chain validation has failed. The certificate (SN: XXXXXXXXXXXXXX) has expired. Validity period ended on 19:56:24 UTC Aug 12 2018 *Sep 13 18:26:24.099: %LWAPP-3-CLIENTERRORLOG: Peer certificate verification failed *Sep 13 18:26:24.099: %CAPWAP-3-ERRORLOG: Certificate verification failed!

Problème 2 : les AP plus récents ne veulent pas rejoindre un WLC plus ancien.
La console vers les AP donne une erreur qui pourrait ressembler à ceci :

[*09/09/2019 04:55:26.3299] CAPWAP State: DTLS Teardown [*09/09/2019 04:55:30.9385] CAPWAP State: Discovery [*09/09/2019 04:55:30.9385] Did not get log server settings from DHCP. [*09/09/2019 04:55:41.0000] CAPWAP State: DTLS Setup [*09/09/2019 04:55:41.3399] Bad certificate alert received from peer. [*09/09/2019 04:55:41.3399] DTLS: Received packet caused DTLS to close connection

Solution :

1. NTP désactive et définit l'heure manuellement via l'interface de ligne de commande :

(Cisco Controller)> config time ntp delete 1 (Cisco Controller)> config time manual 09/30/18 11:30:00

2. NTP désactive et définit l'heure manuellement via l'interface utilisateur graphique :

Emplacement de définition manuelle de l'heure sur l'interface utilisateur graphique

2. Désactivez le certificat installé par le fabricant (MIC) sur le contrôleur. Cette commande n'est acceptée que sur les dernières versions. 

(Cisco Controller)> config ap cert-expiry-ignore mic enable 

Informations connexes

• Assistance technique de Cisco et téléchargements