UAT für Cisco-Router Dual-ISP & VPN: Test Cases und Evidence Collection

Ein UAT (User Acceptance Test) für Cisco-Router mit Dual-ISP und VPN ist nur dann aussagekräftig, wenn er Failover realistisch testet, VPN-Traffic nachweist und Evidence nachvollziehbar dokumentiert. „Tunnel up“ oder „Link up“ genügt nicht: Viele Ausfälle sind Path-down (Upstream kaputt), und viele VPN-Probleme zeigen sich erst bei Traffic (No-NAT, Selektoren, Routing, MTU/MSS). Ein production-grade UAT definiert daher Test Cases mit Pass/Fail-Kriterien, misst Umschaltzeiten (Detection + Convergence + Service-Recovery) und sammelt CLI-Evidence pro Test. Dieses Template liefert praxistaugliche Testfälle und eine strukturierte Evidence Collection für Dual-ISP & VPN.

UAT-Setup: Scope, Rollen und Messkriterien

Starten Sie mit klaren Rahmenbedingungen. Ohne Scope und Messkriterien ist der UAT nicht vergleichbar und führt zu Diskussionen.

• Scope: welche Standorte, welche VPNs (Hub/Spoke), welche ISPs (ISP1/ISP2/LTE)?
• Rollen: NetOps führt Tests aus, Service Owner bestätigt kritische Flows
• Messwerte: Failover-Zeit, Packet Loss während Umschaltung, VPN-Stabilität
• Evidence: pro Testfall CLI-Auszug + Zeitstempel (show clock)

Failover-Zeit als Kette (Template)

$\mathrm{Failover}\_\mathrm{Zeit}=\mathrm{Detection}+\mathrm{Convergence}+\mathrm{Service}\_\mathrm{Recovery}$

Vorbedingungen: Was vor dem UAT bereitstehen muss

Viele UATs scheitern an fehlenden Voraussetzungen. Definieren Sie Pre-Checks als Gate: ohne Baseline keine Abnahme.

• Dual-ISP aktiv: Primary/Backup Priorität klar, Tracking/IP SLA aktiv
• VPN aktiv: IKEv2/IPsec stabil, No-NAT geprüft (falls NAT aktiv)
• Monitoring aktiv: Syslog/NTP ok, NOC kann Events sehen (optional)
• Testziele: definierte Probe-IPs (Hub, DNS, Public IP) und Applikationsziele

CLI: Pre-UAT Baseline Snapshot

show clock
show ip interface brief
show interfaces counters errors
show ip route 0.0.0.0
show ip sla statistics
show track
show crypto ikev2 sa
show crypto ipsec sa
show ip nat statistics
show ntp status
show logging | last 50

Testfallgruppe A: Normalbetrieb (Primary ISP + VPN End-to-End)

Bevor Sie Failover testen, muss der Normalbetrieb eindeutig funktionieren. Das ist die Referenz für alle späteren Abweichungen.

• Pass: Internet erreichbar, Default-Route zeigt auf ISP1, Tracking up
• Pass: VPN SAs up und VPN Traffic Counter steigen
• Fail: Default inkonsistent, SA flaps, Counter bleiben 0

Test A1: Default/Tracking im Normalbetrieb

show clock
show ip route 0.0.0.0
show ip sla statistics
show track

Test A2: VPN Status + Traffic Nachweis

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

Test A3: Traffic-Path Smoke Tests (Beispiel)

ping 1.1.1.1 repeat 10
traceroute 1.1.1.1
ping <HUB_INTERNAL_IP> repeat 10
traceroute <REMOTE_SUBNET_HOST>

Testfallgruppe B: ISP1 Link-Down Failover (klassischer Ausfall)

Dieser Test prüft das Umschalten bei Link-down. Er ist wichtig, aber nicht ausreichend – daher folgt später Path-down.

• Ausführung: ISP1 physisch trennen oder Interface shutdown (kontrolliert)
• Pass: Track/Default wechselt zu ISP2, Internet und VPN bleiben nutzbar
• Pass: Umschaltzeit dokumentiert, keine Flap-Schleife bei Rückkehr

Test B1: Failover auslösen und Zeit messen

show clock
show ip sla statistics
show track
show ip route 0.0.0.0

Test B2: Service-Recovery (Internet + VPN)

ping 1.1.1.1 repeat 20
show crypto ipsec sa
traceroute <REMOTE_SUBNET_HOST>

