Inhalt

Einleitung

Anforderungen

Verwendete Komponenten

Funktionsweise von ISSU

Einschränkungen

Anforderungen und Prüfungen

Upgrade-Prozedur

ISSU-CLI-Workflow

Vollständiger Vorgang

Zusätzliche Betriebsabläufe

Fehlerbehebung

Referenzen

Einleitung

In diesem Dokument wird beschrieben, wie ein Paar Wireless-Controller der Serie 9800 in HA SSO mithilfe der ISSU-Methode (In-Service Software Upgrade) aktualisiert wird.

Anforderungen

Das Dokument beschreibt die Vorgehensweise, die Einschränkungen, die zu treffenden Vorsichtsmaßnahmen und die Upgrade-Anweisungen.

Cisco empfiehlt, dass Sie über Kenntnisse in folgenden Bereichen verfügen:

- Catalyst 9800 Wireless LAN-Controller (WLC)

- Stateful Switchover mit hoher Verfügbarkeit (HA SSO)

Verwendete Komponenten

Dieses Dokument ist nicht auf bestimmte Software- und Hardware-Versionen beschränkt.

Die Informationen in diesem Dokument beziehen sich auf Geräte in einer speziell eingerichteten Testumgebung. Alle in diesem Dokument verwendeten Geräte begannen mit einer gelöschten (Standard-)Konfiguration. Wenn Ihr Netzwerk in Betrieb ist, stellen Sie sicher, dass Sie die möglichen Auswirkungen aller Befehle kennen.

Funktionsweise von ISSU

ISSU ist eine Funktion, die ein Upgrade der Wireless Controller 9800 mit minimalen Ausfallzeiten ermöglicht. Wenn Sie über eine ausreichende Abdeckung verfügen, erfolgt das Upgrade nahtlos, und die Wireless-Clients dürfen keine Ausfallzeiten beobachten. Um dies zu ermöglichen, verfügt ISSU über einen Mechanismus, bei dem jeweils ein Controller aktualisiert wird und die APs gestaffelt aktualisieren können.

Im Folgenden finden Sie eine kurze Übersicht über die verschiedenen Schritte, die während eines ISSU-Upgrades durchgeführt werden:

1. Das Ziel-Image (V2) wird auf den primären Controller heruntergeladen, auf dem V1 ausgeführt wird, und in Pakete erweitert.

2. Das Image wird dann über die RP-Verbindung mit dem Hot-Standby-Controller synchronisiert. Dieser Prozess ist für alle Upgrade-Typen identisch

3. Das entsprechende AP-Image (V2) wird vorab auf die APs heruntergeladen. Der Vorabdownload eines Images hat keine Auswirkungen auf den Service.

4. Der Standby-Controller wird neu geladen und mit dem neuen Image (V2) geladen. An diesem Punkt führt der aktive Controller V1 und den Standby-Controller V2 aus, und sie bilden ein SSO-Paar. Dies ist nur während eines ISSU-Upgrades möglich.

5. Sobald das HA-Paar bereit ist (Aktiv/Standby-Hot-Zustand), wird ein Switchover ausgeführt. Auf dem aktiven Controller wird jetzt V2 und auf dem Standby-Gerät V1 ausgeführt. Der Standby-Controller wird neu geladen und mit V2 ausgeliefert. Zu diesem Zeitpunkt befinden sich beide Controller auf V2, aber die APs laufen noch auf V1.

6. Die APs werden aufgefordert, nach dem Aktivierungsschritt die Images auf V2 umzuschalten, und sie werden fortlaufend aktualisiert, um die Ausfallzeiten zu minimieren. Das bedeutet, dass pro Zyklus Untergruppen von WAPs neu geladen werden und die Clients eine Verbindung zu den benachbarten WAPs herstellen können. Wenn die APs wieder beitreten, werden sie wieder mit V2 verbunden.

7. Der letzte Schritt ist Commit, wodurch die Änderungen permanent sind.

Einschränkungen

Dies sind die Einschränkungen, die Sie beachten müssen, bevor Sie ein ISSU-Upgrade durchführen:

- Das Basis-Image muss Cisco IOS XE 17.3 oder höher sein.

- ISSU ist nur zwischen den Hauptversionen desselben Zuges verfügbar. So wird beispielsweise 16.x.x auf 17.x.x oder 17.x.x auf den nächsten Hauptzug nicht unterstützt

- ISSU-Downgrade wird für Cisco Catalyst Wireless Controller der Serie 9800 nicht unterstützt.

