Welche Cisco-IOS-XE-Version Sie fahren sollten — und warum „die neueste“ die falsche Regel ist

Die Frage nach der richtigen Softwareversion beantworten Netze meist auf eine von zwei Arten: Man bleibt auf dem Stand der Inbetriebnahme, bis etwas dagegen spricht, oder man nimmt bei jeder Gelegenheit die neueste. Beide Antworten sind Vermeidungsstrategien — die eine vermeidet Änderung, die andere vermeidet Entscheidung.

Jeder Zug hat zwei Enden

Der wichtigste und am häufigsten übersehene Punkt ist, dass „Support“ zwei verschiedene Dinge bedeutet. Die Wartungsreleases bringen Fehlerkorrekturen im weiteren Sinne. Der Sicherheitssupport deckt nur noch Korrekturen für Schwachstellen ab und läuft laut Ciscos End-of-Life-Bulletins anderthalb Jahre länger. Ein halbes Jahr danach folgt der Last Date of Support, ab dem es für den Zug keinerlei Unterstützung mehr gibt.

Zwischen dem Ende der Wartung und dem Ende des Sicherheitssupports befindet sich ein Zug in einem Zustand, den man kennen sollte: Sicherheitslücken werden noch geschlossen, ein Fehler in der Funktion aber nicht mehr. Für ein produktives Campus-Netz ist das keine komfortable Lage — sie ist zulässig, aber sie sollte eine Entscheidung sein und kein Zufall.

Für 17.18 hat Cisco mit Stand 25. September 2026 noch kein End-of-Life-Bulletin mit Einzelterminen veröffentlicht. Als Extended-Support-Release hat der Zug laut Cisco 48 Monate ab Erstauslieferung. Die Releases dazwischen — 17.10, 17.11, 17.13, 17.14, 17.16, 17.17 — sind Standard-Support-Releases mit zwölf Monaten. Sie sind für Netze gedacht, die eine bestimmte neue Funktion früh brauchen, nicht als Dauerzustand.

IOS XE 26: Jedes Release wird langlebig

Mit 26.1.1 hat Cisco das Modell umgestellt. Die Hauptnummer ist jetzt das Kalenderjahr — 26 steht für 2026. Es erscheinen zwei Releases pro Jahr im Abstand von etwa sechs Monaten, und jedes davon ist ein Extended-Support-Release mit 48 Monaten ab allgemeiner Verfügbarkeit. Die Unterscheidung „langlebig oder kurzlebig“ entfällt damit für neue Releases.

Die Frage „welches Release und bis wann?“ bleibt trotzdem. Für Catalyst 9200 bis 9600 empfiehlt Cisco mit Stand 4. September 2026 weiterhin 17.18.4 und 17.15.6; eine Empfehlung für 26.x steht dort noch nicht. Wer heute plant, plant also noch auf 17.x und bereitet den Wechsel auf 26 vor.

Zu dieser Vorbereitung gehört ein Punkt, der sonst überrascht: Ab 17.18.2 warnt IOS XE bei Konfigurationen, die Cisco als unsicher einstuft; ab 26.1.1 schränkt es sie ein. Ein Gerät, das mit solchen Befehlen auf 26 aktualisiert wird, schaltet laut Cisco automatisch in den Modus „system mode insecure“, damit nichts ausfällt — gehärtet ist es damit nicht. Ein neues Gerät ohne Startkonfiguration lehnt dieselben Befehle dagegen ab; eine Vorlage aus dem Altbestand scheitert dann ausgerechnet beim Gerätetausch. Welche Befehle Cisco als unsicher führt, zeigt „show system insecure profile“, welche davon ein Gerät tatsächlich nutzt, ab 26.1.1 „show system insecure configuration“. Den Modus verlassen kann ein Gerät erst, wenn alle unsicheren Konfigurationen entfernt sind.

Warum „die neueste“ die falsche Regel ist

Bis 17.18 war die jeweils neueste Version selten ein langlebiger Zug. Ab 26 ist sie es formal immer — aber sie ist weiterhin am wenigsten erprobt. Ein Campus-Netz braucht keine frühe Funktion, sondern Vorhersagbarkeit: dieselbe Version auf möglichst vielen Geräten, über einen Zeitraum, der lang genug ist, dass man das Verhalten kennt.

