Dans le cadre de la documentation associée à ce produit, nous nous efforçons d’utiliser un langage exempt de préjugés. Dans cet ensemble de documents, le langage exempt de discrimination renvoie à une langue qui exclut la discrimination en fonction de l’âge, des handicaps, du genre, de l’appartenance raciale de l’identité ethnique, de l’orientation sexuelle, de la situation socio-économique et de l’intersectionnalité. Des exceptions peuvent s’appliquer dans les documents si le langage est codé en dur dans les interfaces utilisateurs du produit logiciel, si le langage utilisé est basé sur la documentation RFP ou si le langage utilisé provient d’un produit tiers référencé. Découvrez comment Cisco utilise le langage inclusif.
Cisco a traduit ce document en traduction automatisée vérifiée par une personne dans le cadre d’un service mondial permettant à nos utilisateurs d’obtenir le contenu d’assistance dans leur propre langue. Il convient cependant de noter que même la meilleure traduction automatisée ne sera pas aussi précise que celle fournie par un traducteur professionnel.
Ce document décrit en détail le processus de jonction AP avec le WLC Cisco Catalyst 9800.
Cisco vous recommande de prendre connaissance des rubriques suivantes :
Les informations contenues dans ce document sont basées sur les versions de matériel et de logiciel suivantes :
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.
Le protocole CAPWAP (Control And Provisioning Wireless Access Point) est le protocole qui fournit le mécanisme de transport utilisé par les points d'accès (AP) et les contrôleurs LAN sans fil (WLC) pour échanger des informations de contrôle et de plan de données sur un tunnel de communication sécurisé (pour le contrôle CAPWAP).
Afin d'élaborer sur le processus de jointure de point d'accès, il est important que vous compreniez le processus d'établissement de session de point d'accès sans fil de contrôle et de mise en service (CAPWAP).
Gardez à l'esprit que le point d'accès doit avoir une adresse IP avant de pouvoir démarrer le processus CAPWAP. Si le point d'accès n'a pas d'adresse IP, il ne lance pas le processus d'établissement de session CAPWAP.
Remarque : conformément à la RFC 5415, CAPWAP utilise les ports UDP 5246 (pour le contrôle CAPWAP) et 5247 (pour les données CAPWAP).
Une fois que le point d'accès reçoit une réponse de détection valide du WLC, un tunnel DTLS est établi entre eux pour transmettre tous les paquets suivants sur un tunnel sécurisé. Il s'agit du processus d'établissement de la session DTLS :
Après le dernier message ChangedCipherSpec envoyé par le WLC, le tunnel sécurisé est établi et tout le trafic envoyé dans les deux directions est maintenant chiffré.
Il existe plusieurs options pour informer les points d'accès de l'existence d'un WLC dans le réseau :
capwap primary-base <wlc-hostname> <wlc-IP-address>
pour configurer une entrée statique pour un WLC dans le point d'accès.
- Découverte de mobilité : si l'AP a été précédemment joint à un WLC qui faisait partie d'un groupe de mobilité, l'AP enregistre également un enregistrement des WLC présents dans ce groupe de mobilité.
Remarque : les méthodes de détection WLC répertoriées n'ont pas d'ordre de priorité.
Choix du contrôleur LAN sans fil
Une fois que le point d'accès a reçu une réponse de détection de n'importe quel WLC utilisant l'une des méthodes de détection de WLC, il sélectionne un contrôleur à joindre avec ce critère :
- Contrôleur principal (configuré avec la commande capwap primary-base <wlc-hostname> <wlc-IP-address> )
- Contrôleur secondaire (configuré avec la commande capwap secondary-base <wlc-hostname> <wlc-IP-address> )
- Tertiary Controller (configuré avec la commande capwap tertiary-base <wlc-hostname> <wlc-IP-address>)
- Si aucun WLC primaire, secondaire ou tertiaire n'a été configuré précédemment, alors l'AP tente de joindre le premier WLC qui a répondu à la demande de détection avec sa propre réponse de détection qui a la capacité maximale des AP disponibles (c'est-à-dire, le WLC qui peut prendre en charge le plus d'AP à un moment donné).
Machine d'état CAPWAP
Dans la console AP, vous pouvez suivre la machine d'état CAPWAP, qui passe en revue les étapes décrites dans la section Établissement de session CAPWAP.
État CAPWAP : Détection
Ici, vous pouvez voir les demandes et les réponses de détection. Observez comment l'AP reçoit une IP de WLC via DHCP (Option 43), et envoie également une requête de découverte aux WLC connus précédemment :
[*09/14/2023 04:12:09.7740] CAPWAP State: Init
[*09/14/2023 04:12:09.7770]
[*09/14/2023 04:12:09.7770] CAPWAP State: Discovery
[*09/14/2023 04:12:09.7790] Discovery Request sent to 172.16.0.20, discovery type STATIC_CONFIG(1)
[*09/14/2023 04:12:09.7800] Discovery Request sent to 172.16.5.11, discovery type STATIC_CONFIG(1)
[*09/14/2023 04:12:09.7800] Got WLC address 172.16.5.11 from DHCP.
[*09/14/2023 04:12:09.7820] Discovery Request sent to 172.16.0.20, discovery type STATIC_CONFIG(1)
[*09/14/2023 04:12:09.7830] Discovery Request sent to 172.16.5.11, discovery type STATIC_CONFIG(1)
[*09/14/2023 04:12:09.7840] Discovery Request sent to 255.255.255.255, discovery type UNKNOWN(0)
[*09/14/2023 04:12:09.7850]
[*09/14/2023 04:12:09.7850] CAPWAP State: Discovery
[*09/14/2023 04:12:09.7850] Discovery Response from 172.16.0.20
[*09/14/2023 04:12:09.8030] Discovery Response from 172.16.5.11
[*09/14/2023 04:12:09.8060] Discovery Response from 172.16.0.20
[*09/14/2023 04:12:09.8060] Discovery Response from 172.16.5.11
[*09/14/2023 04:12:09.8060] Discovery Response from 172.16.5.11
[*09/14/2023 04:12:09.8060] Discovery Response from 172.16.0.20
[*09/14/2023 04:12:09.8060] Discovery Response from 172.16.5.169
[*09/14/2023 04:12:09.8060] Discovery Response from 172.16.5.169
En plus de la réception d'une réponse de détection à la fois d'un WLC configuré statiquement (172.16.0.20) et du WLC indiqué via l'option DHCP 43 (172.16.5.11), cet AP a également reçu une réponse de détection d'un autre WLC (172.16.5.169) dans le même sous-réseau parce qu'il a reçu le message de détection de diffusion.
État CAPWAP : configuration DTLS.
Ici, la session DTLS entre l'AP et le WLC est échangée.
[*09/27/2023 21:50:41.0000] CAPWAP State: DTLS Setup
[*09/27/2023 21:50:41.7140] sudi99_request_check_and_load: Use HARSA SUDI certificat
État CAPWAP : Rejoindre
Après avoir établi la session DTLS, une demande de jonction au WLC est maintenant envoyée sur la session sécurisée. Observez comment cette demande reçoit immédiatement une réponse Join Response du WLC
[*09/27/2023 21:50:41.9880] CAPWAP State: Join
[*09/27/2023 21:50:41.9910] Sending Join request to 172.16.5.11 through port 5270
[*09/27/2023 21:50:41.9950] Join Response from 172.16.5.11
[*09/27/2023 21:50:41.9950] AC accepted join request with result code: 0
[*09/27/2023 21:50:41.9990] Received wlcType 0, timer 30
[*09/27/2023 21:50:41.9990] TLV ID 2216 not found
[*09/27/2023 21:50:41.9990] TLV-DEC-ERR-1: No proc for 2216
État CAPWAP : données d'image
L'AP compare son image avec l'image du WLC. Dans ce cas, à la fois la partition active de l'AP et sa partition de sauvegarde ont des images différentes du WLC, de sorte qu'il appelle le script upgrade.sh, qui demande à l'AP de demander l'image adéquate au WLC et de la télécharger dans sa partition non active actuelle.
[*09/27/2023 21:50:42.0430] CAPWAP State: Image Data
[*09/27/2023 21:50:42.0430] AP image version 8.10.185.0 backup 8.10.105.0, Controller 17.9.3.50
[*09/27/2023 21:50:42.0430] Version does not match.
[*09/27/2023 21:50:42.0680] upgrade.sh: Script called with args:[PRECHECK]
[*09/27/2023 21:50:42.1060] do PRECHECK, part2 is active part
[*09/27/2023 21:50:42.1240] upgrade.sh: /tmp space: OK available 101476, required 40000
[*09/27/2023 21:50:42.1250] wtpImgFileReadRequest: request ap1g7, local /tmp/part.tar
[*09/27/2023 21:50:42.1310] Image Data Request sent to 172.16.5.11, fileName [ap1g7], slaveStatus 0
[*09/27/2023 21:50:42.1340] Image Data Response from 172.16.5.11
[*09/27/2023 21:50:42.1340] AC accepted join request with result code: 0
[*09/27/2023 21:50:42.1450] <..................................................
[*09/27/2023 21:50:55.4980] ..................................................
[*09/27/2023 21:51:11.6290] ...............................Discarding msg CAPWAP_WTP_EVENT_REQUEST(type 9) in CAPWAP state: Image Data(10).
[*09/27/2023 21:51:19.7220] ...................
[*09/27/2023 21:51:24.6880] ..................................................
[*09/27/2023 21:51:37.7790] ..................................................
[*09/27/2023 21:51:50.9440] ...................................> 76738560 bytes, 57055 msgs, 930 last
[*09/27/2023 21:51:59.9160] Last block stored, IsPre 0, WriteTaskId 0
[*09/27/2023 21:51:59.9160] Image transfer completed from WLC, last 1
Une fois le transfert d'image terminé, le point d'accès lance un processus de vérification de signature d'image pour le valider. Après cela, le script upgrade.sh installe l'image dans la partition non active actuelle, et échange la partition à partir de laquelle elle démarre. Enfin, l'AP se recharge et répète le processus depuis le début (CAPWAP State : Discover).
[*09/27/2023 21:52:01.1280] Image signing verify success.
[*09/27/2023 21:52:01.1440]
[*09/27/2023 21:52:01.1440] [9/27/2023 21:53:2] : Shadow is now in-synced with master
[*09/27/2023 21:52:01.1440]
[*09/27/2023 21:52:01.1440] [9/27/2023 21:53:2] : Verifying against bundle image btldr.img...
[*09/27/2023 21:52:01.1570] upgrade.sh: part to upgrade is part1
[*09/27/2023 21:52:01.1780] upgrade.sh: AP version1: part1 8.10.105.0, img 17.9.3.50
[*09/27/2023 21:52:01.1960] upgrade.sh: Extracting and verifying image in part1...
[*09/27/2023 21:52:01.2080] upgrade.sh: BOARD generic case execute
[*09/27/2023 21:52:01.5280] upgrade.sh: Untar /tmp/part.tar to /bootpart/part1...
[*09/27/2023 21:52:01.7890] upgrade.sh: Sync image to disk...
[*09/27/2023 21:52:31.4970] upgrade.sh: status 'Successfully verified image in part1.'
[*09/27/2023 21:52:32.5270] upgrade.sh: AP version2: part1 17.9.3.50, img 17.9.3.50
[*09/27/2023 21:52:32.5540] upgrade.sh: AP backup version: 17.9.3.50
[*09/27/2023 21:52:32.5700] upgrade.sh: Finished upgrade task.
[*09/27/2023 21:52:32.5840] upgrade.sh: Cleanup for do_upgrade...
[*09/27/2023 21:52:32.5970] upgrade.sh: /tmp/upgrade_in_progress cleaned
[*09/27/2023 21:52:32.6090] upgrade.sh: Cleanup tmp files ...
[*09/27/2023 21:52:32.6720] upgrade.sh: Script called with args:[ACTIVATE]
[*09/27/2023 21:52:32.7100] do ACTIVATE, part2 is active part
[*09/27/2023 21:52:32.7640] upgrade.sh: Verifying image signature in part1
[*09/27/2023 21:52:33.7730] upgrade.sh: status 'Successfully verified image in part1.'
[*09/27/2023 21:52:33.7850] upgrade.sh: activate part1, set BOOT to part1
[*09/27/2023 21:52:34.2940] upgrade.sh: AP primary version after reload: 17.9.3.50
[*09/27/2023 21:52:34.3070] upgrade.sh: AP backup version after reload: 8.10.185.0
[*09/27/2023 21:52:34.3190] upgrade.sh: Create after-upgrade.log
[*09/27/2023 21:52:37.3520] AP Rebooting: Reset Reason - Image Upgrade
Avertissement : les points d'accès de phase 1 risquent de ne pas pouvoir télécharger une nouvelle image en raison d'un certificat expiré. Veuillez consulter la notice de zone 72524 pour plus d'informations et lire attentivement le document d'assistance sur les échecs de téléchargement d'image AP IOS dus à l'expiration du certificat de signature d'image du 4 décembre 2022 (CSCwd80290) pour comprendre son impact et sa solution.
Une fois que l'AP se recharge et passe à nouveau par les états CAPWAP Discover et Join, pendant l'état Image Data, il détecte qu'il a maintenant l'image adéquate.
[*09/27/2023 21:56:13.7640] CAPWAP State: Image Data
[*09/27/2023 21:56:13.7650] AP image version 17.9.3.50 backup 8.10.185.0, Controller 17.9.3.50
[*09/27/2023 21:56:13.7650] Version is the same, do not need update.
[*09/27/2023 21:56:13.7650] status 'upgrade.sh: Script called with args:[NO_UPGRADE]'
[*09/27/2023 21:56:13.7850] do NO_UPGRADE, part1 is active part
État CAPWAP : configuration
Une fois que l'AP a validé qu'il a la même version que le WLC, il notifie ses configurations actuelles au WLC. En général, cela signifie que l'AP demande de maintenir ses configurations (si elles sont disponibles dans le WLC).
[*09/27/2023 21:56:14.8680] CAPWAP State: Configure
[*09/27/2023 21:56:15.8890] Telnet is not supported by AP, should not encode this payload
[*09/27/2023 21:56:15.8890] Radio [1] Administrative state DISABLED change to ENABLED
[*09/27/2023 21:56:16.0650] Radio [0] Administrative state DISABLED change to ENABLED
[*09/27/2023 21:56:16.0750] DOT11_CFG[1]: Starting radio 1
[*09/27/2023 21:56:16.1150] DOT11_DRV[1]: Start Radio1
[*09/27/2023 21:56:16.1160] DOT11_DRV[1]: set_channel Channel set to 36/20
[*09/27/2023 21:56:16.4380] Started Radio 1
[*09/27/2023 21:56:16.4880] DOT11_CFG[0]: Starting radio 0
[*09/27/2023 21:56:17.5220] DOT11_DRV[0]: Start Radio0
[*09/27/2023 21:56:16.5650] DOT11_DRV[0]: set_channel Channel set to 1/20
[*09/27/2023 21:56:16.5650] Started Radio 0
[*09/27/2023 21:56:16.5890] sensord psage_base init: RHB Sage base ptr a1030000
État CAPWAP : Exécuter
À ce stade, le point d'accès a rejoint le contrôleur. Pendant cet état, le WLC déclenche un mécanisme pour remplacer la configuration demandée par l'AP. Vous pouvez voir que l'AP obtient des configurations Radio et Credentials poussées, et il est également assigné à la balise de stratégie par défaut puisque le WLC n'avait aucune connaissance précédente de cet AP.
[*09/27/2023 21:56:17.4870] CAPWAP State: Run
[*09/27/2023 21:56:17.4870] AP has joined controller uwu-9800
[*09/27/2023 21:56:17.4940] DOT11_DRV[0]: set_channel Channel set to 1/20
[*09/27/2023 21:56:17.5440] sensord split_glue psage_base: RHB Sage base ptr a1030000
[*09/27/2023 21:56:17.6010] sensord split_glue sage_addr: RHB Sage base ptr a1030000
[*09/27/2023 21:56:17.6230] ptr a1030000
[*09/27/2023 21:56:17.6420] DOT11_DRV[0]: set_channel Channel set to 1/20
[*09/27/2023 21:56:17.8120] DOT11_DRV[1]: set_channel Channel set to 36/20
[*09/27/2023 21:56:17.9350] Previous AP mode is 0, change to 0
[*09/27/2023 21:56:18.0160] Current session mode: ssh, Configured: Telnet-No, SSH-Yes, Console-Yes
[*09/27/2023 21:56:18.1220] Current session mode: telnet, Configured: Telnet-No, SSH-Yes, Console-Yes
[*09/27/2023 21:56:18.1310] Current session mode: console, Configured: Telnet-No, SSH-Yes, Console-Yes
[*09/27/2023 21:56:18.1340] chpasswd: password for user changed
[*09/27/2023 21:56:18.1350] chpasswd: password for user changed
[*09/27/2023 21:56:18.1520] systemd[1]: Starting Cisco rsyslog client watcher...
[*09/27/2023 21:56:18.1610] Same LSC mode, no action needed
[*09/27/2023 21:56:18.1640] CLSM[00:00:00:00:00:00]: U3 Client RSSI Stats feature is deprecated; can no longer be enabled
[*09/27/2023 21:56:18.1720] systemd[1]: Stopping rsyslog client...
[*09/27/2023 21:56:18.2120] systemd[1]: Starting Cisco syslog service...
[*09/27/2023 21:56:18.2230] systemd[1]: Started Cisco syslog service.
[*09/27/2023 21:56:18.2410] systemd[1]: Started rsyslog client.
[*09/27/2023 21:56:18.2440] AP is in good condition, BLE is off
[*09/27/2023 21:56:18.2510] SET_SYS_COND_INTF: allow_usb state: 1 (up) condition
[*09/27/2023 21:56:18.2530] systemd[1]: Starting dhcpv6 client watcher...
[*09/27/2023 21:56:18.2530] systemd[1]: Stopping DHCPv6 client...
[*09/27/2023 21:56:18.2530] systemd[1]: Starting DHCPv6 client...
[*09/27/2023 21:56:18.2530] systemd[1]: Started DHCPv6 client.
[*09/27/2023 21:56:18.2530] systemd[1]: Started dhcpv6 client watcher.
[*09/27/2023 21:56:18.2560] Set radio 0 power 4 antenna mask 15
[*09/27/2023 21:56:18.2530] Set radio 1 power 4 antenna mask 15
[*09/27/2023 21:56:18.2530] Got WSA Server config TLVs
[*09/27/2023 21:56:18.2720] AP tag change to default-policy-tag
[*09/27/2023 21:56:18.2780] Chip flash OK
Configurer
Choix du WLC statique
Dans l'interface graphique utilisateur, vous pouvez aller à Configuration > Wireless > Access Points, sélectionnez un AP et accédez à l'onglet High Availability. Ici, vous pouvez configurer les WLC principal, secondaire et tertiaire, comme décrit dans la section Sélection du contrôleur LAN sans fil de ce document. Cette configuration est effectuée par point d'accès.
Remarque : à partir de Cisco IOS XE 17.9.2, vous pouvez utiliser les profils d'amorçage pour configurer des contrôleurs principaux, secondaires et tertiaires pour un groupe d'AP correspondant à une expression régulière (regex) ou pour un AP individuel. Référez-vous à la section AP Fallback to Controllers Configured Under AP Priming Profile du Guide de configuration pour plus d'informations.
Veuillez noter que les contrôleurs principal, secondaire et tertiaire configurés dans l'onglet AP High Availability diffèrent des WLC principaux et secondaires de sauvegarde qui peuvent être configurés par AP Join Profile sous l'onglet CAPWAP > High Availability. Les contrôleurs principal, secondaire et tertiaire sont considérés comme des WLC avec les priorités 1, 2 et 3, respectivement, tandis que les contrôleurs principal et secondaire de secours sont considérés comme des WLC avec les priorités 4 et 5.
Si AP Fallback est activé, l'AP recherche activement le contrôleur principal lorsqu'il est joint à un autre WLC. Le point d'accès recherche uniquement les WLC avec les priorités 4 et 5 une fois qu'il y a un événement CAPWAP Down et aucun des contrôleurs principal et secondaire de secours n'est disponible.
Remarque : la configuration des WLC principal et secondaire de sauvegarde dans le profil de jonction AP ne remplit pas les entrées principal statique et secondaire dans l'onglet Haute disponibilité du point d'accès.
Activation de l'accès Telnet/SSH au point d'accès
Accédez à Configuration > Tags & Profiles > AP Join > Management > Device et sélectionnez SSH et/ou Telnet.
Pour configurer les informations d'identification SSH/Telnet, accédez à l'onglet User dans la même fenêtre et définissez le nom d'utilisateur, le mot de passe et le secret pour accéder à l'AP.
Chiffrement de liaison de données
Si vous avez besoin de dépanner un problème client qui vous oblige à prendre une capture de paquet du trafic de l'AP, assurez-vous que le cryptage de liaison de données n'est pas activé sous Configuration > Tags & Profiles > AP Join > CAPWAP > Advanced. Sinon, votre trafic est chiffré.
Remarque : le chiffrement des données chiffre uniquement le trafic de données CAPWAP. Le trafic de contrôle CAPWAP est déjà chiffré via DTLS.
Vérifier
En plus du suivi de la machine d'état CAPWAP dans la console de l'AP, vous pouvez également prendre une capture de paquets incorporée dans le WLC pour analyser le processus de jointure de l'AP :
Notez que tout le trafic après le paquet Chance Cipher Spec (paquet n° 1182) est affiché uniquement sous forme de données d'application sur DTLSv1.2. Il s'agit de toutes les données chiffrées après l'établissement de la session DTLS.
Dépannage
Problèmes identifiés
Veuillez vous reporter aux problèmes connus qui pourraient empêcher vos AP de rejoindre le WLC.
- Points d'accès sur la boucle de démarrage en raison d'une image corrompue dans les points d'accès Wave 2 et Catalyst 11ax (CSCvx32806)
- Avis de zone 72424 : Les points d'accès C9105/C9120/C9130 fabriqués à partir de septembre 2022 peuvent nécessiter des mises à niveau logicielles pour rejoindre les contrôleurs LAN sans fil.
- Avis de champ 72524 : pendant la mise à niveau/rétrogradation du logiciel, les points d'accès Cisco IOS peuvent rester à l'état de téléchargement après le 4 décembre 2022 en raison de l'expiration du certificat - Mise à niveau du logiciel recommandée
- ID de bogue Cisco CSCwb13784 : les points d'accès ne peuvent pas joindre 9800 en raison d'un MTU de chemin non valide dans la demande de jointure AP
- ID de bogue Cisco CSCvu22886 : C9130 : message "unlzma: write: No space left on device" on upgrade to 17.7 Augmenter la taille maximale de /tmp
Consultez toujours la section Chemin de mise à niveau des Notes de publication de chaque version avant de procéder à la mise à niveau.
Remarque : à partir de Cisco IOS XE Cupertino 17.7.1, le contrôleur sans fil Cisco Catalyst 9800-CL n'accepte pas plus de 50 points d'accès si la licence Smart n'est pas connectée et activée.
Vérifications de GUI WLC
Sur votre WLC, accédez à Monitoring > Wireless > AP Statistics > Join Statistics vous pouvez voir la Dernière raison de redémarrage signalée par n'importe quel AP et la Dernière raison de déconnexion enregistrée par le WLC.
Vous pouvez cliquer sur n'importe quel point d'accès et vérifier les détails des statistiques de jonction AP. Ici, vous pouvez voir des informations plus détaillées, comme l'heure et la date à laquelle l'AP s'est joint pour la dernière fois et a tenté de découvrir le WLC.
Pour plus d'informations, accédez à l'onglet Statistiques de la même fenêtre. Vous pouvez ici comparer le nombre de réponses de jointure envoyées avec le nombre de demandes de jointure reçues, ainsi que le nombre de réponses de configuration envoyées par rapport au nombre de demandes de configuration reçues.
Commandes
Ces commandes sont utiles pour dépanner les problèmes de jointure AP :
À partir du WLC
- show ap summary
- debug capwap error
- debug capwap packet
Depuis les points d'accès Wave 2 et Catalyst 11ax
- debug capwap client events (débogage des événements clients capwap)
- debug capwap client error
- debug dtls client error
- debug dtls client event
- debug capwap client keepalive
- redémarrage du capwap de test
- capwap ap erase all
À partir des points d'accès Wave 1
- debug capwap console cli
- debug capwap client no-reload
- show dtls stats
- clear cawap ap ap all-config
Remarque : lorsque vous vous connectez aux AP via Telnet/SSH pour effectuer un dépannage, émettez toujours la commande terminal monitor tout en reproduisant le problème après avoir activé les débogages sur les AP. Sinon, vous ne pouvez pas voir les résultats des débogages.
Traces radioactives
Un bon point de départ lors du dépannage des problèmes de jonction d'AP est de prendre des traces radioactives des adresses MAC radio et Ethernet d'un AP qui a des problèmes de jonction. Référez-vous à la collection Debug & Log sur le document WLC Catalyst 9800 pour plus de détails sur la génération de ces journaux.
Révision | Date de publication | Commentaires |
---|---|---|
2.0 |
06-Oct-2023 |
Première publication |
1.0 |
06-Oct-2023 |
Première publication |