Catalyst Center 2.3.7: Die Wartung endet im Dezember, der Weg auf 3.x ist eine Einbahnstraße

Eine Catalyst-Center-Installation, die läuft, meldet ihr Supportende nicht. Der Termin steht in einer Tabelle von Cisco, und die Antwort darauf ist diesmal mehr als ein Patch: Der Schritt auf 3.x wechselt die Architektur, berührt die Hardwarefrage und bringt Funktionen mit, die Daten an Cisco-Clouddienste senden können.

Was der 17. Dezember bedeutet

Ciscos Richtlinie für Catalyst-Center-Releases kennt zwei Enden. Nach dem Ende der Softwarewartung veröffentlicht Cisco für ein Release keine Wartungsreleases oder Fehlerkorrekturen mehr; die Software wird nicht mehr entwickelt, repariert oder getestet. Nach dem letzten Supporttag sind alle Supportleistungen dafür nicht mehr verfügbar. Als Regel nennt die Richtlinie zwölf Monate nach der Freigabe für das erste und 24 Monate für das zweite Datum.

Die Tabelle reicht bis 2.1.2.x zurück; für jedes Release vor 2.3.7 ist auch der letzte Supporttag vorbei. Maßgeblich ist das Datum in der Tabelle, nicht eine selbst gerechnete Frist. Für 3.x enthält sie (Stand 16. März 2026) noch keine Einträge — das Wartungsende der Zielversion ist deshalb vor der Versionswahl mit Cisco oder dem Partner zu klären.

Der Weg auf 3.x ist eine Einbahnstraße

Für den Schritt von 2.3.7.x auf 3.1.6 hält Ciscos Upgrade-Guide drei Dinge fest: 3.1.6 basiert auf einer neuen Architektur. Der Weg dorthin führt über den Plattform-Upgrade-Workflow. Und nach dem Upgrade ist kein Wechsel zurück auf ein früheres Release möglich.

Der Guide nennt außerdem die zulässigen Ausgangsstände: bestimmte Stände der Patchreihen 2.3.7.7, 2.3.7.9, 2.3.7.10 und 2.3.7.11, jeweils mit festgelegter Build-Nummer. Wer anders steht, patcht zuerst innerhalb von 2.3.7 und vergleicht dabei die Build-Nummer mit der Liste, nicht nur die Versionsnummer.

Die Zielversion ist damit nicht automatisch die neueste. Laut Cisco stehen die 3.x-Releases an unterschiedlichen Punkten:

• 3.1.6 ist das Ziel des im Upgrade-Guide beschriebenen Schritts aus 2.3.7.x.
• 3.2.3 ist laut Release Notes allgemein verfügbar, aktuell als Wartungsupdate 3.2.3-75346.100.
• 3.3.1 ist laut Release Notes ein Controlled-Availability-Release; Zugang gibt es auf Anfrage über den Cisco-Vertrieb.

Für den Weg zu 3.2.3 oder 3.3.1 verweisen beide Release Notes auf Ciscos Upgrade-Guide; wir planen jeden Zwischenschritt gegen dieses Dokument.

Hardware oder virtuell: Die Appliance entscheidet mit

Die zweite Entscheidung betrifft die Plattform unter der Software. Die Termine der drei Appliance-Generationen liegen Jahre auseinander.

Für 3.2.3 und 3.3.1 erzwingt die Software also keinen Hardwaretausch. Die Hardwaretermine laufen trotzdem: DN2-Serviceverträge lassen sich laut Abkündigung nur bis 25. Juni 2028 verlängern. DN3 hat Cisco am 2. Juli 2026 abgekündigt, letzter Liefertermin ist der 31. März 2027; als Migrationsprodukte nennt die Ankündigung DN4-HW-APL, DN4-HW-APL-L und DN4-HW-APL-XL. Laut DN4-Datenblatt setzen diese Catalyst Center 3.3.1 oder neuer voraus — ein Release, das Cisco derzeit nur als Controlled Availability anbietet.

Die dritte Option ist die virtuelle Appliance, und hier unterscheiden sich die Angaben von Release zu Release:

• 3.1.6: laut Datenblatt VMware ESXi (vSphere 7.0.x oder neuer), AWS und Microsoft Azure; für ESXi nennt es 32 vCPUs, 256 GB RAM, 3 TB Speicher und 180 MB/s I/O-Bandbreite.
• 3.2.3: laut Release Notes nur VMware ESXi und Ubuntu KVM, jeweils on-premises.
• 3.3.1: laut Release Notes VMware ESXi on-premises und KVM (Ubuntu Native).

Wer in AWS oder Azure betreibt oder dorthin wechseln will, prüft deshalb zuerst, ob die Zielversion dort freigegeben ist. Und der Wechsel von der Appliance auf eine virtuelle Instanz ist kein Upgrade, sondern ein neues Plattformdesign.

Was 3.x laut Cisco mitbringt

Ob ein Upgrade mehr ist als eine erfüllte Frist, entscheidet sich an den Funktionen, die Sie tatsächlich einsetzen. Das Datenblatt zu 3.1.6 und die Release Notes zu 3.3.1 nennen unter anderem:

