Validation et récupération des points d'accès Catalyst sur 17.12 affectés par une défaillance de mise à niveau

Introduction

Ce document décrit la procédure de récupération quand les AP sont affectés par l'ID de bogue Cisco CSCwf25731 et CSCwf37271.

Contexte

Les mises à niveau ou les PASP appliqués aux systèmes qui exécutent actuellement 17.12.4/5/6/6a ou qui exécutaient précédemment ces versions pendant une période de temps considérable peuvent entraîner l'entrée dans une boucle d'amorçage des modèles de point d'accès affectés (veuillez vérifier la liste des points d'accès affectés ci-dessous) dans certaines conditions, déclenchée par un échec d'installation de l'image en raison d'un espace disque insuffisant sur le stockage du point d'accès. Bien que cela n'affecte pas les opérations quotidiennes ou les SMU, il s'agit d'un risque critique lors des mises à niveau ISSU, des mises à niveau complètes du code du contrôleur ou des installations APSP, car ces procédures impliquent des mises à niveau d'image des points d'accès.

Il est nécessaire de suivre un processus supplémentaire qui nécessite des étapes obligatoires de vérification préalable de la mise à niveau mentionnées dans ce document, car il n'existe aucune solution de contournement de la configuration.

Pour résoudre ce problème, vous devez installer le correctif de version APSP spécifique (indiqué dans le tableau Codes fixes ci-dessous) dans le WLC avant que les AP ne tentent de mettre à niveau, ou utiliser le correctif APSP de nettoyage (disponible pour 17.15.4d et 17.18.2) si vous avez déjà déplacé vers une version ultérieure mais exécuté l'une des versions affectées. Même si vous n'êtes pas sûr de l'historique de votre système, il est fortement recommandé d'effectuer des vérifications de stockage avant toute mise à niveau ou installation d'APSP si les versions concernées ont déjà été présentes dans votre environnement.

Détails de la cause première

Les points d'accès exécutant les versions 17.12.4 à 17.12.6a sont affectés par un bogue de bibliothèque qui génère un fichier journal persistant : /storage/cnssdaemon.log. Ce fichier augmente de 5 Mo par jour et n'est pas effacé par les redémarrages, ce qui finit par épuiser l'espace de stockage du périphérique. Par conséquent, si l'AP est exécuté à partir de la partition de démarrage 1 (Partie 1), et la partition de démarrage 2 (Partie 2) est pleine en raison du fichier journal, le processus de mise à niveau échouera parce qu'il ne peut pas stocker la nouvelle image dans la partition de démarrage 2, ce qui peut conduire à une boucle de démarrage. Pour éviter cela, vous devez effacer le stockage ou vous assurer que le point d'accès a démarré à partir de la partition 2 avant d'essayer toute mise à niveau supplémentaire en suivant les instructions de ce document.

Codes et points d'accès affectés

Points d'accès affectés

Les modèles de points d'accès suivants sont les seuls susceptibles de rencontrer ce problème. Si votre réseau n'utilise aucun de ces modèles spécifiques, votre environnement n'est pas affecté et aucune action supplémentaire n'est requise.

• Catalyst 9124 (I/D/E)
• Catalyst 9130 (E/S)
• Catalyst 9136I
• Catalyst 9162I
• Catalyst 9163E
• Catalyst 9164I
• Catalyst 9166 (I/D1)
• Catalyst IW9167 (I/E)

Codes affectés

Pour vérifier cela sur votre réseau, exécutez la commande suivante à partir de tous les WLC et vérifiez si le code présent dans vos WLC est répertorié dans le tableau ci-dessous.

#show version | in Version

Vous pouvez également faire la même chose à partir des points d'accès. Vérifiez le résultat pour voir si l'image principale ou de sauvegarde exécute une image affectée parmi celles répertoriées dans le tableau.

#show version | in Image

Remarque : Remarque : En général, si le réseau n'est pas en cours d'exécution et n'a pas exécuté 17.12.4, 17.12.5, 17.12.6/6a dans le passé, le problème n'est pas applicable.

Codes fixes

Le tableau suivant répertorie les versions du logiciel WLC et leurs APSP (Access Point Service Packs) correspondants qui contiennent le correctif pour ce bogue. Veuillez noter que pour les versions répertoriées ci-dessous, le correctif est actuellement disponible uniquement via l'installation d'APSP au moment de la rédaction de ce document.

Chemin de mise à niveau et applicabilité des bogues

