Case Study: Dual-ISP-Failover auf Cisco-Routern mit Lasttest und Evidenzen

Dual-ISP-Failover auf Cisco-Routern wirkt in vielen Umgebungen „konfiguriert“, ist aber erst dann production-grade, wenn es unter Last stabil umschaltet und der Servicepfad nachweisbar wiederhergestellt wird. Typische Fehlschläge entstehen durch Path-down (Link bleibt up, Internet ist trotzdem tot), durch nicht getestete Rückkehr zum Primary (Ping-Pong) oder durch VPN-/SaaS-Abhängigkeiten, die bei Umschaltung abbrechen. Diese Case Study beschreibt ein praxisnahes Referenzszenario: Dual-ISP-Failover mit IP SLA/Tracking, Lasttest während der Umschaltung und systematische Evidence Collection (CLI + Messwerte). Ziel ist ein wiederholbares Vorgehen für UAT, Abnahme und Audits.

Ausgangslage: Warum Failover ohne Lasttest trügerisch ist

In vielen Projekten wird Failover mit „ping geht wieder“ abgenommen. Unter echter Last (VoIP, Video, große Downloads, VPN) zeigen sich jedoch Queue Drops, MTU/MSS-Effekte und verzögerte Konvergenz.

• Link-down wird getestet, Path-down nicht
• Umschaltung wird ohne Traffic durchgeführt (kein realer Servicebeweis)
• Failback wird nicht geprüft (Ping-Pong Risiko)
• Evidence ist unvollständig (kein Audit Trail, keine Zeitstempel)

Zielsetzung: Abnahmekriterien für Dual-ISP im Enterprise

Die Abnahme erfolgte über messbare Kriterien: Umschaltzeit, Packet Loss während Umschaltung, Stabilität (keine Flaps) und Service-Recovery für kritische Anwendungen.

• Failover: ISP1 → ISP2 in definierter Zielzeit
• Stabilität: keine wiederkehrenden Track/Route Flaps im Beobachtungsfenster
• Service: Internet (DNS/HTTPS) und ggf. VPN weiterhin funktionsfähig
• Evidence: CLI-Snapshots + Lasttest-Messwerte + Zeitstempel

Failover-Zeit als messbare Kette

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

Referenzdesign: Dual-ISP mit IP SLA, Tracking und Default-Route-Steuerung

Das Design nutzte IP SLA für Path-down Detection und Tracking zur Steuerung der Default-Route. Damit wird Failover nicht nur bei Link-down, sondern auch bei Upstream-Problemen ausgelöst.

• ISP1: Primary Default Route (niedrigere Administrative Distance)
• ISP2: Backup Default Route (höhere Administrative Distance)
• IP SLA: Probe zu stabilem Ziel (z. B. HQ/Resolver/Public DNS)
• Track: koppelt Reachability an Routing-Entscheidung

CLI: IP SLA + Track (Beispiel)

ip sla 10
 icmp-echo 1.1.1.1 source-interface GigabitEthernet0/0
 frequency 10
 timeout 1000
ip sla schedule 10 life forever start-time now
track 10 ip sla 10 reachability
ip route 0.0.0.0 0.0.0.0 203.0.113.1 track 10

ip route 0.0.0.0 0.0.0.0 198.51.100.1 250

Testaufbau: Lasttest, Messpunkte und Beobachtungsfenster

Der Lasttest wurde bewusst so gestaltet, dass er typische Branch-Last abbildet: parallele TCP-Flows (SaaS), kontinuierliche ICMP-Probes (RTT/Loss) und optional VoIP/Video-Simulation.

• Messpunkte: Router (IP SLA), NOC Probe, Testhost im LAN
• Last: mehrere gleichzeitige Downloads/Uploads (TCP), optional UDP für Echtzeit
• Beobachtungsfenster: vor Umschaltung (Baseline), während Umschaltung, nach Stabilisierung
• Logging: NTP synchronized, Syslog aktiv (Events korrelierbar)

Testfälle: Link-down, Path-down und Failback unter Last

Die Case Study nutzte drei Testfälle, weil sie unterschiedliche Fehlerklassen abdecken. Jeder Test wurde mit identischem Evidence Pack dokumentiert.

• Test 1: ISP1 Link-down (Interface down) unter Last
• Test 2: ISP1 Path-down (Upstream unreachability) unter Last
• Test 3: Failback zu ISP1 (Rückkehr) ohne Ping-Pong

