Upgrade-Readiness Check: Kompatibilität, Feature Parity, Downgrade Plan

Ein Upgrade ist erst dann „ready“, wenn drei Fragen mit Fakten beantwortet sind: (1) Ist die Zielversion kompatibel mit Hardware und Betriebsmodus? (2) Gibt es Feature Parity, also funktionieren alle benötigten Funktionen nach dem Upgrade identisch oder mit akzeptierten Änderungen? (3) Gibt es einen getesteten Downgrade-/Rollback-Plan, der innerhalb des Maintenance Windows realistisch ist? Dieser Readiness-Check ist als praxisorientierte Checkliste gedacht, die du vor IOS XE Upgrades konsequent abarbeitest – unabhängig davon, ob du ISSU oder klassisches Reload-Upgrade nutzt.

Readiness in 3 Säulen: Kompatibilität, Feature Parity, Downgrade

Viele Upgrade-Probleme entstehen, weil nur „Image passt auf Flash“ geprüft wurde. Betriebsfähigkeit bedeutet aber mehr: Module, Lizenzen, Install-Mode, HA-Topologie und Feature-Interaktionen.

• Kompatibilität: Plattform, Mode, Packages, Speicher, Boot-Parameter
• Feature Parity: Routing, VPN, NAT, QoS, Telemetrie, HA, Security
• Downgrade Plan: definierter Rückfall mit klarer Entscheidungsschwelle

Kompatibilität prüfen: Hardware, Mode, Speicher, Boot

Kompatibilität bedeutet: Die Zielversion ist für dein Modell, deine Module und deinen Betriebsmodus freigegeben. Zusätzlich müssen Speicher und Boot-Mechanismus passen. In IOS XE ist Install-Mode in der Praxis Standard für kontrollierbare Upgrades.

1) Plattform und aktuelle Version dokumentieren

show version
show platform
show inventory
show boot

2) Install-Mode/Packages prüfen

Für Install-Mode-Upgrades ist es wichtig zu wissen, ob du über packages.conf bootest und ob dein Install-Status sauber ist.

show install summary
dir bootflash:
dir flash:

3) Speicher und freie Kapazität prüfen

dir bootflash:
show file systems

4) Lizenz-/Feature-Bindings prüfen (falls relevant)

Bei IOS XE Plattformen können Lizenzen/Feature-Sets Einfluss auf Feature-Verfügbarkeit haben. Prüfe vorab, ob benötigte Lizenzen aktiv sind.

show license summary
show license status

Kompatibilität in der Praxis: typische Stopper

Diese Punkte sind häufige „Upgrade Killer“, weil sie im Change-Fenster plötzlich sichtbar werden.

• Zu wenig Flash/bootflash für Image + Install-Packages
• Falscher Boot-Mode (Bundle vs. Install) für geplanten Upgrade-Pfad
• HA/Redundancy nicht wie angenommen (Active/Standby Rollen)
• Hardware-Module benötigen spezielle Mindestversionen

Feature Parity prüfen: „Was muss nach dem Upgrade funktionieren?“

Feature Parity ist eine strukturierte Anforderungsliste: Welche Funktionen nutzt der Router wirklich? Danach definierst du Testfälle (Pre-/Post-Checks), die diese Funktionen beweisen. Das verhindert, dass du „erfolgreich upgraded“ hast, aber VPN oder QoS danach subtil kaputt ist.

Feature-Inventar erstellen (schnell per Show/Sections)

show running-config | section router
show running-config | section crypto
show running-config | include ip nat|route-map|policy-map|class-map
show running-config | include snmp-server|logging|ntp
show running-config | section control-plane

Typische Feature-Gruppen für Router-Readiness

• Routing: Static, OSPF/EIGRP/BGP, Redistribution, Summaries
• WAN/Edge: PPPoE, NAT/PAT, Dual-WAN Tracking, PBR
• Security: ACL/ZBF, CoPP, uRPF, Management ACL
• VPN: IKE/IPsec, GRE/DMVPN, MTU/MSS
• QoS: Shaping, LLQ/CBWFQ, WRED/Policing
• Observability: Syslog, SNMPv3, NetFlow/Telemetry

Feature Parity Tests: Pre-Checks als messbare Post-Checks definieren

Jeder relevante Service braucht einen messbaren Test. Das ist dein „Definition of Done“. Ohne diese Tests ist ein Downgrade-Entscheid im Incident unklar.

Routing/Internet Tests

show ip route | include Gateway|0.0.0.0
show ip cef 8.8.8.8
ping 8.8.8.8 source <wan-ip>
traceroute 8.8.8.8 source <wan-ip>

