Validierung und Wiederherstellung von Catalyst APs unter 17.12 aufgrund eines Upgrade-Fehlers

Einleitung

In diesem Dokument wird das Wiederherstellungsverfahren beschrieben, wenn Access Points von der Cisco Bug-ID CSCwf25731 und CSCwf37271 betroffen sind.

Kontext

Upgrades oder APSPs, die auf Systeme angewendet werden, auf denen derzeit 17.12.4/5/6/6a ausgeführt wird oder die zuvor diese Versionen für einen erheblichen Zeitraum ausgeführt haben, können dazu führen, dass betroffene AP-Modelle (siehe Liste der betroffenen Access Points unten) unter bestimmten Bedingungen in den Bootloop eintreten, was durch einen Fehler bei der Image-Installation aufgrund unzureichenden Speicherplatzes auf dem AP-Speicher ausgelöst wird. Dies hat zwar keine Auswirkungen auf den täglichen Betrieb oder SMUs, ist jedoch ein kritisches Risiko bei ISSU-, vollständigen Controller-Code-Upgrades oder APSP-Installationen, da diese Verfahren Access Points-Image-Upgrades umfassen.

Es muss ein zusätzlicher Prozess befolgt werden, der obligatorische Upgrade-Vorabprüfungen gemäß diesem Dokument erfordert, da es keine Problemumgehung für die Konfiguration gibt.

Um dieses Problem zu beheben, müssen Sie den spezifischen APSP-Versionsfix (dargestellt in der Tabelle mit den festen Codes unten) im WLC installieren, bevor die APs versuchen, ein Upgrade durchzuführen, oder den Bereinigungs-APSP (verfügbar für 17.15.4d und 17.18.2) verwenden, wenn Sie bereits zu einer späteren Version gewechselt, aber eine der betroffenen Versionen ausgeführt haben. Selbst wenn Sie sich nicht sicher sind, ob Ihr System bereits in der Vergangenheit verwendet wurde, ist es sehr empfehlenswert, vor einem Upgrade oder einer APSP-Installation Speicherüberprüfungen durchzuführen, falls die betroffenen Versionen jemals in Ihrer Umgebung vorhanden waren.

Details zur Ursache

APs mit den Versionen 17.12.4 bis 17.12.6a sind von einem Bibliotheksfehler betroffen, der eine persistente Protokolldatei generiert: /storage/cnssdaemon.log Diese Datei wächst täglich um 5 MB und wird nicht durch einen Neustart gelöscht, wodurch der Speicherplatz des Geräts schließlich erschöpft ist. Wenn der Access Point also von der Bootpartition 1 (Teil 1) ausgeführt wird und die Bootpartition 2 (Teil 2) aufgrund der Protokolldatei voll ist, schlägt der Aktualisierungsvorgang fehl, da das neue Image nicht in der Bootpartition 2 gespeichert werden kann, was zu einer Bootschleife führen kann. Um dies zu verhindern, müssen Sie den Speicher löschen oder sicherstellen, dass der Access Point von Partition 2 gestartet wurde, bevor Sie weitere Upgrades durchführen. Befolgen Sie dazu die Anweisungen in diesem Dokument.

Betroffene Codes und Access Points

Betroffene Access Points

Die folgenden Access Point-Modelle sind die einzigen, die für dieses Problem anfällig sind. Wenn Ihr Netzwerk keines dieser speziellen Modelle verwendet, ist Ihre Umgebung davon nicht betroffen und es sind keine weiteren Maßnahmen erforderlich.

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

Betroffene Codes

Führen Sie den folgenden Befehl von allen WLCs aus, um dies im gesamten Netzwerk zu überprüfen. Überprüfen Sie auch, ob der Code in den WLCs in der Tabelle unten aufgeführt ist.

#show version | in Version

Alternativ können Sie dasselbe von den APs aus tun. Überprüfen Sie die Ausgabe, um festzustellen, ob das primäre oder das Backup-Image ein betroffenes Image von den in der Tabelle aufgeführten Images ausführt.

#show version | in Image

Anmerkung: Anmerkung: Wenn das Netzwerk nicht ausgeführt wird und in der Vergangenheit nicht 17.12.4, 17.12.5, 17.12.6/6a ausgeführt hat, ist das Problem im Allgemeinen nicht anwendbar.

Feste Codes

