Static Routes mit Tracking sind eine der zuverlässigsten und einfachsten Methoden, um Failover auf Cisco-Routern umzusetzen – ohne komplexes Routing-Protokoll und ohne BGP. Statt „zwei Default-Routen hoffen“ überwachen Sie den Internetpfad aktiv (IP SLA) und koppeln die primäre Route an einen Track-Status. Fällt der Pfad aus, wird die Route automatisch entfernt und eine Backup-Route übernimmt. Dieser Leitfaden zeigt ein praxistaugliches Design, sinnvolle Standardwerte und eine Verifikations-Checkliste.
Wann Static Routes + Tracking die beste Wahl sind
Dieses Design eignet sich besonders für kleine bis mittlere Standorte, Filialen und Büros, die Dual-WAN oder einen Backup-Uplink (z. B. LTE) haben. Die Komplexität bleibt gering, das Verhalten ist deterministisch.
- Single-Standort mit Primary/Backup-Internet
- Filiale mit Dual-ISP ohne BGP
- Backup-Link für kritische Dienste (z. B. Payment/VPN)
- Umgebungen mit wenig Change-Frequenz und klaren Pfaden
Grundprinzip: Warum Tracking besser ist als „nur Administrative Distance“
Eine Backup-Route mit höherer Administrative Distance übernimmt erst, wenn die primäre Route fehlt. Ohne Tracking bleibt die primäre Route jedoch oft aktiv, obwohl „Internet down“ ist (z. B. Provider-Transit gestört). Tracking löst genau dieses Problem, weil es den Pfad statt nur den Link überwacht.
- Ohne Tracking: Link up, Internet down → Router nutzt weiter die primäre Default-Route
- Mit Tracking: Path down → Route wird entfernt → Backup übernimmt
- Ergebnis: kürzere Störphasen, weniger manuelle Eingriffe
Design: Auswahl der Tracking-Ziele
Wählen Sie Tracking-Ziele, die stabil und repräsentativ sind. Idealerweise testen Sie nicht nur „irgendeine öffentliche IP“, sondern mehrere Ziele oder einen Provider-Edge, sofern zuverlässig erreichbar.
- Mindestens ein externes Ziel (z. B. öffentliche DNS-Resolver)
- Optional zusätzlich: ein Ziel in Ihrer Cloud/Zentrale (Business-Pfad)
- Quelle festlegen: source-interface des jeweiligen WAN
- Timeout/Frequenz so wählen, dass Flapping vermieden wird
Konfiguration: IP SLA + Track + Default-Routen (Primary/Backup)
Das Standardmuster besteht aus: IP SLA prüft Erreichbarkeit, Track bewertet das Ergebnis, die primäre Default-Route ist an Track gebunden, die Backup-Route hat höhere Administrative Distance.
Beispiel: WAN-Interfaces (Primary und Backup)
interface GigabitEthernet0/0
description WAN-ISP1-PRIMARY
ip address 198.51.100.2 255.255.255.252
no shutdown
interface GigabitEthernet0/2
description WAN-ISP2-BACKUP
ip address 203.0.113.2 255.255.255.252
no shutdown
Beispiel: IP SLA für den Primary-Pfad
ip sla 10
icmp-echo 8.8.8.8 source-interface GigabitEthernet0/0
frequency 5
timeout 1000
ip sla schedule 10 life forever start-time nowBeispiel: Track an IP SLA koppeln
track 10 ip sla 10 reachabilityBeispiel: Default-Routen mit Failover
ip route 0.0.0.0 0.0.0.0 198.51.100.1 track 10
ip route 0.0.0.0 0.0.0.0 203.0.113.1 200Optional: Backup-Pfad ebenfalls überwachen (sauberer Failback)
Wenn auch der Backup-Uplink instabil sein kann, definieren Sie ein eigenes IP SLA/Tracking dafür. Das verhindert unkontrollierte Failbacks und erleichtert Monitoring.
Beispiel: IP SLA für Backup-Pfad (optional)
ip sla 20
icmp-echo 1.1.1.1 source-interface GigabitEthernet0/2
frequency 5
timeout 1000
ip sla schedule 20 life forever start-time now
track 20 ip sla 20 reachability
Failover-Verhalten: Umschaltzeiten und Stabilität
Umschaltzeiten hängen von SLA-Frequenz und Timeout ab. Zu aggressive Werte erhöhen Flapping-Risiko. Für viele Büros sind 5 Sekunden Frequenz und 1 Sekunde Timeout ein guter Start, müssen aber zur Leitungsqualität passen.
- Zu aggressiv: häufiges Hin-und-Her bei kurzzeitigen Loss-Spikes
- Zu träge: längere Störphase, bis Track „down“ wird
- Praxis: lieber stabil und dokumentiert testen als „millisekundenschnell“
NAT bei Failover: Der häufigste Praxis-Stolperstein
Wenn NAT auf dem Router liegt, muss klar sein, welches WAN-Interface NAT-Outside ist. In Dual-WAN-Szenarien ist es wichtig, dass NAT bei Umschaltung ebenfalls konsistent funktioniert oder bewusst nur für den aktiven Pfad konfiguriert ist.
Beispiel: NAT Overload auf Primary (und bei Failover anpassen)
ip access-list standard NAT_INSIDE
permit 10.10.0.0 0.0.255.255
interface GigabitEthernet0/0
ip nat outside
interface GigabitEthernet0/2
ip nat outside
interface GigabitEthernet0/1
ip nat inside
ip nat inside source list NAT_INSIDE interface GigabitEthernet0/0 overload
Verifikation NAT
show ip nat statistics
show ip nat translationsVerifikation: So weisen Sie das Failover objektiv nach
Nach der Konfiguration müssen Sie zeigen, dass Track arbeitet, die primäre Route verschwindet und die Backup-Route übernimmt. Zusätzlich sollten Sie Pfadtests und Logs prüfen.
Tracking- und Routing-Checks
show ip sla statistics
show track
show ip route 0.0.0.0Pfadtests (vor/nach Umschaltung vergleichen)
ping 8.8.8.8 repeat 20
traceroute 1.1.1.1Erwartete Ergebnisse
- Track 10 ist Up im Normalbetrieb, Default-Route zeigt auf ISP1
- Bei Path-Ausfall wird Track 10 Down, Route über ISP1 verschwindet
- Backup-Default über ISP2 wird aktiv (AD 200)
Failover-Testplan: Sicher testen ohne Überraschungen
Testen Sie nicht „im Blindflug“. Simulieren Sie Link-Down oder Path-Down kontrolliert und dokumentieren Sie Umschaltzeiten. Bei produktiven Standorten gehört ein Rollback-Plan dazu.
- Test 1: Primary Link Down (Interface shut) → Backup übernimmt
- Test 2: Path Down (Upstream blockieren/Provider testen) → Track wird Down
- Test 3: Failback → Primary übernimmt wieder ohne Flapping
- Dokumentation: Zeiten, Pfade (Traceroute), betroffene Sessions
Typische Fehlerbilder und schnelle Ursachen
Wenn Failover nicht funktioniert, liegt es meist an falscher Source-Interface-Angabe, einem ungeeigneten Tracking-Ziel oder an NAT/Policy-Abhängigkeiten. Diese Punkte prüfen Sie zuerst.
- Track bleibt Up trotz Störung: Ziel ist noch erreichbar oder falsche Quelle
- Track wird Down, aber Route bleibt: track nicht in Route eingebunden
- Failover ok, aber Internet tot: NAT/Firewall/Policies nicht failover-fähig
- Flapping: SLA zu aggressiv, instabile Leitung, kein stabiler Failback
Minimaler Template-Baustein (Copy/Paste geeignet)
Dieses Template bündelt den Kern: IP SLA, Track, Primary Default mit Track und Backup Default mit höherer Administrative Distance. IPs und Interfaces sind Platzhalter.
ip sla 10
icmp-echo 8.8.8.8 source-interface GigabitEthernet0/0
frequency 5
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 198.51.100.1 track 10
ip route 0.0.0.0 0.0.0.0 203.0.113.1 200
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.
