Post-Change-Verifikation auf Cisco-Routern ist der Schritt, der aus einer „erfolgreich durchgeführten Änderung“ einen nachweislich stabilen Produktivzustand macht. Im Enterprise ist ein Change erst dann abgeschlossen, wenn KPIs im erwarteten Bereich liegen, Monitoring/Alerting keine neuen Anomalien zeigen und der Traffic Path für kritische Services validiert ist. Ohne strukturierte Post-Checks bleiben stille Fehler (falscher Default, asymmetrisches Routing, No-NAT fehlt, QoS greift nicht) unentdeckt und eskalieren später als P1-Incident. Dieser Leitfaden zeigt eine praxistaugliche Post-Change-Checkliste mit KPI-Set, CLI-Evidence und Traffic-Path-Validierung.
Prinzip: Post-Change ist Evidence, nicht Bauchgefühl
Post-Checks müssen reproduzierbar sein und als Evidence im Change-Ticket landen. Nutzen Sie immer dieselbe Reihenfolge: Zustand → KPIs → Traffic Path → Monitoring → Abnahme.
- Zustand: Interface, Routing, VPN, NAT, CPU/Memory
- KPIs: Uptime/Path, RTT/Loss, Drops/Errors, Failover-Bereitschaft
- Traffic Path: kritische Flows end-to-end verifizieren
- Monitoring: Alarme, Counter, Dashboards, Syslog/SIEM
- Abnahme: Pass/Fail + Rollback-Trigger
Post-Change Gate: Pass/Fail-Kriterien definieren
Definieren Sie vor der Implementierung, was „grün“ bedeutet. Das verhindert Diskussionen im Change Window und erleichtert Rollback-Entscheidungen.
- Pass: Default-Route korrekt, keine Interface-Errors-Spikes
- Pass: VPN (falls Scope) traffic-fähig, keine SA-Flaps
- Pass: RTT/Loss innerhalb Zielwerten oder Baseline
- Pass: QoS (falls Scope) keine Drops in Echtzeitklassen
- Fail: Management instabil, CPU dauerhaft hoch, Routing Flaps, Blackholes
Schritt 1: Sofort-Snapshot nach Change (immer gleich)
Der erste Snapshot ist Ihre „Post“-Baseline. Speichern Sie ihn mit Zeitstempel und Change-ID.
show clock
show ip interface brief
show interfaces counters errors
show ip route 0.0.0.0
show ip route summary
show ip cef summary
show ip nat statistics
show ip nat translations
show crypto ikev2 sa
show crypto ipsec sa
show ip sla statistics
show track
show policy-map interface
show ntp status
show logging | last 100
show processes cpu sorted
show processes memory sortedSchritt 2: KPI-Set für Post-Change (minimal, enterprise-tauglich)
KPIs müssen messbar sein. Nutzen Sie ein kleines Set, das die häufigsten Nebenwirkungen von Changes abdeckt. Wenn Sie eine Pre-Change-Baseline haben, vergleichen Sie gegen diese.
- Verfügbarkeit: Default/Path erreichbar (IP SLA/Tracking, falls vorhanden)
- Qualität: RTT/Loss zu festen Targets (Internet, Hub, DC)
- Stabilität: Routing/VPN Neighbor- und SA-Stabilität
- Performance: CPU/Memory Headroom, Drops/Queues am WAN
- Integrität: NTP synchronized, Syslog sichtbar
CLI: KPI-Checks (Copy/Paste)
show ip sla statistics
show track
ping 1.1.1.1 repeat 20
traceroute 1.1.1.1
show interfaces | include output drops|queue
show interfaces counters errors
show processes cpu sorted
show ntp status
show logging | last 50Schritt 3: Monitoring-Validierung (NOC/SOC Sicht)
Ein Change ist nicht abgeschlossen, wenn Monitoring blind ist. Prüfen Sie, ob das Gerät weiterhin im NOC sichtbar ist und ob neue Alarme ausgelöst wurden.
- Syslog: Events kommen mit korrekter Zeit an
- SNMP/Telemetry: Interface/CPU Metriken aktualisieren sich
- Alerts: keine neuen Flap-/Drop-/CPU-Alarme seit Change-Zeitpunkt
- SIEM: Security-relevante Events (wenn betroffen) plausibel
CLI: Monitoring-Readiness (Router-seitig)
show ntp status
show logging | last 50
show snmp user
show ip interface briefSchritt 4: Traffic-Path-Validierung (kritische Flows end-to-end)
Die wichtigste Post-Change-Prüfung ist die Validierung des Traffic Path: läuft der kritische Traffic wirklich über den erwarteten Pfad und wird nicht durch NAT/ACL/QoS verändert? Nutzen Sie feste Testfälle statt „ein bisschen surfen“.
- Internet: DNS + HTTPS (Users und ggf. Guest separat)
- VPN/Inter-Site: Branch ↔ HQ/DC kritische Netze
- SaaS: definierte Ziel-URLs/IPs (wenn Scope)
- Voice/Video: wenn QoS geändert wurde (Call/Meeting unter Last)
CLI: Pfadprüfung (Router-Perspektive)
show ip route <DEST_IP>
show ip cef <DEST_IP> detail
traceroute <DEST_IP>
show ip nat translations
show access-listsTraffic-Nachweis für VPN (falls Scope)
show crypto ikev2 sa
show crypto ipsec saSchritt 5: Validierung von NAT, ACL und Segmentierung (häufige Nebenwirkungen)
Viele Post-Change-Issues sind Policy-bedingt: NAT-Whitelist zu breit/zu eng, No-NAT fehlt, ACL blockt DNS/NTP oder neue Subnetze. Prüfen Sie Counter und gezielte Deny-Logs.
- NAT: Translations steigen bei Testtraffic, keine unerwarteten Segmente
- No-NAT: VPN-Traffic wird nicht genattet
- ACL: Counter plausibel, Guest→RFC1918 blockt, Users→MGMT blockt
CLI: Policy-Checks
show ip nat statistics
show ip nat translations
show access-lists
show logging | include DENY|ACLSchritt 6: QoS-Validierung (wenn QoS im Scope war)
QoS gilt nur als erfolgreich, wenn die Policy am WAN-Egress greift und Echtzeitklassen unter Last keine Drops zeigen. Prüfen Sie Policy-Zähler und Queue Drops.
- Policy attached: korrektes Interface, richtige Richtung
- Class Counters: Traffic in REALTIME/VIDEO sichtbar
- Drops: keine auffälligen Drops in Echtzeitklassen
CLI: QoS Evidence
show policy-map interface
show interfaces | include output drops|queueSchritt 7: Routing-Stabilität (Loops, Flaps, Blackholes verhindern)
Nach Routing-Changes ist Stabilität das Kernkriterium. Prüfen Sie Neighbor-Status und Logs auf Flap-Indikatoren. Bei Blackholes sind CEF und spezifische Prefix-Checks entscheidend.
- OSPF/BGP: Neighbors stabil, keine wiederkehrenden Up/Down Events
- Prefix-Integrität: erwartete Routen vorhanden, keine unerwarteten Summaries/Null0
- CEF: Forwarding konsistent, keine Anomalien
CLI: Routing Evidence
show ip ospf neighbor
show bgp summary
show ip route summary
show ip cef summary
show logging | include OSPF|BGP|LINEPROTO|LINK-Rollback-Trigger: Wann Sie sofort zurück müssen
Ein professioneller Post-Change-Prozess enthält klare Backout-Trigger. Das reduziert Risiko, weil Entscheidungen nicht ad hoc getroffen werden.
- Management instabil oder nicht erreichbar (über MGMT/Bastion)
- Default-Route fehlt oder flapt
- VPN/Standortkritische Services down (wenn Scope)
- CPU dauerhaft hoch oder Control-Plane-Storm
- Routing Loop/Blackhole bestätigt
Abschluss: Post-Change Evidence Pack (zum Ticket anhängen)
Hängen Sie das Evidence Pack strukturiert an: Snapshot, KPI-Checks, Traffic-Path-Tests, Monitoring-Status. So ist der Change auditfähig und spätere Root-Cause-Analysen sind schneller.
- Post-Snapshot (vollständig)
- KPI-Messwerte (RTT/Loss, Drops/Errors, CPU)
- Traffic-Path Evidence (Route/CEF/Traceroute, NAT/VPN Counter)
- Monitoring Evidence (NTP/Syslog, Alarme/Dashboards)
- Pass/Fail Entscheidung + Rollback-Status
CLI: Post-Change Evidence Pack (Copy/Paste)
show clock
show ip interface brief
show interfaces counters errors
show ip route 0.0.0.0
show ip route summary
show ip cef summary
show ip sla statistics
show track
ping 1.1.1.1 repeat 20
traceroute 1.1.1.1
show ip nat statistics
show ip nat translations
show crypto ipsec sa
show access-lists
show policy-map interface
show ntp status
show logging | last 100
show processes cpu sortedKonfiguriere 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.