In der folgenden Tabelle sind die WLC-Softwareversionen und die entsprechenden APSPs (Access Point Service Packs) aufgeführt, die das Problem beheben. Bitte beachten Sie, dass der Fix für die unten aufgeführten Versionen derzeit nur über die APSP-Installation zum Zeitpunkt dieser Veröffentlichung verfügbar ist.

Upgrade-Pfad und Anwendbarkeit von Fehlern

Anhand der folgenden Tabelle können Sie feststellen, ob Ihre aktuellen WLCs und APs-Softwareversionen für diesen Fehler infrage kommen und welche Upgrade-Schritte erforderlich sind. Wenn Ihre aktuelle Bereitstellung mit einer dieser Versionen in der Tabelle mit den anwendbaren Fehlern und dem Upgrade-Pfad übereinstimmt, müssen Sie die Speichervorprüfungen durchführen, die im Abschnitt Upgrade-Vorprüfungen erläutert werden, bevor Sie weitere Upgrades durchführen.

Fehler nicht zutreffend, Upgrade-Pfad

Die folgende Tabelle zeigt, ob Ihre WLCs und APs nicht für diesen Bug gelten:

Bug anwendbar und Upgrade-Pfad

Die folgende Tabelle zeigt, ob Ihre WLCs und APs für diesen Fehler zutreffen:

Upgrade-Prechecks

Wenn Ihre Umgebung von diesem Fehler betroffen ist, befolgen Sie diese obligatorischen Schritte, um eine sichere Wiederherstellung und ein Upgrade zu gewährleisten:

1. Identifizieren: Führen Sie die manuellen oder automatisierten Vorprüfungen durch, um festzustellen, welche Access Points für den Fehler infrage kommen. Eine automatisierte Vorabprüfung wird dringend empfohlen.
2. Wiederherstellen: Befolgen Sie bei markierten APs die Wiederherstellungsverfahren, die im Abschnitt Wiederherstellung beschrieben sind.
3. Überprüfung: Führen Sie die Vorabprüfungen erneut aus, um sicherzustellen, dass alle Geräte fehlerfrei sind und das Speicherproblem behoben ist.
4. Upgrade: Fahren Sie mit dem Upgrade auf die festen APSPs fort, die in der Tabelle der festen Versionen aufgeführt sind.

Manuelles Precheck

1. Über den WLC können Sie die Spalten für das primäre und das Backup-Image überprüfen, um festzustellen, ob auf Ihren Access Points eine der betroffenen Versionen ausgeführt wird (siehe Abschnitt "Affected Codes" weiter oben).

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

Sie können eine ähnliche Überprüfung auch direkt auf AP-Ebene durchführen, indem Sie den folgenden Befehl ausführen, um beide Image-Partitionen zu überprüfen:

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

Überprüfen Sie die aktive Boot-Partition, um sicherzustellen, dass das Backup-Image auf Teil 2 vorhanden ist. Verwenden Sie den Befehl "show boot", und stellen Sie sicher, dass die "BOOT path-list" auf Teil 1 verweist. zeigt dies an, dass der Access Point derzeit von der primären Partition ausgeführt wird und versucht, ein Upgrade auf die sekundäre Komponente durchzuführen, wodurch das Problem ausgelöst werden könnte.

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

2. Überprüfen Sie die aktuelle Dateisystemnutzung, indem Sie die Partition /dev/ubivol/part2 prüfen. Wenn "Use%" nahe bei 100% liegt, ist die Partition erschöpft, was dazu führt, dass das Upgrade fehlschlägt und möglicherweise eine Boot-Schleife auslöst.

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. Überprüfen Sie die Image-Integrität für beide Partitionen, um sicherzustellen, dass sie nicht beschädigt sind. Alle Felder für das primäre und das Backup-Image müssen den Status "Gut" aufweisen. Wenn in einem Feld etwas Anderes angezeigt wird, stoppen Sie den Prozess, und öffnen Sie sofort ein TAC-Ticket.

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

Automatisiertes Precheck

Verwenden Sie für die automatisierte Vorabprüfung das WLAN Poller Tool. Mit diesem Tool können Sie die erforderlichen Befehle für alle Access Points gleichzeitig ausführen, um die betroffenen Access Points zu identifizieren. Sie können es direkt über den folgenden Link herunterladen: https://developer.cisco.com/docs/wireless-troubleshooting-tools/wlan-poller-wlan-poller/

Schritte:

1. Extrahieren - Extrahieren Sie die WLAN-Abfragedateien in Ihr bevorzugtes Verzeichnis.