Die brauchbare Regel besteht deshalb aus drei Bedingungen. Erstens: ein langlebiger Zug — bis 17.18 jeder dritte, ab 26 jedes Release. Zweitens: nicht der neueste, sondern einer mit Betriebserfahrung, der trotzdem noch Jahre an Wartung vor sich hat. Drittens: der Wechsel wird geplant, bevor die Wartungsreleases enden, nicht danach.

Eine Ausnahme gibt es regelmäßig: eine Funktion, die man wirklich braucht und die nur in einem neueren Zug existiert. Dann ist die Entscheidung vertretbar — aber sie ist eine Ausnahme mit Begründung und nicht die Regel.

Wie ein Wechsel abläuft, der nicht wehtut

1. 01

   Bestandsaufnahme

   Welches Gerät fährt welche Version? Nicht aus der Dokumentation, sondern aus dem Netz gelesen. Fast jede Bestandsaufnahme fördert mindestens einen Zug zutage, von dem niemand wusste, dass er noch läuft.

2. 02

   Zielversion festlegen

   Ein Zug für die gesamte Plattformklasse, begründet gegen die Support-Enden. Zwei Zielversionen im selben Campus sind manchmal nötig, drei sind ein Symptom.

3. 03

   Testpfad

   Ein Gerät je Bauart und Rolle, in einer Umgebung, in der ein Fehler nichts kostet. Geprüft wird nicht nur der Start, sondern das, was Ihr Netz tatsächlich nutzt: Authentisierung, Sprach-VLAN, Multicast, Stacking, Uplink-Verhalten — beim Sprung auf 26 zusätzlich die als unsicher eingestuften Befehle.

4. 04

   Gestaffelter Rollout

   Erst eine unkritische Fläche, dann eine Etage, dann der Rest — mit definierten Beobachtungszeiträumen dazwischen. Ein Rollout ohne Pausen ist ein Rollout ohne Abbruchmöglichkeit.

5. 05

   Nachweis und Wiederholbarkeit

   Der Stand nach dem Rollout wird erfasst und gegen den Sollzustand geprüft. Was einmal als Ablauf beschrieben ist, kostet beim nächsten Zug einen Bruchteil.

Für Umgebungen mit einem Netzwerk-Controller ist die Softwareverteilung genau die Aufgabe, für die er gebaut ist: Zielabbild festlegen, Abweichung sichtbar machen, gestaffelt verteilen, Ergebnis protokollieren. Wie wir das aufsetzen, steht unter Cisco Catalyst Center; die Einordnung in den Gesamtbetrieb unter Unternehmensnetze.

Warum das gerade jetzt zählt

Drei Entwicklungen treffen aufeinander. Erstens endet der Sicherheitssupport für 17.9 am 30. September 2026, und 17.12 hat seine Wartungsreleases seit dem 30. März 2026 hinter sich — beides Züge, die in vielen Netzen noch laufen. Zweitens hat Cisco am 5. August 2026 ein Hardening-Release für IOS XE veröffentlicht: Schwachstellen bis CVSS 9.8, ohne Workaround, behoben in 17.9.10, 17.12.8, 17.15.6, 17.18.4 und 26.1.2. Drittens macht IOS XE 26 aus der Zugwahl eine Frage des Zeitpunkts statt der Kadenz.

Solche Veröffentlichungen sind inzwischen planbar: Seit Juli reserviert Cisco den ersten und dritten Mittwoch im Monat für gehärtete Softwarestände und nennt die betroffenen Plattformen sieben Tage vorher. Wer Wartungsfenster daran ausrichtet, patcht nach Plan statt nach Schlagzeile.

Die Bestandsaufnahme ist deshalb der lohnendste erste Schritt. Sie kostet einen Tag und beantwortet die Frage, ob Sie ein Planungsthema haben oder ein akutes. Für Plattformen, die gar kein aktuelles IOS XE mehr bekommen, gehört der Austausch in dieselbe Liste — dazu unser Ablöseplan für Catalyst 2960-X und 3650.