OSPF/BGP Tests (falls genutzt)

show ip ospf neighbor
show ip bgp summary

VPN Tests (falls genutzt)

show crypto isakmp sa
show crypto ipsec sa

QoS Tests (falls genutzt)

show policy-map interface <wan-interface>

Observability Tests

show logging | last 50
show snmp user
show ntp status

Downgrade-Plan: Rollback ist nicht „Reload und gut“

Downgrade bedeutet: du kannst kontrolliert auf die vorherige Version zurück, ohne Konfigverlust und innerhalb deines Zeitfensters. In Install-Mode ist dafür entscheidend, dass du vor dem Commit testest und dass du die vorherige Software/Packages verfügbar hast.

• Rollback-Fenster: nach Activate testen, erst dann Commit
• Known-good Startup-Config ist Pflicht (vorher speichern)
• OOB/Console bereit: Downgrade ohne Management-Lockout

Konfig- und Image-Backup vor dem Upgrade

copy running-config startup-config
copy running-config scp:
copy startup-config scp:

Abbruchkriterien (Beispiele)

• BGP/OSPF Neighbors kommen nicht stabil hoch
• VPN SAs bauen nicht auf oder Counters bleiben 0
• CPU/Memory ungewöhnlich hoch nach Upgrade
• Interface Errors/Drops steigen signifikant

Operational Guardrails: Was ein Upgrade „betriebssicher“ macht

Readiness ist nicht nur Technik. Die wichtigsten Risikosenker sind klarer Ablauf, Pilotierung und Observability, damit du im Change-Fenster nicht blind bist.

• Pilotgruppe vor Massenrollout (ein Standort/Cluster)
• Maintenance Window in Phasen: Pre → Upgrade → Post → Observe
• Monitoring während Upgrade: Syslog, CPU, Interfaces, Neighbors
• Keine Parallel-Changes (Freeze), klare Owner/Rollen

Readiness Quick-Checklist (Copy & Paste)

Diese Checkliste ist die kurze Version, die du im Change-Ticket abhaken kannst.

• Kompatibilität: Plattform/Module, Speicher, Boot/Install-Mode, Lizenzstatus geprüft
• Feature-Inventar: Routing/VPN/NAT/QoS/CoPP/Telemetry erfasst
• Pre-Checks dokumentiert: Version, Routen, Neighbors, VPN, QoS, Logs
• Rollback: Config + Images gesichert, OOB/Console verfügbar
• Post-Checks definiert: messbare Tests je Feature
• Abbruchkriterien: klar, zeitlich begrenzt, Entscheidungsbefugnis geklärt

Command Pack: Pre-Checks in einem Block

show clock
show version
show platform
show inventory
show boot
show install summary
show license summary
show ip interface brief
show interfaces | include CRC|drops|error
show ip route | include Gateway|0.0.0.0
show ip ospf neighbor
show ip bgp summary
show crypto isakmp sa
show crypto ipsec sa
show policy-map interface <wan-interface>
show policy-map control-plane
show logging | last 100
copy running-config startup-config

Konfiguration speichern

copy running-config startup-config

Konfiguriere Cisco Router & Switches und liefere ein Packet-Tracer-Lab (CCNA)

Hallo! Ich bin ein CCNA-Network Engineer und unterstütze Sie bei Cisco Router- und Switch-Konfigurationen – inklusive eines vollständigen Cisco Packet-Tracer-Labs (.pkt). Ideal für Lern-/Übungsszenarien, Validierung oder eine saubere Demo-Topologie.

Was ich (je nach Paket) umsetze

• Switching: VLANs, Trunking (802.1Q), Port-Zuweisung, STP-Basics (PortFast/BPDU Guard wo sinnvoll)

• Routing: Default/Static Routing oder OSPF, Inter-VLAN Routing (Router-on-a-Stick)

• Services: DHCP (Pools/Scopes), NAT/PAT für Internet-Simulation

• Optional Security: Basic ACLs und SSH-Hardening

• Test & Verifikation: Ping/Traceroute + wichtige Show-Commands (mit erwarteten Ergebnissen)

Sie erhalten

• ✅ Packet Tracer .pkt Datei

• ✅ Saubere Konfigurations-Notizen pro Gerät

• ✅ Verifikations-Checkliste + erwartete Outputs

• ✅ Kurze Dokumentation (wie die Topologie funktioniert)

Bitte schreiben Sie mir vor der Bestellung, damit wir Scope, Packet-Tracer-Version, Geräteanzahl und Deadline klären.

Konfiguriere Cisco Router & Switches | Cisco Packet-Tracer-Labs. Finden Sie mich auf Fiverr.