Site icon bintorosoft.com

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

Red Snapper

Computer engineer configuring network settings on a laptop with an expansive server room in the background AI generated

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.

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-Zeit als messbare Kette

Failover_Zeit = Detection + Convergence + Service_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.

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.

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.

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.

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.

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.

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.

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.

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

Sie erhalten

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.

Exit mobile version