IOS XE Prozessmodell verstehen: Troubleshooting mit show platform

IOS XE unterscheidet sich von klassischem IOS durch ein stärker modulares Prozess- und Plattformmodell: Statt „ein Monolith“ gibt es eine Linux-basierte Umgebung, in der die Control-Plane als IOSd läuft und weitere Plattformprozesse (z. B. Forwarding-/I/O-Subsysteme) separat überwacht werden. Genau hier setzt show platform an: Du siehst Hardware-/Slot-Status, Module, Prozesszustände und oft Crash-/Reset-Indizien. Wer dieses Modell versteht, kann unter Zeitdruck schneller zwischen „Routing/Config-Problem“ und „Plattform/Prozess-Problem“ unterscheiden.

IOS XE Prozessmodell: Control Plane vs. Plattformprozesse

Für Troubleshooting ist die wichtigste Trennung: Was läuft in der Control Plane (IOSd/Route Processor) und was ist Plattform-/Forwarding-Ebene. Viele Fehler sehen gleich aus („Traffic geht nicht“), haben aber unterschiedliche Ursachen.

• Control Plane: IOSd, Routing, Management, CLI
• Plattformprozesse: Hardware-/I/O-Services, Treiber, Module
• Data Plane: Forwarding (CEF/ASIC je nach Plattform)

Merker

CLI lebt  ≠  Forwarding ok

Warum show platform im Incident so wertvoll ist

show platform liefert dir schnell Antworten auf „ist das Gerät gesund?“: Hat ein Modul rebootet? Ist ein Prozess in Crash/Reset? Gibt es einen abnormalen Status? Damit erkennst du Plattformprobleme, die du mit reinen Routing-Checks (show ip route) nicht siehst.

• Module/Slots: Status und Uptime-Indizien
• Prozesszustände: Running, Disabled, Crash, Restart
• Resets/Crashes: Hinweise auf Software-/Hardware-Probleme

Grundlegende Kommandos: Einstieg in 30 Sekunden

Beginne mit einem kompakten Überblick. Ergänze danach gezielt Detailansichten für den betroffenen Slot/Prozess.

show platform
show platform software status control-processor brief
show processes cpu sorted
show logging | last 100

show platform interpretieren: Was du typischerweise siehst

Die genaue Ausgabe ist plattformabhängig, aber das Muster ist ähnlich: Chassis/Slot/Module mit Statusfeldern. Achte auf „nicht ready“, „failed“, „reset“ und auf abweichende Uptime.

Worauf du in der Ausgabe fokussierst

• Status: ok/ready vs. failed/not ready
• Role: aktiv/standby (bei HA/Redundancy)
• Uptime/Last reset reason (wenn angezeigt)
• Module mit abweichender Uptime: „hat neu gestartet“

Control-Processor Status: IOSd/CPU-Gesundheit prüfen

Wenn Control-Plane instabil ist, siehst du das oft an Control-Processor-Status, CPU-Last und Logs. Wichtig: hohe CPU bedeutet nicht automatisch „Hardware kaputt“, aber sie kann Routing und Management massiv beeinträchtigen.

Control-Plane Kurzcheck

show platform software status control-processor brief
show processes cpu sorted
show processes memory sorted
show logging | include CRASH|TRACEBACK|IOSXE|SYS-

Plattformprozesse und Restart-Indizien: „Warum flappen Interfaces?“

Wenn Interfaces flappen, Line Protocol instabil ist oder Forwarding sporadisch aussetzt, ist ein Prozess-/Subsystem-Restart eine häufige Ursache. show platform und Logs helfen, diese Neustarts zeitlich zu korrelieren.

Uptime- und Restart-Indizien korrelieren

show platform
show version
show logging | last 300

Interpretationsregel

• Wenn show version eine stabile Uptime zeigt, aber ein Modul/Subsystem in show platform eine kürzere Uptime hat, gab es einen partiellen Restart.
• Wenn Logs zeitgleich „link down/up“ und „process restart“ zeigen, ist es eher Plattform als Routing.

Forwarding vs. Routing: Mit CEF gegenprüfen

Auch wenn show platform gesund aussieht, kann Forwarding falsch sein (z. B. CEF-Blackhole, falscher Next-Hop, FIB inkonsistent). Darum gehört eine CEF-Gegenprobe dazu.

show ip route <destination>
show ip cef <destination> detail
traceroute <destination> source <source-ip>

Typische Troubleshooting-Szenarien mit show platform

Diese Muster helfen dir, schnell die richtige Hypothese zu wählen.

Scenario A: CLI ok, aber Traffic weg

• Prüfe show platform auf „not ready/failed“ bei Forwarding-nahen Komponenten
• Prüfe Interface drops/errors, CEF und ggf. QoS

show platform
show interfaces | include drops|error
show ip cef 8.8.8.8
show policy-map interface <wan>

Scenario B: Sporadische Link-Flaps ohne physische Ursache

• Prüfe Prozess-/Subsystem-Restarts (Uptime, Reset Reason)
• Korrelieren mit Syslog „LINEPROTO“ und Plattformmeldungen

show platform
show logging | include LINEPROTO|LINK-|PLATFORM|CRASH

Scenario C: Nach Upgrade instabil

• Prüfe, ob alle Module im erwarteten State sind
• Prüfe Crash-/Traceback-Indizien und Memory-Leaks

show platform
show version
show processes memory sorted
show logging | include CRASH|TRACEBACK

Praktische Ergänzungen: Was du neben show platform immer mitnimmst

show platform ist ein Einstieg, kein vollständiger Befund. In einem sauberen Incident-Snapshot gehören Version, Uptime, CPU und relevante Logs dazu.

• show version: Image, Uptime, Reload Reason
• show inventory: Hardware-Details (für RMA/Case)
• show environment: Temperatur/Power (plattformabhängig)
• show tech-support: Evidence Capture für TAC

Evidence Bundle (Copy & Paste)

show clock
show version
show platform
show platform software status control-processor brief
show processes cpu sorted
show processes memory sorted
show interfaces | include CRC|drops|error
show ip route | include Gateway|0.0.0.0
show logging | last 300
show tech-support

Typische Pitfalls bei der Interpretation

Viele Fehlinterpretationen entstehen, wenn man „Prozessmodell“ und „Netzmodell“ vermischt. Nicht jeder Prozess-Restart ist ein Incident, und nicht jeder Traffic-Ausfall ist „IOSd crashed“.

• show platform ist plattformabhängig: Felder variieren
• Kurze Uptime eines Subsystems kann geplant sein (z. B. ISSU/HA)
• Hohe CPU kann auch durch Control-Plane-Floods (Scans) kommen → CoPP prüfen

CoPP Gegencheck

show policy-map control-plane
show processes cpu sorted

Konfiguration speichern

Router# 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.