Cisco-Router-Konfiguration: Beispiel für professionelle Handover-Dokumente

Professionelle Handover-Dokumente sind der Unterschied zwischen „Router läuft“ und „Router ist betriebssicher“. Sie müssen es dem Betriebsteam ermöglichen, den Zustand nachzuvollziehen, Änderungen kontrolliert durchzuführen und Störungen schnell einzugrenzen – ohne Rückfragen an das Projektteam. Dieses Beispiel zeigt eine praxisnahe Struktur für Handover-Unterlagen nach einer Cisco-Router-Konfiguration, inklusive typischer Inhalte, Tabellenlogik (als Stichpunkte) und den CLI-Nachweisen, die in einem Abnahmeprotokoll stehen sollten.

Dokumentpaket im Handover: Überblick und Mindestumfang

Ein vollständiges Handover besteht aus wenigen, klar getrennten Dokumenten. Jedes Dokument hat einen Zweck und enthält nur die Informationen, die im Betrieb benötigt werden.

• Handover-Deckblatt (Projektmetadaten, Scope, Versionen, Ansprechpartner)
• Topologie- und Interface-Dokument (WAN/LAN, Ports, Übergaben)
• IP-/VLAN-Plan (Subnetze, Gateways, DHCP, Rollen)
• Routing/NAT/VPN/Policies (kurze, nachvollziehbare Übersichten)
• Monitoring/Logging (Syslog, NTP, SNMPv3, Alarmkatalog)
• Abnahmeprotokoll (Pre-/Post-Checks, UAT, Failover-Tests)
• Rollback- und Notfallzugang (Trigger, Schritte, Console/OOB)
• Runbook/SOP (Standardchecks und Reaktion auf Alarme)

Beispiel: Handover-Deckblatt (Inhalte)

Das Deckblatt ist die „Single Source of Truth“ für Betrieb und Audit: Was wurde geliefert, in welcher Version, wann, von wem, und wie wird eskaliert.

• Projektname: Standort/Edge-Bezeichnung, Ticket-ID/Change-ID
• Gerät: Modell, Seriennummer, IOS/IOS XE-Version, Lizenzstatus
• Scope: WAN, VLANs, Routing, NAT, VPN, QoS, Monitoring (ja/nein)
• Go-Live-Datum, Hypercare-Zeitraum, Support-Kontakte
• Risiken/Annahmen: Providerparameter, MTU, externe Abhängigkeiten

Beispiel: Topologie- und Interface-Dokument

Dieses Dokument beantwortet operativ die wichtigste Frage: „Wo ist was angeschlossen?“ Es enthält WAN-Übergaben, LAN-Uplinks, Trunks und Managementpfade.

Interface-Übersicht (Musterinhalte)

• GigabitEthernet0/0: WAN-ISP1, Übergabe Port/VLAN, IP/Gateway, MTU
• GigabitEthernet0/2: WAN-ISP2 (optional), IP/Gateway, Tracking
• GigabitEthernet0/1: LAN-Trunk zum Switch (dot1Q), VLAN-Liste
• Loopback0 (optional): Management/Monitoring-ID

CLI-Nachweis für Interface-Status (Abnahmeanhang)

show ip interface brief
show interfaces counters errors
show interfaces | include line protocol|MTU

Beispiel: IP- und VLAN-Plan (sauber strukturiert)

Der IP-/VLAN-Plan ist im Betrieb unverzichtbar: er steuert DHCP, Policies, NAT und Monitoring. Er sollte Rollen, Subnetze und Gateways klar darstellen.

VLAN-Rollen (Beispielstruktur)

• VLAN10-MGMT: 10.10.10.0/24, GW 10.10.10.1, nur IT
• VLAN20-USERS: 10.10.20.0/24, GW 10.10.20.1, DHCP zentral
• VLAN30-VOICE: 10.10.30.0/26, GW 10.10.30.1, QoS
• VLAN40-IOT: 10.10.40.0/26, GW 10.10.40.1, restriktiv
• VLAN50-GUEST: 10.10.50.0/24, GW 10.10.50.1, nur Internet

Subnetting-Hinweis (für Planungsbegründung)

Ein /26 bietet 64 Adressen (62 nutzbar) und ist für Voice/IoT häufig ausreichend.

$2^6=64$

CLI-Nachweis für VLAN-Gateways (Abnahmeanhang)

show ip interface brief
show arp summary

Beispiel: Routing-Dokument (Pfadlogik und Abhängigkeiten)

Das Routing-Dokument beschreibt, wie der Standort „den Weg nach außen“ findet und wie interne Netze verteilt werden. Es nennt das verwendete Protokoll, Default-Logik, Failover-Kriterien und relevante Nachbarn.

• Routing-Modell: Static / OSPF / EIGRP / BGP
• Default-Route: Next-Hop, Tracking (IP SLA) ja/nein
• Failover: Umschaltkriterien (Link-Down vs. Path-Down)
• Nachbarn: OSPF/EIGRP/BGP Peers inkl. IPs und Rolle
• Filter/Policies: Prefix-Lists/Route-Maps (falls BGP)

CLI-Nachweis Routing (Abnahmeanhang)

show ip route summary
show ip route 0.0.0.0
show ip protocols
show bgp summary
show ip ospf neighbor

Beispiel: NAT-Dokument (Internetverhalten nachvollziehbar)

NAT muss im Handover klar dokumentiert sein, weil viele Störungen darauf zurückgehen. Das Dokument benennt Inside/Outside, Quellnetze, No-NAT für VPN und ggf. Portweiterleitungen.