Utilisez le tableau ci-dessous pour déterminer si vos versions logicielles actuelles de WLC et d'AP s'appliquent à ce bogue et quelles étapes de mise à niveau prendre. Si votre déploiement actuel correspond à l'une de ces versions dans la table Bug applicable et chemin de mise à niveau, vous devez effectuer les vérifications préalables du stockage décrites dans la section Prévérifications de mise à niveau avant d'essayer d'autres mises à niveau.

Bogue non applicable et chemin de mise à niveau

Le tableau suivant montre si vos WLC et AP ne s'appliquent pas pour ce bogue :

Bogue applicable et chemin de mise à niveau

Le tableau suivant montre si vos WLC et AP ne s'appliquent pas pour ce bogue :

Prévérifications de mise à niveau

Si votre environnement est affecté par ce bogue, suivez ces étapes obligatoires pour assurer une récupération et une mise à niveau en toute sécurité :

1. Identifier : Exécutez les vérifications préalables manuelles ou automatisées pour identifier les points d'accès spécifiques applicables au bogue. Une vérification préalable automatisée est fortement recommandée.
2. Récupérer : Pour tous les AP marqués, suivez les procédures de récupération mentionnées dans la section Récupération.
3. Vérifier : Réexécutez les vérifications préalables pour vérifier que tous les périphériques sont sains et que le problème de stockage est résolu.
4. Mise à niveau: Procédez à la mise à niveau vers les PAPS fixes répertoriés dans le tableau Versions fixes.

Prévérification manuelle

1. À partir du WLC, vous pouvez vérifier les colonnes d'image principale et de sauvegarde pour confirmer si vos points d'accès exécutent l'une des versions affectées (consultez la section Codes affectés ci-dessus).

9800-l#show ap image
Total number of APs  : 4

Number of APs
        Initiated                  : 0
        Downloading                : 0
        Predownloading             : 0
        Completed downloading      : 0
        Completed predownloading   : 0
        Not Supported              : 0
        Failed to Predownload      : 0
        Predownload in progress    : No

AP Name             Primary Image          Backup Image            Predownload Status   Predownload Version  Next Retry Time   Retry Count   Method
------------------------------------------------------------------------------------------------------------------------------------------------------------------
Ap117.12.5.41        17.12.4.201                None                  0.0.0.0             N/A                 0           N/A
Ap217.12.5.41        17.12.4.201                None                  0.0.0.0             N/A                 0           N/A
Ap317.12.5.41        17.12.4.201                None                  0.0.0.0             N/A                 0           N/A
Ap417.12.5.41        17.12.4.201                None                  0.0.0.0             N/A                 0           N/A

Vous pouvez également effectuer une vérification similaire directement au niveau du point d'accès en exécutant la commande suivante pour vérifier les deux partitions d'image :

AP# show version
AP Running Image     :17.12.5.41
Primary Boot Image   : 17.12.5.41
Backup Boot Image    : 17.12.5.209
Primary Boot Image Hash: 93ef1e703a5e7c5a4f97b8f59b220f52d94dd17c527868582c0048caad6397a9f3526c644f94a52bb70a104385690065ad0d652aa3fed607f24920d7e5ed5b5c
Backup Boot Image Hash: 4bbe4a0d9edc3cad938a7de399d3c2e08634643a2623bae65973ef00deb154b8eb7c7917eeecdd46e3e2ddc7be80139475e19fb3040b08aa715de196a733252b
1 Multigigabit Ethernet interfaces

Vérifiez la partition de démarrage active pour vous assurer que l'image de sauvegarde se trouve sur la partie2. Utilisez la commande « show boot » et vérifiez que la « liste de chemins d'accès BOOT » pointe vers la partie1. cela indique que l'AP est actuellement exécuté à partir de la partition principale et tente de mettre à niveau vers la partie secondaire qui pourrait déclencher le problème.

AP# show boot
--- Boot Variable Table ---
BOOT path-list: part1
Console Baudrate: 9600 Enable Break:

2. Vérifiez l'utilisation actuelle du système de fichiers en vérifiant la partition /dev/ubivol/part2. Si le pourcentage d'utilisation est proche de 100 %, la partition est épuisée, ce qui entraînera l'échec de la mise à niveau et peut-être le déclenchement d'une boucle de démarrage.

AP# show filesystems
Filesystem                Size      Used Available Use% Mounted on
devtmpfs                880.9M         0    880.9M   0% /dev
/sysroot                883.8M    219.6M    664.1M  25% /
tmpfs                     1.0M     56.0K    968.0K   5% /dev/shm
tmpfs                   883.8M         0    883.8M   0% /run
tmpfs                   883.8M         0    883.8M   0% /sys/fs/cgroup
/dev/ubivol/part1       372.1M     79.7M    292.4M  21% /part1
/dev/ubivol/part2       520.1M    291.3M    228.9M  56% /part2