2. Konfiguration: Aktualisieren Sie die Datei "config.ini" mit den folgenden Parametern, um sicherzustellen, dass Sie Ihre spezifischen Anmeldeinformationen und die Controller-IP-Adresse eingeben.

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. Kommandolistenvorbereitung - Comment out (das Hashsymbol "#" hinzufügen) der Standardinhalte in "cmdlist_cos" und "cmdlist_cos_qca", dann fügen Sie die folgenden Befehle zu beiden Dateien.

# 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. Ausführung - Führen Sie das Tool mit ".\wlanpoller.exe" aus. Das Tool führt SSH für alle Access Points durch und erfasst die Befehlsausgaben.

5. Data Retrieval (Datenabruf): Navigieren Sie nach Abschluss des Vorgangs zum neu erstellten Ordner /data. Folgen Sie den Unterverzeichnissen zum endgültigen Ordner, der die einzelnen AP-Ausgabedateien enthält.

6. Analyse - Laden Sie die "ap_detection_script.py" aus dem offiziellen Box-Link, legen Sie es in den "data" Ordner und führen Sie es aus.

7. Review Results - Öffnet die generierte Datei "Status_check_results.log", um die Liste der Access Points in einem problematischen Zustand anzuzeigen. Diese Geräte erfordern Wiederherstellungsschritte (im Abschnitt Wiederherstellung unten erläutert), bevor Sie mit dem Upgrade fortfahren. Hier eine Erläuterung, wie die Ergebnisse zu interpretieren sind:

Die APs können entweder von Partition 1 oder Partition 2 booten. Wenn eine Partition aktiv ist, wird die andere für Image- oder APSP-Downloads verwendet. Die logische Speicherpartition ist Partition 2 dauerhaft zugeordnet und kann nicht geändert werden. Dieses Problem betrifft nur Access Points, die derzeit von Partition 1 booten. Sie können dies überprüfen, indem Sie in der Spalte "current_boot_partition_check" überprüfen, welche Partition derzeit von den Access Points verwendet wird. Beispiel:

Aus dem obigen Beispiel können wir schließen, dass von den 3 APs:

• AP-Name: Test AP1 (Aktion erforderlich): Wenn ein Access Point in der Spalte "current_boot_partition_check" den Wert "True Susceptible" für part1 anzeigt, müssen Sie die Spalte "part2_mem_usage_check" überprüfen. Wenn in dieser Spalte ebenfalls "True Susceptible" (Wahrhaftig anfällig) angezeigt wird, ist der Access Point betroffen.

  • Beispiel: Test AP1 ist betroffen (Start in Teil 1 und Teil 2 verfügbarer Speicherplatz: 51,9 MB) und muss wiederhergestellt werden.

• AP-Name: AP2 testen (Partition 1): Wenn ein WAP Teil1 "True Susceptible" anzeigt, "Teil2_mem_usage_check" jedoch "False Not Susceptible" anzeigt, ist der WAP sicher.

  • Beispiel: Test AP2 ist nicht betroffen, da es genügend Platz in Partition 2 (Teil 2) hat, jedoch wird empfohlen, den APSP zu installieren, um zukünftige Probleme zu beheben, da die Datei cnssdaemon.log weiterhin im AP vorhanden ist.

• AP-Name: Test AP3 (Partition 2): Wenn ein Access Point in der Spalte "current_boot_partition_check" Teil 2 "False Not Susceptible" anzeigt, ist dies nicht der Fall. Weitere Kontrollen sind nicht erforderlich.

Anmerkung: Anmerkung: Der numerische Wert, der in der Spalte "part2_mem_usage_check" neben dem Status "True/False Susceptible" erscheint, stellt den verfügbaren Speicherplatz in Partition 2 dar.

• Jeder Access Point: Wenn auf einem AP die Option "Image Integrity Check: Failed" (Fehler) in der Spalte "image_integrity_check" (Image_Integritätsprüfung) öffnen Sie ein TAC-Ticket.

Wiederherstellung

Basierend auf dem jeweiligen Status jedes Access Points empfiehlt das Skript die effizienteste Wiederherstellungsmethode. Befolgen Sie die unten aufgeführten detaillierten Schritte für die identifizierten betroffenen APs:

Austausch der AP-Image-Partition