- ISSU-Upgrade wird nur für Controller im INSTALLATIONSMODUS unterstützt (PAKETMODUS wird nicht unterstützt)

- Ein ISSU-Upgrade nimmt mehr Zeit in Anspruch als ein Standard-Upgrade, da sich ein WLC zu einem bestimmten Zeitpunkt im HA-Paar selbst aktualisiert und dann ein fortlaufendes Upgrade durchführt, um die Ausfallzeiten zu minimieren. Wenn Sie APs hinter einer WAN-Verbindung mit einer gewissen Latenz haben, ist es wichtig, die Download-Zeit des AP-Images zu minimieren, da dies die ISSU-Upgrade-Zeit durch Kaskadierung drastisch erhöhen kann. Achten Sie auf effiziente Methoden für AP-Upgrades oder HTTPS-Out-of-Band-Upgrades, um die Download-Zeit für AP-Images zu verkürzen und die ISSU-Gesamtdauer auf ein Minimum zu begrenzen.

Anforderungen und Prüfungen

Bevor Sie mit dem Upgrade der Wireless Controller 9800 mit ISSU fortfahren, müssen Sie einige Anforderungen und Prüfungen erfüllen, um ein reibungsloses Upgrade der Controller und der Access Points sicherzustellen.

Schritt 1: Überprüfen, ob keine aktive oder nicht aktivierte Version ausgeführt wird

CLI-Befehl:

show install summary

Erwartete Ausgabe:

Es wird nur eine Version im Status "C" (für aktiviert und aktiviert) angezeigt:

WLC#show install summary

[ Chassis 1/R0 2/R0 ] Installed Package(s) Information:

State (St): I - Inactive, U - Activated & Uncommitted,

C - Activated & Committed, D - Deactivated & Uncommitted

--------------------------------------------------------------------------------

Type  St   Filename/Version

--------------------------------------------------------------------------------

IMG   C    17.09.04a.0.6

Schritt 2: Überprüfen, ob sich der Controller im INSTALLATIONSMODUS befindet

Stellen Sie sicher, dass sich sowohl der aktive als auch der Standby-Controller im Installationsmodus befinden und über "bootflash:/packages.conf" gestartet werden (siehe Schritt 3).

CLI-Befehl:

show version | i Installation mode

Erwartete Ausgabe:

WLC#show version | i Installation mode

Installation mode is INSTALL

Schritt 3: Überprüfen Sie die Datei, die zum Booten verwendet wird ("packages.conf")

Wenn sich der Controller im INSTALLATIONSMODUS befindet, muss er von der Datei "packages.conf" booten.

CLI-Befehl:

show boot

Erwartete Ausgabe:

WLC#show boot

BOOT variable = bootflash:packages.conf,12;

CONFIG_FILE variable =

BOOTLDR variable does not exist

Configuration register is 0x102

Standby BOOT variable = bootflash:packages.conf,12;

Standby CONFIG_FILE variable =

Standby BOOTLDR variable does not exist

Standby Configuration register is 0x102

Schritt 4: Überprüfung der Redundanzstatus

Der aktive Controller muss sich im ACTIVE und der Standby-Controller muss sich im STANDBY-HOT Status, d. h., dass die Kommunikation aktiv ist und dass sie miteinander kommunizieren.

CLI-Befehl:

show chassis rmi

show redundancy

Erwartete Ausgabe:

WLC#show chassis rmi

Chassis/Stack Mac Address : 000c.29c4.caff - Local Mac Address

Mac persistency wait time: Indefinite

H/W   Current

Chassis#   Role    Mac Address     Priority Version  State                 IP                RMI-IP

--------------------------------------------------------------------------------------------------------

*1       Active   000c.29c4.caff     2      V02     Ready                169.254.10.9       198.19.10.9

2       Standby  000c.29d2.4018     1      V02     Ready                169.254.10.10      198.19.10.10

WLC#show redundancy

Redundant System Information :

------------------------------

...

Hardware Mode = Duplex

Configured Redundancy Mode = sso

Operating Redundancy Mode = sso

Maintenance Mode = Disabled

Communications = Up

Current Processor Information :

-------------------------------

Active Location = slot 1

Current Software state = ACTIVE

...

Peer Processor Information :

----------------------------

Standby Location = slot 2

Current Software state = STANDBY HOT

...

Schritt 5: Überprüfen Sie, ob der Bootflash genügend Speicherplatz für das neue Image bietet.