3. Vérifiez l'intégrité de l'image pour les deux partitions afin de vous assurer qu'elles ne sont pas endommagées. Tous les champs des images principale et de sauvegarde doivent afficher l'état "Bon"; si un champ indique le contraire, arrêtez le processus et ouvrez un dossier TAC immédiatement.

AP# show image integrity
/part1(Backup) 17.12.5.209
    part.bin : Good
    ramfs_data_cisco.squashfs : Good
    iox.tar.gz : Good
/part2(primary) 17.12.5.41
    part.bin : Good
    ramfs_data_cisco.squashfs : Good
    iox.tar.gz : Good

Prévérification Automatisée

Pour la vérification préalable automatisée, utilisez l'outil WLAN Poller. Cet outil vous permet d'exécuter les commandes nécessaires sur tous vos points d'accès simultanément pour identifier les points d'accès concernés ; vous pouvez le télécharger directement à partir du lien suivant : https://developer.cisco.com/docs/wireless-troubleshooting-tools/wlan-poller-wlan-poller/#wlan-poller

Étapes:

1. Extraction - Extrayez les fichiers du contrôleur WLAN dans votre répertoire préféré.

2. Configuration - Mettez à jour le fichier "config.ini" avec les paramètres suivants, en vous assurant que vous entrez vos informations d'identification spécifiques et l'adresse IP du contrôleur.

wlc_type: 2
mode: ssh
ap_mode: ssh

; set global WLC credentials
wlc_user: 
wlc_pasw: 
wlc_enable: 

; set global AP credentials
ap_user: 
ap_pasw: 
ap_enable: 

[WLC-1]
active: True
ipaddr: 
mode: ssh

3. Préparation de la liste de commandes - Commentez (ajoutez le symbole de hachage « # ») le contenu par défaut dans « cmdlist_cos » et « cmdlist_cos_qca », puis ajoutez les commandes suivantes aux deux fichiers.

# snippet to download the Debug image on COS APs
# show version | in Compiled
# archive download-sw /reload tftp:///
# 
show clock
show version
show flash
show flash | i cnssdaemon.log
show boot
show filesystems
show image integrity

4. Exécution - Exécutez l'outil à l'aide de « .\wlanpoller.exe ». L'outil effectue une connexion SSH à tous les points d'accès et collecte les résultats de la commande.

5. Récupération des données - Une fois terminé, naviguez jusqu'au dossier /data nouvellement créé. Suivez les sous-répertoires jusqu'au dossier final contenant les fichiers de sortie individuels de l'AP.

6. Analyse - Téléchargez le "ap_detection_script.py" à partir du lien officiel Box, placez-le dans le dossier "data" et exécutez-le.

7. Examiner les résultats - Ouvrez le "Status_check_results.log" généré pour afficher la liste des points d'accès dans un état problématique. Ces périphériques nécessitent des étapes de récupération (expliquées dans la section Récupération ci-dessous) avant de procéder à la mise à niveau, voici une explication de la façon d'interpréter les résultats :

Par conception, les AP peuvent démarrer à partir de la partition 1 ou de la partition 2. Quand une partition est active, l'autre est utilisée pour les téléchargements d'image ou d'APSP. La partition de stockage logique est mappée de manière permanente à la partition 2 et ne peut pas être modifiée. Ce problème affecte uniquement les points d'accès qui démarrent actuellement à partir de la partition 1. Vous pouvez vérifier cela en vérifiant la colonne "current_boot_partition_check" pour vérifier quelle est la partition actuelle utilisée par les AP. Exemple :

À partir de l'exemple ci-dessus, nous pouvons conclure que des 3 AP :

• Nom du point d'accès : Test AP1 (action requise) : Si un point d'accès affiche la partie 1 "Vrai Susceptible" dans la colonne "current_boot_partition_check", vous devez alors vérifier la colonne "part2_mem_use_check". Si cette colonne indique également "Vrai sensible", l'AP est affecté.

  • Exemple : Le test de l'AP1 est affecté (démarrage dans l'espace disponible des Parties1 et2 : 51,9 MB) et nécessite une récupération.