1. Isolierung der APs: Stellen Sie sicher, dass die APs nicht mit dem WLC verbunden sind.
   1. Stellen Sie sicher, dass SSH im Zugangsprofil der APs aktiviert ist und dass die APs SSH-fähig sind (oder eine Konsole verwenden).
   2. Stellen Sie sicher, dass die APs nicht mit dem WLC verbunden sind, Sie jedoch weiterhin über SSH-Zugriff auf die APs verfügen. Hierzu muss eine ACL im Gateway vorhanden sein, oder die APs werden in ein isoliertes VLAN verschoben. Wenn die APs Zugriff auf den WLC erhalten, kann der AP zum Booten von Teil 1 zurückkehren und wieder in den betroffenen Zustand zurückkehren.

2. Konfigurieren des Startpfads - Legen Sie auf den betroffenen Access Points den Startpfad auf Partition 2 fest:

AP# config boot path 2

3. Neustart - Starten Sie den Access Point neu, um das Image von Partition 2 zu laden:

AP# reload

4. Upgrade - Installieren Sie im WLC den benötigten APSP in Ihrem aktuellen Code, oder, wenn Sie den Code aktualisieren würden, wechseln Sie zu einem neuen Code und stellen Sie sicher, dass APSP ebenfalls installiert ist.

5. Reconnect (Wiederverbindung herstellen): Entfernen Sie nach Abschluss des Controller-Upgrades den Kommunikationsstopper zwischen dem AP und dem WLC. Der AP wird dem WLC beitreten und automatisch das neue, feste Image beim Start von Teil 1 herunterladen.

6. Doppelprüfung - Überprüfen Sie nach dem Upgrade auf eine feste Version beide Partitionen der APs, um sicherzustellen, dass der Backup-Steckplatz nicht immer noch das fehlerhafte Image enthält.

7. Wartung - Um die Stabilität langfristig aufrechtzuerhalten und zukünftige Boot-Schleifen zu verhindern, empfehlen wir, die Backup-Partition mit einem zweifelsfrei funktionierenden Image zu überschreiben. Für kleinere Gruppen Archiv "download-sw" direkt auf dem AP; Bei größeren Bereitstellungen sollten Sie einen WLC-WAP vor dem Herunterladen durchführen, um die Backup-Partition zu aktualisieren, ohne die Aktivierung des WLC-WAP-Images auszulösen.

Wiederherstellung des AP-Shell-Zugriffs

Das Technical Assistance Center (TAC) kann die manuelle Wiederherstellung durchführen, indem es die Datei cnssdaemon.log direkt von der Shell auf den betroffenen Access Points löscht. Je nach Ausmaß der Auswirkungen gibt es im Folgenden zwei Methoden:

• Geringe Anzahl betroffener APs: Für eine kleine Anzahl betroffener APs kann das TAC mit einem von zwei Ansätzen fortfahren:

  • Manueller Shell-Zugriff: Greifen Sie über die Shell einzeln auf jeden Access Point zu, um die Protokolldatei manuell zu löschen.

  • Automatisierter (Bulk-)Shell-Zugriff: Verwenden Sie das RADKit-Tool, um den Bereinigungsprozess für alle betroffenen APs zu automatisieren.

• Große Anzahl betroffener APs: TAC verwendet das Radkit-Tool, das einen Bulk-Shell-Zugriff auf alle betroffenen APs ermöglicht, um den Cleanup-Prozess effizient durchzuführen.

Anmerkung: Wir empfehlen die Verwendung von RADKit für das Wiederherstellungsverfahren des AP-Shell-Zugriffs, um Effizienz und Konsistenz zu gewährleisten.

Anmerkung: Radkit kann über folgenden Link heruntergeladen werden: Radkit Laden Sie die neueste Version herunter und laden Sie sie herunter. Folgen Sie diesem Video, um Radkit zu installieren: Radkit-Installation

Wann sollte ich ein TAC-Ticket eröffnen?

Öffnen Sie sofort ein TAC-Ticket, wenn eine der folgenden Bedingungen eintritt:

• Fehlgeschlagene Wiederherstellung: Das AP-Image AP Image Partition Swap-Verfahren schlägt fehl oder kann nicht in Ihrer Umgebung implementiert werden.
• Integrität: Manuelle oder automatisierte Vorprüfungen geben einen "Image Integrity Check: Fehlgeschlagen" für einen AP.
• Speichererschöpfung: Wenn nach dem Upgrade/APSP installieren die Partition "/dev/ubivol/part2" zeigt noch eine kritisch hohe Nutzung.