• NAT-Owner: Router oder Firewall (klar festlegen)
• Inside/Outside-Interfaces
• NAT-Quellnetze (welche VLANs dürfen ins Internet?)
• No-NAT-Ausnahmen (VPN-Subnetze)
• Static PAT/Portforwards (Port, Ziel, Owner, Zweck)

CLI-Nachweis NAT (Abnahmeanhang)

show ip nat statistics
show ip nat translations
show running-config | include ip nat inside|ip nat outside|ip nat inside source

Beispiel: VPN-Dokument (Matrix, Kryptoprofile, Betriebskontrollen)

VPNs benötigen eine Matrix: welche Peers, welche Netze, welche Pfade. Zusätzlich sollten Rekey/DPD, MTU/MSS und Monitoring-Checks dokumentiert sein, damit „Tunnel up“ auch „Traffic ok“ bedeutet.

• Peer-Daten: IP/FQDN, Primary/Backup, Kontaktstelle
• Interessante Netze (Selektoren) oder VTI/Tunnel-Interface
• Kryptoprofil: IKEv2, Cipher/Hash, DH/PFS (nach Policy)
• Betrieb: Rekey/DPD, MTU/MSS-Strategie
• Abnahme: Paketzähler und End-to-End Tests

CLI-Nachweis VPN (Abnahmeanhang)

show crypto ikev2 sa
show crypto ipsec sa
show crypto session detail

Beispiel: Security- und Segment-Policies (Policy-Matrix)

Für Betrieb und Audit ist eine Policy-Matrix Pflicht: Wer darf wohin? Besonders Guest, IoT und Management müssen klar geregelt sein. Die Regeln sollten einen Owner und einen Zweck haben.

• Guest: nur Internet, kein Zugriff auf interne Netze
• IoT: nur definierte Ziele/Ports (z. B. Print, Cloud)
• Management: nur aus MGMT-Netz erreichbar (SSH/AAA/SNMPv3)
• Logging: welche Policies loggen Events (wenn gefordert)

CLI-Nachweis Policies (Abnahmeanhang)

show access-lists
show running-config | include ip access-group|access-class

Beispiel: Monitoring- und Logging-Dokument

Damit Betriebsteams proaktiv arbeiten können, müssen Syslog, NTP und SNMPv3 dokumentiert sein – inklusive Alarmkatalog und Schwellenwerten. Ohne diese Angaben entstehen Alarmflut oder blinde Flecken.

• NTP-Server, Zeitsynchronisation, Zeitstempel aktiviert
• Syslog-Ziel(e), Log-Level, Quellinterface
• SNMPv3: User/Group, Location/Contact, Polling/Traps
• Alarmkatalog: WAN down/flaps, Path-down, VPN down, CPU hoch, CRC/Drops

CLI-Nachweis Monitoring (Abnahmeanhang)

show clock
show ntp status
show running-config | include ntp server|logging host|snmp-server
show logging | last 50

Beispiel: Abnahmeprotokoll (Pre-/Post-Checks und UAT)

Das Abnahmeprotokoll ist das wichtigste Qualitätsdokument: Es zeigt, dass der Sollzustand getestet wurde. Es sollte die Outputs der relevanten Kommandos enthalten und UAT-Ergebnisse dokumentieren.

Pre-Checks (vor dem Change)

show ip interface brief
show interfaces counters errors
show ip route summary
show processes cpu sorted
show logging | last 50

Post-Checks (nach dem Change)

show ip interface brief
show ip route 0.0.0.0
show ip nat statistics
show crypto ipsec sa
ping 8.8.8.8 repeat 10
traceroute 1.1.1.1

UAT-Checkliste (Beispielinhalte)

• Internet: definierte Ziele erreichbar, Pfad plausibel
• Business-Apps: Login/Transaktion erfolgreich
• VPN: Tunnel stabil, Paketzähler steigen
• Segmentierung: Guest intern blockiert, IoT restriktiv
• Failover (wenn vorhanden): Link-Down und Path-Down Tests dokumentiert

Beispiel: Rollback- und Notfallzugang-Dokument

Dieses Dokument muss im Incident sofort nutzbar sein. Es definiert Trigger, Schritte und Validierung. Zusätzlich beschreibt es den Notfallzugang (Console/OOB) und wer Remote-Hands stellt.

• Rollback-Trigger: Managementverlust, WAN instabil, Routing-Loop, VPN kritisch down
• Rollback-Schritte: Default/Policies zurück, letzte stabile Config aktivieren
• Validierung nach Rollback: Basis-Checks und Pfadtests
• Notfallzugang: Console/OOB, Zugangsdaten-Handling, Ansprechpartner

Rollback-Validierung (CLI)

show ip interface brief
show ip route
show logging | last 50
ping 198.51.100.1
ping 8.8.8.8

Beispiel: Runbook/SOP für den Betrieb (kurz und wiederholbar)

Das Runbook enthält Standardreaktionen auf Alarme und eine minimale Kommandoliste. Ziel ist, dass auch neue Teammitglieder schnell zielführend prüfen können.

• WAN/Internet down: Interface, Default-Route, Gateway, NAT
• VPN down: IKEv2/IPsec SAs, Logs, Pfadqualität
• Routing-Probleme: Nachbarn, Route-Quellen, Flapping
• Performance: Errors/Drops, CPU/Memory, QoS-Zähler

Runbook-Kommandos (Minimalset)

show ip interface brief
show interfaces counters errors
show ip route 0.0.0.0
show ip nat statistics
show crypto ikev2 sa
show crypto ipsec sa
show logging | last 50
show processes cpu sorted

Finale Übergabe: Konfiguration sichern und versionieren

Zum Abschluss muss der finale Zustand gespeichert und als „post“-Version versioniert abgelegt werden. Das reduziert Risiko bei späteren Changes und ist die Grundlage für Drift-Kontrolle.

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.