• Nom du point d'accès : Test AP2 (Partition 1) : Si un point d'accès affiche la partie 1 "Vrai Susceptible" mais que la partie 2_mem_utilisation_check affiche "Faux Non Susceptible", le point d'accès est sûr.

  • Exemple : Le test de l'AP2 n'est pas impacté car il a assez d'espace dans la partition 2 (partie2), cependant, il est recommandé d'installer l'APSP pour prendre soin des problèmes futurs puisque le fichier cnssdaemon.log continue d'exister dans l'AP.

• Nom du point d'accès : Test AP3 (Partition 2) : Si un point d'accès affiche la partie 2 "False Not Susceptible" dans la colonne "current_boot_partition_check", il n'est pas affecté. Aucun autre contrôle n'est nécessaire.

Remarque : Remarque : La valeur numérique apparaissant dans la colonne "part2_mem_used_check" en regard de l'état "Vrai/Faux sensible" représente la quantité d'espace disponible dans la partition 2.

• Tout point d'accès : Si un point d'accès affiche « Image Integrity Check : Failed" dans la colonne "image_Integrity_Check", poursuivez l'ouverture d'un dossier TAC.

Récupération

En fonction de l'état spécifique de chaque point d'accès, le script recommandera la méthode de récupération la plus efficace. Suivez les étapes détaillées ci-dessous pour les points d'accès affectés identifiés :

Échange de partition d'image AP

1. Isoler les AP - assurez-vous que les AP n'ont aucune connectivité avec le WLC :
   1. Assurez-vous que SSH est activé dans le profil de jonction des AP et que les AP sont accessibles par SSH (ou utilisez la console)
   2. Assurez-vous que les AP n'ont pas de connectivité avec le WLC, mais, vous avez toujours un accès SSH aux AP. Cela peut être réalisé en ayant une ACL dans la passerelle ou en déplaçant les AP vers un VLAN isolé. Si les AP obtiennent l'accès au WLC, l'AP pourrait revenir à la Partie d'amorçage 1 et reviendra à l'état affecté.

2. Configurer le chemin d'amorçage - Sur les AP concernés, définissez le chemin d'amorçage sur la partition 2 :

AP# config boot path 2

3. Reboot - Redémarrez l'AP pour charger l'image à partir de la partition 2 :

AP# reload

4. Mise à niveau - Installez dans le WLC l'APSP nécessaire dans votre code actuel, ou, si vous deviez mettre à niveau le code, passez à un nouveau code et assurez-vous que l'APSP est également installé.

5. Reconnect - Une fois la mise à niveau du contrôleur terminée, supprimez l'arrêt de communication entre le point d'accès et le WLC. Le point d'accès va rejoindre le WLC et télécharger automatiquement la nouvelle image fixe dans la partie de démarrage 1.

6. Double vérification - Après la mise à niveau vers une version fixe, vérifiez les deux partitions des AP pour vous assurer que le slot de sauvegarde ne contient toujours pas l'image boguée.

7. Maintenance - Pour maintenir la stabilité à long terme et éviter de futures boucles de démarrage, nous vous recommandons de remplacer la partition de sauvegarde par une image correcte connue. Pour les petits groupes, utilisez archive "download-sw" directement sur l'AP ; pour les déploiements plus importants, effectuez un pré-téléchargement AP WLC pour mettre à jour la partition de sauvegarde sans déclencher l'activation de l'image AP.

Récupération d'accès shell AP

Le Centre d'assistance technique (TAC) peut effectuer une récupération manuelle en effaçant le fichier cnssdaemon.log directement de l'interpréteur de commandes sur les points d'accès affectés. Selon l'ampleur de l'impact, il existe deux méthodes mentionnées ci-dessous :

• Petit nombre de points d'accès affectés : Pour un petit nombre de points d'accès affectés, le TAC peut procéder en utilisant l'une des deux approches suivantes :

  • Accès manuel au shell : Accédez à chaque point d'accès individuellement via le shell pour effacer manuellement le fichier journal.

  • Accès automatisé (en masse) au shell : Utilisez l'outil RADKit pour automatiser le processus de nettoyage de tous les points d'accès affectés.

• Grand nombre de points d'accès affectés : le TAC doit utiliser l'outil Radkit, ce qui permet un accès groupé de l'interpréteur de commandes à tous les points d'accès affectés simultanément pour exécuter le processus de nettoyage efficacement.

Remarque : Nous recommandons d'utiliser RADKit pour la procédure de récupération d'accès au shell AP afin d'assurer l'efficacité et la cohérence.