Cisco TAC kann auf die AP-Shell zugreifen, um die Datei "cnssdaemon.log" manuell zu löschen und erweiterte Wiederherstellungsaktionen durchzuführen, um Ihre Geräte wiederherzustellen.

Häufig gestellte Fragen

F: Gilt dieses Problem nur für vollständige Code-Upgrades oder betrifft es auch APSP-Installationen?

A : Dieses Problem betrifft beide Szenarien. Wenn Ihre Umgebung die Kriterien für diesen Fehler erfüllt, kann das Problem während eines vollständigen Code-Upgrades oder einer APSP-Installation (einschließlich des APSP mit der Fehlerbehebung) auftreten. Bitte führen Sie die Upgrade-Vorabprüfungen durch, um festzustellen, ob Sie die Wiederherstellungsschritte durchführen müssen, bevor Sie Updates oder APSPs anwenden.

F: Mein WLC und meine APs sind auf 17.9.x (oder älter) und ich muss auf 17.12.x aktualisieren. Was soll ich tun?

A : Sie können ein direktes Upgrade von 17.9.x auf 17.12.x durchführen. Wenn Ihre AP-Modelle jedoch anfällig für diesen Fehler sind, stellen Sie sicher, dass Sie den empfohlenen APSP sofort nach dem Upgrade installieren.

F: Mein WLC und meine APs verwenden Version 17.9.x (oder frühere Version), und ich muss ein Upgrade auf Version 17.15.x oder höher durchführen.

A : Es gibt zwei mögliche Szenarien:

• Direktes Upgrade: Wenn Ihre Umgebung ein direktes Upgrade zulässt (bitte überprüfen Sie dies in den Versionshinweisen für Ihren Zielcode), fahren Sie mit dem Upgrade fort und installieren Sie dann den APSP für diesen Zielcode.
• Zwischenaktualisierung: Wenn Sie einem Upgrade-Pfad folgen müssen (z. B. 17.9.x → 17.12.x → 17.15.x), empfehlen wir, die gesamte Sequenz bis 17.15.x innerhalb eines Tages auszuführen. Da die Datei cnssdaemon.log täglich um 5 MB wächst, verhindert das schnelle Abschließen des Upgrades, dass die Datei eine kritische Größe erreicht. Wenn ein Upgrade am selben Tag nicht möglich ist, müssen Sie den APSP in der Phase 17.12.x installieren, bevor Sie schließlich mit 17.15.x fortfahren und den entsprechenden APSP installieren können.

F: Ich bin bereits am 17.15.x. Bedeutet das, dass ich von diesem Fehler nicht betroffen bin?

A : Nicht unbedingt. Wenn Ihre APs zuvor die Versionen 17.12.4, 17.12.5 oder 17.12.6/6a (auf 9800-L/40/80/CL) ausgeführt haben, wurde die problematische Protokolldatei möglicherweise bereits erstellt und bleibt im Speicher. Wir empfehlen dringend, den Abschnitt Upgrade Prechecks zu befolgen, um sicherzustellen, dass alle verbleibenden Dateien bereinigt werden.

F: Ich verwende die Plattformen 9800-M, 9800-H1 oder 9800-H2, die zuerst in 17.15 unterstützt wurden. Bin ich betroffen?

A : Es gibt zwei mögliche Szenarien:

• Der erste Anbieter, der WLC beitrat: Wenn Ihre APs einem 9800-M/H1/H2 als erstem Controller beigetreten sind, sind Sie davon nicht betroffen.
• Zuvor beigetretene WLCs: Wenn diese APs vor dem Wechsel auf den 9800-M/H1/H2 zuvor mit einem anderen Controller verbunden wurden, auf dem eine betroffene Version ausgeführt wird (17.12.4/5/6/6a), tragen sie möglicherweise immer noch die problematische Datei. In diesem Fall befolgen Sie bitte den Abschnitt Upgrade-Vorabprüfungen.

F: Wir verfügen über separate WLCs für Labortests und gestaffelte Upgrades. Wie sollten wir damit umgehen?

A : Stellen Sie sicher, dass auf allen WLCs in Ihrer Umgebung der entsprechende APSP ausgeführt wird. Da die Datei cnssdaemon.log täglich um 5 MB wächst, wird jeder Access Point, der einem WLC beitritt, der betroffenen Code ausführt, möglicherweise anfällig für diesen Fehler, auch vorübergehend zum Testen.