Ein sauberes Inventory ist die Grundlage für sicheren Betrieb: Du weißt, welche Switches wo stehen, welche IOS/IOS XE Versionen laufen, welche Seriennummern betroffen sind und wann Geräte in End-of-Sale/End-of-Support laufen. Ohne diese Daten werden Updates, Incident-Response und Budgetplanung teuer und unzuverlässig. Dieser Leitfaden zeigt, wie du Seriennummern, Modelle, Softwarestände und Hardware-Details auf Cisco Switches korrekt erfasst, typische Fehler vermeidest und die Daten so strukturierst, dass Lifecycle-Management (EoX) und Audits funktionieren.
Welche Inventory-Daten wirklich relevant sind
Für Lifecycle und Betrieb brauchst du mehr als „Hostname und IP“. Ein gutes Asset-Set ist klein genug für Pflege, aber vollständig genug für Updates und Ersatzteilplanung.
- Hostname, Standort, Rack/Position, Rolle (Access/Distribution)
- Modell/Plattform (z. B. Catalyst-Serie), Hardware-Revision
- Seriennummer(n) (Chassis, Stack-Member, Module)
- IOS/IOS XE Version, Image-Name, Boot-Variable
- Uptime/Reload-Gründe (optional, für Stabilität)
- Lizenz-/Feature-Level (bei IOS XE relevant)
Seriennummern korrekt erfassen: Chassis, Stack und Module
Seriennummern sind nicht immer „eine“. In Stacks hat jeder Member eine eigene SN. Zusätzlich können Netzteile/Module eigene Seriennummern haben. Nutze daher die passenden Commands, um nichts zu übersehen.
Chassis und Module (Inventory)
show inventory
Stack-Member Seriennummern (StackWise)
show switch
show switch detail
Zusätzlich: Hardware-ID / EEPROM (plattformabhängig)
show version | include Processor board ID|System serial number
Modelle und Plattformen eindeutig erfassen
Für Lifecycle brauchst du die exakte Plattformbezeichnung, nicht nur „Cisco Switch“. show version liefert Modell, Base MAC, Speicher und Image-Informationen. Bei Stacks ist außerdem relevant, ob alle Member identisch sind.
Modell und Plattformdaten
show version
show version | include Model number|cisco|processor|Memory|System image file
Stack-Homogenität prüfen
show switch
IOS/IOS XE Versionen richtig dokumentieren (inkl. Image und Boot)
Für Updates und Security-Patches reicht „Version X.Y“ nicht. Dokumentiere das exakte Image (bin), den Install-Modus (Bundle/Install bei IOS XE) und die Boot-Variable. Das verhindert Update-Fehler und erklärt Versionsdrift.
Softwarestand und Image
show version | include Cisco IOS|IOS XE|System image file|System compile time
dir flash:
Boot-Variable prüfen
show boot
show running-config | include boot system
Uptime und Reload-Grund als Stabilitätsindikator
Für Lifecycle ist Uptime nicht zwingend, aber operativ sehr nützlich: häufige Reloads können auf instabile Software oder Hardware hindeuten. Dokumentiere Uptime und „Last reload reason“ mindestens für kritische Systeme.
Uptime und Reload Reason
show version | include uptime|Last reload reason
show logging | include RELOAD|POWER|CRASH
Lizenz- und Feature-Level erfassen (IOS XE/Catalyst)
In IOS XE Umgebungen beeinflussen Lizenzstände oft Features und Upgrade-Planung. Für Inventory genügt meist die Info, welches Feature-Set aktiv ist und ob Smart Licensing genutzt wird (plattformabhängig).
Lizenzstatus prüfen (plattformabhängig)
show license summary
show license status
Standard-Workflow: Daten als „One-Liner“ pro Switch sammeln
Damit du Inventory skalieren kannst, brauchst du einen standardisierten Befehlsblock, den jeder Admin nutzen kann. Daraus extrahierst du anschließend Seriennummern, Modell und Version strukturiert.
Kommandoblock (Copy/Paste)
show inventory
show version
show version | include Processor board ID|System serial number|System image file|Last reload reason|uptime
show boot
show switch
Typische Fehler im Inventory (und wie du sie vermeidest)
Die häufigsten Probleme sind falsche oder unvollständige Seriennummern, „Version ohne Image“ und fehlende Stack-Member-Daten. Genau diese Fehler führen später zu falschen EoX-Bewertungen und Update-Risiken.
- Nur eine Seriennummer erfasst, Stack-Member fehlen
- Nur „IOS Version“ notiert, aber Image/Install-Mode fehlt
- Hostname/Standort nicht konsistent (keine eindeutige Zuordnung)
- Module/PSU nicht erfasst (Ersatzteilplanung schwierig)
- Boot-Variable nicht geprüft (Upgrade-Rollback riskant)
Lifecycle-Praxis: Wie du Inventory für EoX nutzbar machst
Inventory ist erst dann Lifecycle-fähig, wenn du Modell und Seriennummer eindeutig zuordnen kannst und Softwarestände mit Patch-Policy abgleichst. Operativ bewährt sich eine Einteilung nach Rolle und Kritikalität.
- Rolle: Access/Distribution/Core, Standort/Rack
- Kritikalität: kritisch (Core), hoch (Distribution), normal (Access)
- Software-Policy: erlaubte Versionen, Maintenance-Window
- Lifecycle: EoX-Daten pro Plattform (separat pflegen und referenzieren)
Praxis-Tipp: „Golden Version“ pro Plattform
Definiere pro Plattform eine freigegebene IOS/IOS XE Version. Inventory zeigt dir dann sofort, welche Geräte davon abweichen.
Audit und Aktualisierung: Inventory aktuell halten ohne Daueraufwand
Inventory scheitert oft nicht an der Ersterfassung, sondern an der Pflege. Setze deshalb einen klaren Prozess: Update nach Changes, regelmäßige Stichproben und ein Standard für Namensgebung/Standortfelder.
- Pflicht: Inventory-Update nach Hardwaretausch/Stack-Change/Upgrade
- Regelmäßig: Quartalsweise Audit-Stichprobe (kritische Geräte zuerst)
- Dokumentation: Port-Descriptions, Standort-Tagging, eindeutige Hostnames
Best Practices: Minimaler Inventory-Standard als Template
Wenn du eine einfache Struktur nutzt, bleibt Inventory pflegbar und trotzdem lifecycle-tauglich. Dieses Minimalset reicht für die meisten Campus-Umgebungen.
- Hostname
- Management-IP
- Standort (Gebäude/Rack/U)
- Rolle (Access/Distribution)
- Modell/Plattform
- Seriennummer(n) (Chassis/Stack)
- IOS/IOS XE Version + Image
- Boot-Variable/Install-Mode
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.
