Cisco-Router-Konfiguration: Geräte-Readiness (Lizenz, Features und Image)

Bevor Sie eine Cisco-Router-Konfiguration produktiv ausrollen, muss das Gerät „ready“ sein: korrektes Image (IOS/IOS XE), passende Lizenzen, verfügbare Features sowie ausreichende Ressourcen (CPU/Memory/Storage). In der Praxis scheitern Projekte nicht selten an scheinbaren Kleinigkeiten wie fehlendem VPN-Feature, falschem Boot-Image, abgelaufenen Lizenzen oder zu wenig Flash-Speicher für Updates. Dieser Leitfaden zeigt eine praxistaugliche Geräte-Readiness-Checkliste inklusive CLI-Checks, damit Implementierung, Abnahme und Betrieb ohne Überraschungen laufen.

Was „Geräte-Readiness“ umfasst

Readiness bedeutet, dass das Gerät den geplanten Funktionsumfang technisch und lizenzseitig abbilden kann – und dass Upgrade/Backup/Recovery im Change-Fenster sicher durchführbar sind.

• Plattform: Modell, Ports/Module, Durchsatz (NAT/VPN/QoS)
• OS/Image: IOS oder IOS XE, Version, Feature-Set
• Lizenzen: aktiv, passend für Features (z. B. Security/VPN/Routing)
• Ressourcen: CPU/Memory/Flash, optional SSD
• Betrieb: Logging/NTP, OOB/Console, Backup/Restore

Schritt 1: Plattformdaten erfassen (Hardware, Module, Ports)

Erfassen Sie zuerst die physische Basis. Gerade bei WAN-Ports, SFPs und Modulen entscheiden Details über Zeitplan und Rollout (z. B. falscher Transceiver, fehlendes LTE-Modul).

• Modell/Chassis und Seriennummer
• Interface-Typen: Kupfer/Glas, SFP-Modelle, WAN-Module
• Stromversorgung/Redundanz (wenn kritisch)
• Hardwarebeschleunigung für Crypto (plattformabhängig)

CLI: Hardware-Identifikation

show version
show inventory

Schritt 2: IOS/IOS XE Image prüfen (Version, Boot, Kompatibilität)

Das Image bestimmt Stabilität und Feature-Verfügbarkeit. Prüfen Sie Version, Boot-Konfiguration und ob das gewünschte Ziel-Image im Flash liegt. In Projekten ist das ein Pflichtpunkt vor jeder Implementierung.

• OS-Typ (IOS vs. IOS XE) und genaue Version
• Boot-Variable(n) korrekt gesetzt
• Genügend Flash für das Ziel-Image und ggf. Packages
• Upgrade-/Rollback-Plan: vorheriges Image bleibt verfügbar

CLI: Image- und Boot-Checks

show version
show boot
dir flash:

Schritt 3: Lizenzstatus prüfen (Feature-Freischaltung ist Projektkritisch)

Lizenzen sind kein „Papierkram“, sondern entscheiden über Features (z. B. Security/VPN, Advanced Routing). Prüfen Sie Lizenzstatus vor dem Go-Live, nicht erst beim Aktivieren eines Features.

• Lizenztyp und Status (aktiv, eval, abgelaufen)
• Welche Features sind lizenziert (Routing, Security, ggf. App-Hosting)
• Unternehmensstandard: Lizenznachweis als Teil der Pre-Checks

CLI: Lizenz-Checks

show license summary
show license all

Schritt 4: Feature-Readiness prüfen (Routing, VPN, NAT, QoS, HA)

Ein Router ist nur dann ready, wenn die geplanten Projektfeatures tatsächlich nutzbar sind. Prüfen Sie mindestens die Bereiche, die im Scope stehen, und testen Sie Schlüsselkomponenten in einem kontrollierten Fenster.

• Routing: Static/OSPF/EIGRP/BGP (je nach Design)
• VPN: IKEv2/IPsec, ggf. GRE/VTI/DMVPN (wenn im Scope)
• NAT: PAT/Static NAT/No-NAT für VPN
• QoS: Shaping/Policy-Maps (wenn WAN-Engpässe zu erwarten sind)
• HA: HSRP/VRRP/Tracking (wenn in der Architektur vorgesehen)

CLI: Feature-Sichtbarkeit im Ist-Zustand (runbook-tauglich)

show running-config | include router ospf|router bgp|crypto|ip nat|policy-map|standby|vrrp
show ip route
show ip nat statistics
show crypto ikev2 sa
show policy-map interface

Schritt 5: Ressourcen und Performance-Fit (CPU, Memory, Storage)

Selbst wenn Features verfügbar sind, kann das Gerät in der Praxis überfordert sein – besonders bei VPN, NAT und QoS gleichzeitig. Prüfen Sie Ressourcen und planen Sie Puffer ein.

• CPU: ausreichend Reserve im Normalbetrieb (keine Dauerlast)
• Memory: stabil, keine dauerhafte Knappheit bei Tabellen/Queues
• Flash: genug Platz für aktuelles und Rollback-Image
• Kapazität: Anzahl gleichzeitiger VPN-Sessions/NAT-Translations passend zum Bedarf

CLI: Ressourcen-Checks

show processes cpu sorted
show processes memory sorted
dir flash:

Schritt 6: Management-Readiness (Zugriff, OOB, Security)

Wenn im Change-Fenster der Managementzugang verloren geht, wird ein Routine-Change zur Downtime. Readiness bedeutet daher: SSH-only, Management-ACL, Console/OOB getestet, Notfallzugang dokumentiert.

• SSH-only aktiv, Telnet/HTTP deaktiviert
• VTY per Access-Class auf MGMT-Netz begrenzt
• Console/OOB erreichbar (oder Remote-Hands) und Zugangsdaten verfügbar
• Account-Standard: individuelle Nutzer, optional AAA/Accounting

CLI: Management-Checks

show ip ssh
show running-config | include line vty|access-class|transport input|username|aaa

Schritt 7: Logging/Audit-Readiness (NTP + Syslog als Pflicht)

Ohne korrekte Zeit und zentrale Logs sind Incidents schwer aufklärbar. NTP und Syslog gehören daher in jede Readiness-Prüfung – vor allem vor Rollouts auf mehrere Standorte.

CLI: NTP/Syslog Baseline (sollte vorhanden sein)

service timestamps log datetime msec
ntp server 192.0.2.10 prefer
logging host 192.0.2.20
logging trap informational

CLI: Verifikation

show ntp status
show logging | last 50

Schritt 8: Backup/Restore-Readiness (Rollback sicherstellen)

Ein Gerät ist nur dann „ready“, wenn Sie vor dem Change sichern und im Fehlerfall zurückrollen können. Dazu gehören Running/Startup-Config, ein klares Namensschema und ein getesteter Notfallpfad.

• Pre-Backup: running-config exportieren und versionieren
• Startup-Config nur nach erfolgreicher Abnahme schreiben
• Rollback-Trigger und Validierungschecks definiert

CLI: Backup-Baustein

show running-config
show startup-config
copy running-config startup-config

Readiness-Abnahme: Minimaler Gate-Check (Copy/Paste)

Diese Checkliste eignet sich als „Go/No-Go“-Gate vor Implementierung. Wenn ein Punkt rot ist (Lizenz, Image, Ressourcen), sollte der Rollout nicht starten.

show version
show inventory
show boot
dir flash:
show license summary
show processes cpu sorted
show processes memory sorted
show ip ssh
show ntp status
show logging | last 30

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.