• KI-gestütztes Baselining: eine Baseline der Leistungswerte des eigenen Netzes, die sich laufend anpasst und die KI-Analytik ermöglicht.
• KI-gestützte Anomalieerkennung: Leistungsprobleme erkennen, harmlose Abweichungen ausblenden, Rauschen reduzieren.
• ThousandEyes-Agenten: direkt aus Catalyst Center auf alle unterstützten Switches ausrollen, für mehr Sicht auf die Anwendungsleistung.
• SWIM: Images, Patches und Wartungsupdates zentral verwalten; validierte Images als Standard je Gerätefamilie, Rolle oder Tag festlegen — im Betrieb meist Golden Image genannt.
• Plug and Play: Cisco-Geräte aus dem Karton werden provisioniert, indem man sie ans Netz anschließt (Zero-Touch-Deployment).
• Live Protect: laut Release Notes neu in 3.3.1; validiert Security Shields, die Cisco-Produkte ohne Neustart und ohne Dienstunterbrechung schützen.

Das Datenblatt trennt nicht zwischen neuen und vorhandenen Funktionen; was für Ihre Installation neu ist, zeigt erst der Abgleich mit dem heutigen Stand. Wir empfehlen, jede Funktion an einer Betriebsfrage zu messen: Welches heutige Problem löst sie, und braucht sie Lizenzen, eine Cloud-Anbindung oder ein Release, das Sie noch nicht haben? Live Protect etwa kommt erst mit 3.3.1.

Wie wir Assurance in den Betrieb bringen, steht unter Assurance und Fehleranalyse; welche IOS-XE-Version als Standard-Image taugt, behandelt der Beitrag zur IOS-XE-Versionsstrategie.

Der AI Assistant: erst prüfen, dann einschalten

Das Datenblatt zu 3.1.6 beschreibt den Cisco AI Assistant als Werkzeug, um Fragen zu stellen, Probleme zu analysieren und im Netz Maßnahmen auszulösen. Vor dem Einschalten zählen zwei Punkte aus Ciscos Beschreibung des Assistenten.

Erstens braucht er eine Registrierung bei Cisco Catalyst Cloud, in den Systemeinstellungen unter External Services mit einem cisco.com-Konto. Zweitens werden Kundeninhalte und Systeminformationen aus der Nutzung von Catalyst Center laut Cisco „primarily processed and stored in the United States, regardless of your physical location“ — also vorrangig in den USA verarbeitet und gespeichert, unabhängig vom Standort. Das gilt für die Eingaben ebenso wie für die Betriebsdaten, die der Assistent auswertet.

Laut Cisco werden diese Daten nicht zum Training verwendet. Der Assistent steht allen Lizenzstufen offen; seine Funktionen folgen aber den Lizenzstufen der Features, die er nutzt.

Der Upgrade-Plan: Wartungsaufgaben vor, während und nach dem Wechsel

Aus diesen Punkten ergibt sich ein Ablauf. Er beantwortet zugleich die Frage, welche Wartungsaufgaben ein Wechsel auf Catalyst Center 3.x mit sich bringt.

1. 01

   Bestand erfassen

   Release mit Build-Nummer, Appliance oder virtuelle Plattform, Einzelknoten oder Drei-Knoten-Cluster, genutzte Funktionen, Integrationen und API-Nutzer — gelesen aus der Plattform, nicht aus der Projektdokumentation.

2. 02

   Zielbild festlegen

   Zielversion, Plattform und einzuschaltende Cloud-Funktionen gemeinsam entscheiden, begründet gegen die Termine aus Richtlinie und Abkündigungen.

3. 03

   Ausgangsstand herstellen

   Liegt die Installation nicht auf einem im Upgrade-Guide gelisteten Stand, zuerst innerhalb von 2.3.7 patchen — als eigener Change mit eigener Abnahme.

4. 04

   Sichern und vorprüfen

   Vollständiges Backup mit geprüfter Wiederherstellung; Voraussetzungen und Ablauf des Upgrade-Guides für genau diesen Pfad durcharbeiten. Das Backup sichert Daten, einen Rückweg auf 2.3.7 sieht Cisco nicht vor.

5. 05

   Testen

   Den Pfad dort durchspielen, wo ein Fehler nichts kostet, und die Abnahmeprüfungen gleich mit üben.

6. 06

   Wartungsfenster und Abnahme

   Mit Puffer, Go/No-Go-Entscheidung vor dem Start und erreichbaren Verantwortlichen für ISE, ITSM und Automatisierung. Abgenommen wird der Betrieb, nicht die Versionsanzeige.

• Assurance: Health-Daten bekannter Geräte und Clients sind aktuell, ein bekannter Fehlerfall erscheint wie erwartet.
• Provisionierung: Ein Testgerät durchläuft Plug and Play bis zur freigegebenen Konfiguration.
• SWIM: Eine Image-Verteilung auf ein Pilotgerät läuft durch, die Standard-Images sind unverändert gesetzt.
• Integrationen: ISE, ITSM-Tickets und Ereignis-Abonnements funktionieren; Skripte und Pipelines laufen gegen die neue Version.

Welche Schnittstellen typischerweise daran hängen, beschreibt der Beitrag zur Catalyst-Center-API. Dauerhaft bleiben drei Aufgaben: Patchstände pflegen, die Termine von Software und Appliance verfolgen und den nächsten Wechsel planen, bevor die Wartung endet.

Wie wir Plattform-Upgrades und Softwarestände planen, steht unter SWIM und Lifecycle; ein Wechsel auf neue Hardware oder eine virtuelle Instanz gehört zu Einführung und Plattformdesign. Wenn Sie vor dem 17. Dezember eine belastbare Entscheidung brauchen, können Sie das Catalyst-Center-Upgrade mit uns besprechen.