A *.bin Die Bildgröße beträgt etwa 1 GB. Stellen Sie sicher, dass Sie mehrere GB freien Speicherplatz im Bootflash haben, bevor Sie fortfahren.

CLI-Befehl:

dir bootflash:/ | in free

Erwartete Ausgabe:

WLC#dir bootflash:/ | in free

14785671168 bytes total (11446026240 bytes free)

Schritt 6: Vergewissern Sie sich, dass kein anderes Upgrade ausgeführt wird.

Dies ist ein wichtiger Schritt, denn wenn der Controller bei einem vorherigen Upgrade feststeckt, schlägt das neue Upgrade fehl.

CLI-Befehl:

show issu state detail

Erwartete Ausgabe:

WLC#show issu state detail

Current ISSU Status: Enabled

Previous ISSU Operation: N/A

=======================================================

System Check                        Status

-------------------------------------------------------

Platform ISSU Support               Yes

Standby Online                      Yes

Autoboot Enabled                    Yes

SSO Mode                            Yes

Install Boot                        Yes

Valid Boot Media                    Yes

Operational Mode                    HA-REMOTE

=======================================================

No ISSU operation is in progress

Upgrade-Prozedur

Nachdem alle Prüfungen bestanden wurden, können wir nun mit dem Upgrade der Wireless-Controller fortfahren. Sie können die Controller entweder über die grafische Benutzeroberfläche oder die Kommandozeile aktualisieren. Beide Verfahren weisen Vor- und Nachteile auf. CLI gibt Ihnen mehr Kontrolle, da Sie jeden Schritt einzeln starten können. Dies erfordert jedoch etwas mehr Arbeit als ein Upgrade über die GUI. Ein Upgrade des Controllers über die GUI kann mit einem einzigen Tastendruck erfolgen, und alle Schritte werden automatisch ausgeführt. Wenn jedoch während des Upgrades ein Fehler auftritt, müssen Sie die CLI aufrufen, um den betreffenden fehlgeschlagenen Schritt erneut zu starten. In diesem Handbuch wird nur das CLI-Upgrade-Verfahren beschrieben, da GUI-Verfahren durch einfaches Ausführen der GUI-Anweisungen durchgeführt werden können.

ISSU-CLI-Workflow

Dieser Abschnitt zeigt eine kurze Zusammenfassung der Befehle, die zum Upgrade der Controller ausgeführt wurden. Es wird eine vollständige Erläuterung der einzelnen Befehle und aller Schritte bereitgestellt:

Command

Beschreibung

install add file <Datei>

Das von CCO auf den Bootflash heruntergeladene Image wird auf den Controller geladen und zu Paketen erweitert.

Vordownload des AP-Image

AP-Images, die dem v2-Image entsprechen, werden vorab auf APs heruntergeladen.

install activate issu [auto-abort-timer <30-1200>]

ISSU-Orchestrierung des einen WLC-Reloads gefolgt vom anderen. Der Aktivierungs-Trigger setzt den Access Point gestaffelt zurück, wobei nach bestem Bemühen versucht wird, die Verbindung für die Clients beizubehalten.

installieren/übernehmen

Der Commit macht die Änderungen permanent

Vollständiger Vorgang

Schritt 1: Löschen der AP-Vorabdownload-Statistiken

Es ist am besten, diese Statistiken vor dem Upgrade zu löschen, damit Sie eine neue Ausgabe erhalten, die sich nur auf das aktuelle Upgrade bezieht. Vor dem Starten des Upgrades darf kein Pre-Download durchgeführt werden.

CLI-Befehl:

clear ap predownload statistics

show ap image

Erwartete Ausgabe:

WLC#show ap image

Total number of APs  : 2

Number of APs

Initiated                  : 0

Downloading                : 0

Predownloading             : 0

...

Predownload in progress    : No

Schritt 2: Entfernen des vorherigen Software-Images

Falls nicht genügend Speicherplatz im Bootflash vorhanden ist, können Sie die alten Installationsdateien immer mit dem Befehl install remove inactive bereinigen.

CLI-Befehl:

install remove inactive

Schritt 3: Konfigurieren des Werts des Prozentsatzes für das fortlaufende AP-Upgrade

Sie können diesen Wert auf bis zu 25 % (Maximalwert) festlegen. Beachten Sie, dass bei Auswahl von 5 % (Mindestwert) weniger Access Points pro Iteration aktualisiert werden und das Upgrade länger dauert. Dies trägt jedoch auch zur Reduzierung der globalen Ausfallzeiten bei. Wählen Sie diesen Wert entsprechend Ihrer Bereitstellung und Ihrer AP-Abdeckung aus.