Testfallgruppe C: ISP1 Path-Down Failover (realistischer als Link-Down)

Path-down ist ein typischer Provider-/Upstream-Fehler: Link bleibt up, aber Ziele sind nicht erreichbar. Ohne IP SLA/Tracking failt Failover oft genau hier.

• Ausführung: Probe-Target unreachability simulieren (z. B. Upstream blockiert), oder Testziel wechseln
• Pass: IP SLA erkennt Path-down, Track fällt, Default wechselt zu ISP2
• Fail: Link up, aber Router bleibt auf ISP1 und Services sind gestört

Test C1: Tracking reagiert auf Path-Down

show clock
show ip sla statistics
show track
show ip route 0.0.0.0
show logging | include TRACK|IP_SLA

Testfallgruppe D: VPN Failover-Verhalten (Stabilität bei Pfadwechsel)

VPN kann bei ISP-Wechsel flappen (DPD/Rekey) oder Traffic kann asymmetrisch werden. Testen Sie deshalb ausdrücklich VPN-Stabilität und Counter über den Wechsel.

• Pass: VPN SAs bleiben stabil oder rekonvergieren innerhalb Zielzeit
• Pass: Traffic Counter steigen weiterhin, keine „SA up, no traffic“
• Fail: wiederkehrende SA-Flaps, Counter bleiben 0, Applikationspfade brechen

Test D1: VPN Counters vor/nach Failover vergleichen

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

Test D2: No-NAT und Selektoren prüfen (wenn NAT im Einsatz)

show ip nat statistics
show ip nat translations

Testfallgruppe E: Rückkehr zum Primary (Failback ohne Ping-Pong)

Failback ist oft riskanter als Failover, weil instabile Links Flapping erzeugen können. Definieren Sie eine Stabilitätsregel (z. B. Delay) oder akzeptieren Sie bewusst manuelles Failback.

• Pass: Rückkehr zu ISP1 erst nach stabiler Probe (keine Flaps)
• Pass: Default wechselt kontrolliert, VPN stabil
• Fail: Ping-Pong zwischen ISPs, wiederkehrende VPN-Rekeys

Test E1: Failback Evidence

show clock
show ip sla statistics
show track
show ip route 0.0.0.0
show crypto ipsec sa
show logging | last 50

Testfallgruppe F: Negative Tests (Policy und Sicherheit)

UAT sollte nicht nur „funktioniert“, sondern auch „funktioniert nicht“ validieren. Das verhindert Policy-Leaks, die erst im Audit auffallen.

• Test: Managementzugriff nur aus MGMT-Netz (VTY Access-Class wirkt)
• Test: VPN nur für definierte Netze (keine ungewollten Routen)
• Test: NAT-Ausnahmen (No-NAT) greifen korrekt

CLI: Negative Test Evidence (Auszug)

show running-config | include line vty|access-class|transport input
show ip route summary
show access-lists

Evidence Collection: Struktur, Benennung und Mindestinhalt

Damit Evidence auditierbar ist, muss sie strukturiert abgelegt werden. Nutzen Sie pro Testfall einen Ordner oder eine Datei mit Zeitstempel und Gerät-ID.

• Benennung: SITEID_DEVICE_TESTID_TIMESTAMP
• Mindestinhalt: show clock + relevante show-Outputs + Ergebnis (Pass/Fail)
• Optional: Screenshots aus NOC/SIEM (Track down, VPN down Events)

CLI: Standard Evidence Pack (pro Testfall, minimal)

show clock
show ip route 0.0.0.0
show ip sla statistics
show track
show crypto ipsec sa
show crypto ikev2 sa
show interfaces counters errors
show logging | last 50

Pass/Fail Kriterien: Vorlage zur Abnahme

Abnahme wird objektiv, wenn Kriterien vorher feststehen. Definieren Sie Zielwerte für Umschaltzeit und akzeptablen Packet Loss, passend zur Businesskritikalität.

• Passen: Internet + VPN funktionsfähig nach Failover innerhalb Zielzeit
• Passen: keine anhaltenden Flaps (BGP/OSPF/VPN) im Abnahmefenster
• Passen: Evidence vollständig, Monitoring sichtbar (wenn Scope)
• Fail: wiederkehrende Flaps, „SA up aber kein Traffic“, Ping-Pong Failback

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.