Standard-Deliverables für Cisco-Router-Projekte: As-Built, Backup-Konfiguration und operatives Runbook

Standard-Deliverables sind der Unterschied zwischen „Projekt abgeschlossen“ und „Betrieb kann arbeiten“. Bei Cisco-Router-Projekten müssen Deliverables drei Ziele erfüllen: Sie müssen den Ist-Zustand (As-Built) nachvollziehbar dokumentieren, einen sicheren Rückweg ermöglichen (Backup- und Restore-Konzept) und dem Betriebsteam ein ausführbares Runbook geben (Incident, Change, Abnahme). Dieser Leitfaden beschreibt die Standard-Deliverables, ihren Mindestinhalt und die CLI-Nachweise, die als Belege in die Projektakte gehören.

Deliverable-Set: Was „fertig“ im Cisco-Router-Projekt bedeutet

Ein professionelles Deliverable-Set ist klein genug, um gepflegt zu werden, aber vollständig genug, um Incidents und Changes ohne Rätselraten zu bearbeiten. Jedes Deliverable sollte versioniert (Ticket-/Change-ID) und eindeutig einem Standort/Gerät zugeordnet sein.

• As-Built Dokument (Ist-Architektur + Pfadlogik)
• Backup-Konfigurationen (pre/post, running/startup) + Restore/Rollback
• Operatives Runbook (First-Level, Incident, Change, Abnahme)

Deliverable 1: As-Built (Mindestinhalt)

As-Built ist die referenzierte Wahrheit nach dem Go-Live. Es beschreibt nicht nur, was geplant war, sondern was tatsächlich umgesetzt wurde – inklusive Abweichungen, Annahmen und bekannten Einschränkungen.

• System-Steckbrief: Hostname, Standort, Rolle, Modell, IOS/IOS XE, Lizenzstatus
• Topologie: WAN-Provider, Übergabe (VLAN/MTU), LAN-Uplink, ggf. VPN-Hub
• IP-/VLAN-Plan: VLANs, Subnetze, Gateways, DHCP/DNS-Infos
• Routing: Protokoll(e), Default-Handling, Nachbarn/Peers, Filterpflicht (falls BGP)
• NAT: Ownership, Whitelist-Netze, Portforwards (falls vorhanden), No-NAT (falls VPN)
• VPN: Typ, Peers, interessante Netze, Krypto-Standard, DPD/Rekey (Betriebssicht)
• Security-Policies: Guest/IoT/MGMT Mindestregeln, Policy-Matrix-Auszug
• Monitoring: NTP/Syslog/SNMPv3, Alarmkatalog, KPI-Messpunkte
• Abweichungen: Soll/Ist, Ausnahmen (Owner, Grund, Ablaufdatum)

CLI-Belege für As-Built (Auszug)

show version
show inventory
show license summary
show ip interface brief
show interfaces description
show ip route 0.0.0.0
show ip route summary

As-Built: Diagramme und Anlagen (was wirklich gebraucht wird)

As-Built muss nicht „schön“, sondern verwendbar sein. Ein einfaches L3-Diagramm und ein Interface-/IP-Plan lösen die meisten Betriebsfragen. Große Diagrammsets sind optional.

• L3-Übersicht: Router ↔ Provider ↔ Core/Switch ↔ VPN-Hub (wenn vorhanden)
• Interface-Plan: WAN/LAN/Subinterfaces/Tunnel inkl. Descriptions
• Policy-Übersicht: Segmente und Hauptregeln (Guest/IoT/MGMT)

Deliverable 2: Backup-Konfigurationen (Pflichtset)

Backups sind nicht „ein File“, sondern ein Satz definierter Zustände. Für sichere Changes brauchen Sie mindestens: pre-change (Ist), post-change (Ist) und eine klare Zuordnung, welche Konfiguration als „letzter stabiler Zustand“ gilt.

• PRE: running-config (vor Change) + Datum/Zeit + Ticket-ID
• PRE: startup-config (vor Change) + Boot-Infos (wenn Upgrade im Scope)
• POST: running-config (nach Change) + Abnahme bestätigt (ja/nein)
• POST: startup-config (nur nach Abnahme geschrieben)
• Optional: Image-Infos (show boot, dir flash) bei OS-Änderungen

Dateinamen-Standard (Beispiel)