CLI-Befehl:

conf t

ap upgrade staggered {5 | 15 | 25 | one-shot}

end

write memory

Schritt 4: Herunterladen des .bin-Image auf den Controller

Sie können dieses Bild entweder über die Kommandozeile oder die Benutzeroberfläche hochladen. Mit der GUI geschieht dies, wenn Sie den Upgrade-Prozess starten.

CLI-Befehl:

dir bootflash:*.bin

[OPTIONAL] copy ftp://

:

@

/

bootflash:

Schritt 5: Installieren des Images

Mit diesem Schritt wird die erste Phase des Upgrades eingeleitet. Das Controller-Software-Image wird dem Flash-Speicher hinzugefügt und in Pakete erweitert. Das muss ein paar Minuten dauern. Überprüfen Sie nach Abschluss des Installationsvorgangs, ob das neue Image im Befehl "show install summary" als "Inaktiv" angezeigt wird.

CLI-Befehl:

install add file bootflash:

show install summary

Erwartete Ausgabe:

WLC#show install summary

[ Chassis 1/R0 2/R0 ] Installed Package(s) Information:

State (St): I - Inactive, U - Activated & Uncommitted,

C - Activated & Committed, D - Deactivated & Uncommitted

--------------------------------------------------------------------------------

Type  St   Filename/Version

--------------------------------------------------------------------------------

IMG   C    17.09.04a.0.6

IMG   I    17.12.02.0.2739

Schritt 6: Image auf die APs vorab herunterladen

Vor der Aktivierung des Images müssen wir die Access Points anweisen, das derzeit inaktive Image (V2) vorab herunterzuladen. Wenn der Vorabdownload nicht initiiert wird, schlägt das ISSU-Upgrade fehl, da dies ein erforderlicher Schritt zur Minimierung der Ausfallzeiten ist. Dieser Vorgang kann je nach Anzahl der mit dem Controller verbundenen APs und der Verbindungslatenz mehrere Minuten dauern.

CLI-Befehl:

ap image predownload

show ap image

Erwartete Ausgabe:

WLC#show ap image

Total number of APs  : 2

Number of APs

Initiated                  : 0

Downloading                : 0

Predownloading             : 2

Completed downloading      : 0

Completed predownloading   : 0

Not Supported              : 0

Failed to Predownload      : 0

Predownload in progress    : Yes

Schritt 7: Aktivieren des neuen Bilds

Sobald der Pre-Download beendet ist, können Sie das neue Image aktivieren. Dies ist der längste Schritt des Upgrade-Prozesses. Es führt Kompatibilitätsprüfungen durch, installiert das Paket und aktualisiert die Paketstatusdetails. Optional können Sie das Zeitlimit für das Abbrechen des Hinzufügens neuer Software festlegen, ohne das Image zu bestätigen. Gültige Werte liegen zwischen 30 und 1200 Minuten. Der Standardwert ist 360 Minuten (6 Stunden). Sobald Sie das Upgrade starten, findet der gesamte ISSU-Prozess statt: Standby-Upgrades, Switchover, dann neue Standby-Upgrades und dann das gestaffelte AP-Upgrade.

CLI-Befehl:

install activate issu [auto-abort-timer <30-1200 mins>]

Erwartete Ausgabe:

WLC#install activate issu

install_activate: START Sun Jan 14 08:29:36 EST 2024

install_activate: Activating ISSU

NOTE: Going to start Activate ISSU install process

STAGE 0: System Level Sanity Check

===================================================

--- Verifying install_issu supported ---

--- Verifying standby is in Standby Hot state ---

--- Verifying booted from the valid media ---

--- Verifying AutoBoot mode is enabled ---

--- Verifying Platform specific ISSU admission criteria ---

--- Verifying Image ISSU Compatibility ---

Finished Initial System Level Sanity Check

STAGE 1: Installing software on Standby

===================================================

--- Starting install_remote ---

[2] install_remote package(s) on chassis 2/R0

WARNING: Found 1545 disjoint TDL objects.

[2] Finished install_remote on chassis 2/R0

install_remote: Passed on [2/R0]

Finished install_remote

STAGE 2: Restarting Standby

===================================================

--- Starting standby reload ---

Finished standby reload

--- Starting wait for Standby to reach terminal redundancy state ---

Finished wait for Standby to reach terminal redundancy state

STAGE 3: Installing software on Active

===================================================

--- Starting install_active ---

WARNING: Found 2969 disjoint TDL objects.