Baseline (vor dem Lasttest): Pre-Checks und Referenzwerte

Vor jeder Umschaltung wurde der Normalzustand dokumentiert. Ohne Baseline sind Messwerte nicht interpretierbar und Audits nicht belastbar.

CLI: Pre-Test Evidence Pack

terminal length 0
show clock
show ntp status
show ip interface brief
show interfaces counters errors
show interfaces | include output drops|queue
show ip route 0.0.0.0
show ip sla statistics
show track
show logging | last 50
show processes cpu sorted

Test 1 Ergebnisse: Link-down Failover unter Last (Beobachtungen)

Beim Link-down wechselte die Default-Route zuverlässig auf ISP2. Kritisch war die Beobachtung von Drops/Queue während der Umschaltung sowie die Zeit bis zur Wiederherstellung von HTTPS/DNS.

• Pass: Track/Default Route wechselt auf ISP2
• Pass: Lastflüsse laufen nach kurzer Unterbrechung weiter
• Check: output drops/queue drops steigen nicht dauerhaft an
• Check: CPU bleibt im stabilen Bereich (keine Control-Plane Überlast)

CLI: Evidence während Umschaltung (Link-down)

show clock
show ip route 0.0.0.0
show track
show ip sla statistics
show interfaces | include output drops|queue
show logging | include LINEPROTO|LINK-|TRACK|IP_SLA

Test 2 Ergebnisse: Path-down Failover unter Last (entscheidender Enterprise-Test)

Dieser Test zeigte den Mehrwert von IP SLA: Link blieb up, aber der Pfad war gestört. Ohne SLA/Tracking wäre der Router auf ISP1 geblieben und der Standort hätte „Internet up“ gemeldet, obwohl Services nicht funktionieren.

• Pass: IP SLA erkennt Unreachability, Track geht down
• Pass: Default Route wechselt trotz Link-up auf ISP2
• Check: Logs enthalten Track/IP SLA Events mit korrekter Zeit
• Check: RTT/Loss normalisieren sich nach Umschaltung

CLI: Evidence Path-down

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

Test 3 Ergebnisse: Failback und Stabilität (Ping-Pong vermeiden)

Failback wurde erst nach stabiler Probe durchgeführt. Ziel war, Flapping zu vermeiden, das unter Last besonders störend ist. Als Best Practice wurde Failback optional zeitverzögert oder manuell geregelt.

• Pass: Rückkehr zu ISP1 erst nach stabiler Reachability
• Pass: keine wiederkehrenden Track-Flaps nach Failback
• Check: Lasttest bleibt stabil, keine dauerhaften Drops

CLI: Failback Evidence

show clock
show ip sla statistics
show track
show ip route 0.0.0.0
show logging | last 100

Lasttest-Evidence: Was dokumentiert wurde (Template)

Damit der Lasttest auditierbar ist, wurden Messwerte und CLI-Ausgaben zeitlich verknüpft. Wichtig sind Zeitstempel und eine klare Zuordnung zu Standort und Testfall.

• Messwerte: RTT/Loss vor/während/nach Umschaltung
• Traffic: Durchsatz/Flow-Zahlen (aus Testtool), optional Screenshots
• Router: Interface Drops, CPU, Track/IP SLA, Default Route
• Logs: Track/Interface Events, ggf. BGP/OSPF (falls relevant)

Evidence Pack: Standardisiertes Bundle pro Testfall

Dieses Bundle wurde pro Testfall als Textdatei gespeichert (SITE_DEVICE_TESTID_TIMESTAMP). Es eignet sich für Abnahmeprotokolle und spätere RCA.

terminal length 0
show clock
show ntp status
show ip interface brief
show interfaces counters errors
show interfaces | include output drops|queue
show ip route 0.0.0.0
show ip sla statistics
show track
show logging | last 150
show processes cpu sorted

Lessons Learned: Praktische Verbesserungen aus der Case Study

Aus den Tests wurden konkrete Preventive Actions abgeleitet, um Failover künftig reproduzierbar und weniger riskant zu machen.

• Path-down Tests als Pflicht-UAT, nicht optional
• IP SLA Targets: mindestens ein internes (HQ) und ein externes Ziel
• Failback-Regel: stabilitätsbasiert (Delay) oder bewusst manuell
• NOC-Alarme: Track down, Failover Count, sustained Loss/RTT
• Evidence Packs als Go-Live Gate in jedem Change Window

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.