• <HOSTNAME>_PRE_<YYYYMMDD-HHMM>_CHG<ID>_running.txt
• <HOSTNAME>_POST_<YYYYMMDD-HHMM>_CHG<ID>_running.txt

CLI: Backup-Export (Minimum)

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

Backup-Konzept: Restore und Rollback (wie es operativ sicher wird)

Ein Backup ist nur wertvoll, wenn Restore/rollback definiert und technisch möglich ist. Das Betriebsteam braucht Trigger, Schritte und Validierungschecks, um im Incident schnell zurückzukehren.

• Rollback-Trigger: WAN down, Routing-Loop, VPN kritisch down, Security-Policy verletzt
• Soft Rollback: blockweise Rücknahme (NAT/VPN/Routing/Policies)
• Hard Rollback: Reload mit letzter stabiler Startup-Config, OOB/Console verfügbar
• Validierung: feste Checks (WAN, Routing, NAT, VPN, NTP/Syslog)

CLI: Boot-/Recovery-Belege (bei Upgrade-Projekten)

show boot
dir flash:
show version

Deliverable 3: Operatives Runbook (Mindeststruktur)

Ein Runbook ist ausführbar: Es enthält Schrittfolgen, Kommandos und Pass/Fail-Hinweise. Der Fokus liegt auf den häufigsten Aufgaben: First-Level Diagnose, VPN/WAN/Routing Checks, Change-Checks und Abnahme.

• First-Level Triage: „Internet langsam/weg“, „VPN down“, „Routing flaps“
• Standardchecks: Interface-Errors, CPU/Memory, Logs, NTP
• Servicechecks: NAT, VPN, Routing, Failover (IP SLA/Tracking)
• Change-Methodik: Pre-/Post-Checks, Stop/Go, Rollback
• Eskalation: Provider/Remote Hands, interne Verantwortliche

Runbook: First-Level Triage (Copy/Paste)

Dieses Set eignet sich als erster Schritt in nahezu jedem Incident und sollte im Runbook als Standard verankert sein.

show ip interface brief
show interfaces counters errors
show ip route 0.0.0.0
show ip route summary
show logging | last 100
show processes cpu sorted
show processes memory sorted

Runbook: WAN/Path-Qualität und Failover

Für Unternehmensbetrieb ist Path-Down genauso relevant wie Link-Down. Wenn IP SLA/Tracking genutzt wird, muss das Runbook diese Checks enthalten.

show ip sla statistics
show track
ping 8.8.8.8 repeat 20
traceroute 1.1.1.1

Runbook: NAT-Checks

NAT-Probleme sind häufig. Das Runbook muss daher Translations und Statistiken prüfen, bevor tieferes Debugging erfolgt.

show ip nat statistics
show ip nat translations

Runbook: VPN-Checks (Traffic-fähig, nicht nur „up“)

VPN gilt erst als „ok“, wenn SAs stabil sind und Traffic nachweisbar fließt. Logs helfen, Rekey/DPD-Schleifen zu erkennen.

show crypto ikev2 sa
show crypto ipsec sa
show crypto session detail
show logging | include IKEV2|IPSEC|CRYPTO

Runbook: Change- und Abnahmechecks (Standard)

Diese Checks bilden den Kern von Pre-/Post-Checks und sollten auch bei Routine-Changes verpflichtend sein. Sie sind gleichzeitig die Basis für Abnahmeprotokolle.

show ip interface brief
show interfaces counters errors
show ip route 0.0.0.0
show ip nat translations
show crypto ipsec sa
show policy-map interface
show ntp status
show logging | last 50
show processes cpu sorted

Operative Mindest-Deliverables: Was der Betrieb wirklich bekommt

Damit das Betriebsteam arbeitsfähig ist, sollten Deliverables in einer klaren Struktur übergeben werden. So werden Incidents schneller gelöst, und Audits sind einfacher.

• 01_As-Built (PDF/Doc) + Diagramm(e)
• 02_IP-Interface-Plan (CSV/PDF)
• 03_Configs_PRE_POST (Versioniert, pro Gerät/Standort)
• 04_Runbook_SOP (First-Level, Change, Rollback)
• 05_Acceptance (UAT + Pre/Post Outputs + Tester/Zeiten)
• 06_Monitoring (Ziele, Alarmkatalog, KPI-Messpunkte)

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.