[1] install_active package(s) on chassis 1/R0

[1] Finished install_active on chassis 1/R0 install_active: Passed on [1/R0]

Finished install_active

STAGE 4: Restarting Active (switchover to standby)

===================================================

--- Starting active reload ---

New software will load after reboot process is completed

Es empfiehlt sich, den aktuellen Status des Upgrades regelmäßig mit den Befehlen "show chassis rmi" und "show redundancy" zu überwachen. Dies zeigt Ihnen, sobald ein Controller aus dem HA-Paar entfernt wurde und wann er zurückkommt und für welche Version. Beachten Sie, dass der Vorgang etwa 20 bis 30 Minuten dauern kann.

Sobald das Upgrade abgeschlossen ist, wird das Image als aktiv, aber "nicht aktiviert" angezeigt:

WLC#show install summary

[ Chassis 1/R0 2/R0 ] Installed Package(s) Information:

State (St): I - Inactive, U - Activated & Uncommitted,

C - Activated & Committed, D - Deactivated & Uncommitted

--------------------------------------------------------------------------------

Type  St   Filename/Version

--------------------------------------------------------------------------------

IMG   U    17.12.02.0.2739

--------------------------------------------------------------------------------

Auto abort timer: active , time before rollback - 05:23:37

--------------------------------------------------------------------------------

Nach Abschluss der Installation lädt der WLC die APs gestaffelt neu. Um das AP-gestaffelte Upgrade zu überwachen, können Sie die grafische Benutzeroberfläche (unter "AP Upgrade Statistics" im Abschnitt "Software Upgrade") oder den CLI-Befehl "show ap uptime" verwenden, der die CAPWAP-Betriebszeit der APs anzeigt. Dies gibt einen Hinweis darauf, welche Access Points bereits neu geladen wurden. Sie können auch überprüfen, ob das AP-Upgrade abgeschlossen ist, indem Sie die Protokolle mithilfe des Befehls "show logging" auf dem Controller überprüfen:

Jan 20 14:23:22.478: %UPGRADE-6-STAGGERED_UPGRADE_COMPLETE: Chassis 2 R0/0: wncmgrd: Staggered AP Upgrade completed succesfully

Schritt 8: [OPTIONAL] Beenden des Zeitgebers für den automatischen Abbruch

Falls Sie mehr Zeit als die Standardzeit von 6 Stunden für das Upgrade benötigen (wenn Sie viele APs für das Upgrade haben und sicherstellen möchten, dass dies einwandfrei funktioniert, bevor Sie das Image bestätigen), können Sie diesen Timer stoppen. Auf diese Weise findet kein automatisches Rollback statt.

CLI-Befehl:

install auto-abort-timer stop

Schritt 9: Dauerhafte Gestaltung der neuen Software

Bestätigen Sie die Aktivierungsänderungen mit dem Befehl install commit so, dass sie bei allen Neuladevorgängen beständig sind. Dies ist der letzte Schritt eines normalen Upgrade-Prozesses. Der Befehl install commit sorgt dafür, dass Software bei Neustarts erhalten bleibt.

CLI-Befehl:

install commit

Erwartete Ausgabe:

WLC#show install summary

[ Chassis 1/R0 2/R0 ] Installed Package(s) Information:

State (St): I - Inactive, U - Activated & Uncommitted,

C - Activated & Committed, D - Deactivated & Uncommitted

--------------------------------------------------------------------------------

Type  St   Filename/Version

--------------------------------------------------------------------------------

IMG   C    17.12.02.0.2739

Sobald die Version festgeschrieben und die Access Points auf der neuen Version neu geladen wurden, ist das ISSU-Upgrade abgeschlossen.

Zusätzliche Betriebsabläufe

Es gibt einige weitere Vorgänge, die Sie möglicherweise während oder nach dem ISSU-Upgrade durchführen müssen, z. B. das Abbrechen des Upgrades oder das Rollback auf eine vorherige Version:

ISSU-Abbruch

Mit diesem Schritt wird der bisher durchgeführte Upgrade-Prozess abgebrochen und das Gerät in ISSU-Form auf den vorherigen Installationsstatus (V1) zurückgesetzt. Dies gilt sowohl für die Controller als auch für die APs. Dies kann durchgeführt werden, wenn Sie eine schwerwiegende Auswirkung auf das Upgrade feststellen und wenn Sie das Image noch nicht bestätigt haben. Dieser Befehl und Prozess funktioniert nur, wenn "install commit" noch nicht ausgegeben wurde. Sobald das Image aktiviert wurde, kann kein Rollback auf ISSU-Art durchgeführt werden.