Remarque : Pour télécharger Radkit, veuillez utiliser ce lien : Radkit Téléchargez et téléchargez la dernière version. Pour installer Radkit, suivez cette vidéo : Installation Radkit

Quand ouvrir un dossier TAC

Ouvrez immédiatement un dossier TAC si l'une des situations suivantes se présente :

• Échec de la récupération : La procédure AP Image AP Image Partition Swap échoue ou ne peut pas être implémentée dans votre environnement.
• Problèmes d'intégrité : Les prévérifications manuelles ou automatisées renvoient une « Vérification de l'intégrité de l'image : État « Failed » pour tout point d'accès.
• Épuisement du stockage : Si, après la mise à niveau/l'installation d'APSP, la partition "/dev/ubivol/part2" montre toujours une utilisation très élevée.

Cisco TAC peut accéder à l'interpréteur de commandes AP pour effacer manuellement le fichier cnssdaemon.log et effectuer des actions de récupération avancées pour restaurer vos périphériques.

FAQ

Q : Ce problème s'applique-t-il uniquement aux mises à niveau de code complètes ou affecte-t-il également les installations APSP ?

A : Ce problème affecte les deux scénarios. Si votre environnement répond aux critères de ce bogue, le problème peut se produire pendant une mise à niveau complète du code ou l'installation d'APSP (y compris l'APSP avec le correctif de bogue). Veuillez compléter la section Prévérifications de mise à niveau pour déterminer si vous devez suivre les étapes de récupération avant d'appliquer des mises à jour ou des PASP.

Q : Mes WLC et AP sont sur 17.9.x (ou antérieure) et je dois mettre à niveau vers 17.12.x, Que dois-je faire ?

A : Vous pouvez effectuer une mise à niveau directe de 17.9.x vers 17.12.x. Cependant, si vos modèles AP sont sensibles à ce bogue, assurez-vous d'installer l'APSP recommandé immédiatement après la mise à niveau.

Q : Mes WLC et AP sont sur 17.9.x (ou antérieure) et je dois mettre à niveau vers 17.15.x ou supérieur.

A : Deux scénarios sont possibles :

• Mise à niveau directe : Si votre environnement permet une mise à niveau directe (veuillez vérifier via les notes de publication pour votre code cible), poursuivez la mise à niveau, puis installez l'APSP pour ce code cible.
• Mise à niveau intermédiaire : Si vous devez suivre un chemin de mise à niveau (par exemple, 17.9.x → 17.12.x → 17.15.x), nous vous recommandons de terminer la séquence complète vers 17.15.x dans le même jour. Étant donné que le fichier cnssdaemon.log augmente de 5 Mo par jour, l'achèvement de la mise à niveau empêche rapidement le fichier d'atteindre une taille critique. Si une mise à niveau le jour même n'est pas possible, vous devez installer l'APSP à l'étape 17.12.x avant de passer à l'étape 17.15.x et d'installer son APSP respectif.

Q : Je suis déjà sur 17.15.x. Cela signifie-t-il que je ne suis pas affecté par ce bogue ?

A : Pas nécessairement. Si vos AP exécutaient précédemment la version 17.12.4, 17.12.5 ou 17.12.6/6a (sur 9800-L/40/80/CL), le fichier journal problématique peut avoir déjà été généré et rester dans le stockage. Nous vous recommandons vivement de suivre la section Prévérifications de mise à niveau pour vous assurer que les fichiers résiduels sont nettoyés.

Q : J'utilise les plates-formes 9800-M, 9800-H1 ou 9800-H2, qui ont été prises en charge pour la première fois dans la version 17.15. Suis-je concerné ?

A : Deux scénarios sont possibles :

• Première connexion au WLC : Si vos points d'accès ont rejoint un 9800-M/H1/H2 en tant que premier contrôleur, vous n'êtes pas affecté.
• Les WLC précédents ont rejoint : Si ces AP ont été précédemment joints à un contrôleur différent exécutant une version affectée (17.12.4/5/6/6a) avant de passer au 9800-M/H1/H2, ils peuvent toujours transporter le fichier problématique. Dans ce cas, veuillez suivre la section Prévérifications de mise à niveau.

Q : Nous avons des WLC séparés pour les tests en laboratoire et les mises à niveau échelonnées. Comment devrions-nous les gérer ?

A : Assurez-vous que tous les WLC de votre environnement exécutent l'APSP approprié. Étant donné que le fichier cnssdaemon.log augmente de 5 Mo par jour, tout AP qui rejoint un WLC exécutant du code affecté, même temporairement pour le test, deviendra potentiellement sensible à ce bogue.