CLI-Befehl:

install abort issu

Erwartete Ausgabe:

STAGE 1: Rolling Back software on Standby

===================================================

--Starting Deactivation at the standby --

--- Starting abort_standby ---

[1] abort_standby package(s) on chassis 1/R0

WARNING: Found 1545 disjoint TDL objects.

[1] Finished abort_standby on chassis 1/R0

abort_standby: Passed on [1/R0]

Finished abort_standby

STAGE 2: Restarting Standby

===================================================

--- Starting standby reload ---

Finished standby reload

--- Starting wait for Standby to reach terminal redundancy state ---

Finished wait for Standby to reach terminal redundancy state

STAGE 3: Rolling Back software on Active

===================================================

--Starting Deactivation at the active --

--- Starting abort_active ---

WARNING: Found 1545 disjoint TDL objects.

[2] abort_active package(s) on chassis 2/R0

[2] Finished abort_active on chassis 2/R0

abort_active: Passed on [2/R0]

Finished abort_active

STAGE 4: Restarting Active (switchover to standby)

===================================================

--- Starting active reload ---

New software will load after reboot process is completed

SUCCESS: install_abort  Wed Jan 17 21:58:52 CET 2024

client_loop: send disconnect: Broken pipe

Umschalten auf den "primären" Controller

In einer Produktionsumgebung kann dieser Schritt gewünscht werden, wenn der ursprüngliche Controller wieder aktiv sein soll. Denken Sie daran, dass nach Abschluss des ISSU-Upgrades die "sekundäre" Einheit der aktive Controller ist. Sie können jederzeit den ursprünglichen Zustand wiederherstellen, indem Sie einen manuellen Switchover durchführen. Sie müssen sicherstellen, dass sich das Peer-Gerät im "Standby Hot"-Zustand befindet, bevor Sie fortfahren.

CLI-Befehl:

redundancy force-switchover

Rollback zum vorherigen Status nach Abschluss des ISSU-Upgrades

Nach Abschluss des Upgrades wird ISSU-Downgrade für Cisco Catalyst Wireless Controller der Serie 9800 nicht mehr unterstützt. Zu diesem Zeitpunkt bedeutet ein Rollback, dass sowohl Wireless-Controller als auch Access Points aufgrund der Codeänderung neu geladen werden. Dies führt zu Ausfallzeiten. Sie können zunächst die verfügbaren Rollbackpunkte überprüfen und dann entscheiden, zu welchem Rollback durchgeführt werden soll.

CLI-Befehl:

show install rollback

show install rollback id

install rollback to id

Erwartete Ausgabe:

WLC#sh install rollback

ID      Label                            Description

-------------------------------------------------------

3       No Label                         No Description

2       No Label                         No Description

1       No Label                         No Description

WLC#sh install rollback id 2

Rollback id - 2 (Created on 2024-04-22 10:31:57.000000000 +0000)

Label: No Label

Description: No Description

Reload required: NO

State (St): I - Inactive, U - Activated & Uncommitted,

C - Activated & Committed, D - Deactivated & Uncommitted

--------------------------------------------------------------------------------

Type  St   Filename/Version

--------------------------------------------------------------------------------

IMG   C    17.09.04a.0.6

WLC#install rollback to id 2

install_rollback: START Thu May 30 09:44:38 UTC 2024

install_rollback: Rolling back to id 2

This operation may require a reload of the system. Do you want to proceed? [y/n]y

--- Starting Rollback ---

Performing Rollback on all members

[2] Rollback package(s) on Chassis 2/R0

[1] Rollback package(s) on Chassis 1/R0

[2] Finished Rollback package(s) on Chassis 2/R0

Checking status of Rollback on [1/R0 2/R0]

Rollback: Passed on [1/R0 2/R0]

Finished Rollback operation

SUCCESS: install_rollback Thu May 30 09:45:40 UTC 2024

Fehlerbehebung

Falls Sie vor, während oder nach dem Upgrade der Wireless-Controller der Serie 9800 mit ISSU mit einem Problem konfrontiert werden, empfehlen wir Ihnen, dieses Dokument durchzugehen, in dem die häufigsten auftretenden Probleme und deren Lösungen erläutert werden.

Referenzen

- Hohe Verfügbarkeit durch Patching und Rolling AP-Upgrades auf Cisco Catalyst Wireless Controllern der Serie 9800

- 17.12.X Konfigurationsleitfaden