Dual-ISP-Design auf Cisco-Routern: Failover, Load Sharing und End-to-End-Verifikation

Ein Dual-ISP-Design auf Cisco-Routern reduziert Downtime, wenn es nicht nur „zwei Leitungen“ bereitstellt, sondern Failover-Kriterien, Pfad-Überwachung (Path-Down) und saubere Verifikation end-to-end definiert. In der Praxis sind Providerstörungen mit Link-up deutlich häufiger als echte Link-down-Events. Deshalb reicht eine zweite Default-Route nicht aus: Sie brauchen IP SLA/Tracking, klare Prioritäten (Active/Standby oder Load Sharing) und Tests, die Internet, DNS, VPN und kritische Apps einbeziehen. Dieser Leitfaden zeigt praxistaugliche Designs für Failover und Load Sharing – inklusive CLI-Beispiele und Checklisten.

Designentscheidungen: Active/Standby vs. Load Sharing

Bevor Sie konfigurieren, müssen Sie das Betriebsziel festlegen. Active/Standby ist robuster und einfacher zu betreiben. Load Sharing kann Bandbreite besser nutzen, erhöht aber Komplexität (Symmetrie, Policies, NAT, VPN).

• Active/Standby: ein Primary Pfad, Backup nur bei Störung (Standard für viele Unternehmen)
• Load Sharing: beide Links aktiv (z. B. per PBR oder ECMP), mehr Komplexität
• BGP Dual-ISP: für öffentliche Präfixe/Policies, höchste Komplexität, höchste Kontrolle

Ausfallmodelle: Link-Down vs. Path-Down

Dual-ISP muss beide Ausfallarten abdecken. Link-Down ist physischer Ausfall. Path-Down ist Upstream-Ausfall bei Link-up – der häufigste Grund für „Internet weg, aber Interface up“.

• Link-Down: Interface down (Carrier lost)
• Path-Down: Upstream/Transit/DNS/Peering gestört (Interface bleibt up)
• Designziel: Path-Down innerhalb definierter Zeit erkennen und umschalten

Basis-Architektur: Zwei WAN-Interfaces, klarer Inside/Outside

Unabhängig vom Modus müssen WAN-Interfaces eindeutig sein und NAT/Routing sauber zugeordnet werden. Interface-Descriptions mit Circuit-ID sind Pflicht für Betrieb und Provider-Tickets.

• WAN1: ISP1 PRIMARY (Interface, IP, Gateway, MTU/VLAN)
• WAN2: ISP2 BACKUP (Interface, IP, Gateway, MTU/VLAN)
• LAN: inside (VLAN/Subinterfaces), Policies, DHCP/DNS-Design

CLI: Interface-Standards (Beispiel)

interface GigabitEthernet0/0
 description WAN-ISP1-PRIMARY-CID12345
 ip address 198.51.100.2 255.255.255.252
 ip nat outside
 no shutdown
interface GigabitEthernet0/2

description WAN-ISP2-BACKUP-CID67890

ip address 203.0.113.2 255.255.255.252

ip nat outside

no shutdown

Failover-Design (Active/Standby): Default-Routen + IP SLA/Tracking

Das Standarddesign nutzt eine Primary Default-Route, die an Tracking gebunden ist. Fällt der Pfad (Link-Down oder Path-Down), wird die Route entfernt und die Backup-Default greift über höhere Administrative Distance.

IP SLA + Tracking (Path-Down Erkennung)

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

Default-Routen (Primary tracked, Backup mit höherer AD)

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

Verifikation Failover-Pfad

show ip sla statistics
show track
show ip route 0.0.0.0

Wichtige Parameter: Targets, Frequenz und Failback

IP SLA ist nur so gut wie das Target. Nutzen Sie idealerweise ein Provider-nahes Target und zusätzlich ein neutrales Internet-Target. Failback sollte kontrolliert erfolgen, um Flapping bei instabilem Provider zu vermeiden.

• Targets: mindestens zwei (z. B. Provider-GW + Public Resolver)
• Frequenz/Timeout: schnell genug für Business, nicht zu empfindlich
• Failback: optional verzögert, um Flapping zu reduzieren

Load Sharing ohne BGP: ECMP vs. Policy-Based Routing (PBR)

Load Sharing ist in der Praxis entweder ECMP (gleichwertige Routen) oder PBR (Policy-basiert). ECMP ist einfach, aber weniger steuerbar. PBR ist steuerbar, aber erfordert sauberes Monitoring und klare Ausnahmebehandlung.

• ECMP: zwei Default-Routen mit gleicher AD, Hashing verteilt Flows
• PBR: bestimmte Quellen/Segmente/Apps über ISP1 oder ISP2
• Wichtig: bei NAT/VPN muss Symmetrie bedacht werden (Return Path)

Load Sharing mit PBR: Segmentbasiertes Beispiel (konzeptionell)

Ein typischer Ansatz ist, Guest über ISP2 und Corporate über ISP1 zu senden. Für Stabilität müssen Sie Path-Down erkennen und PBR bei Ausfall sauber umgehen.

• Users: bevorzugt ISP1 (Primary)
• Guest: bevorzugt ISP2 (Secondary)
• Failover: bei Path-Down wird PBR-Next-Hop ungültig und Default greift

BGP Dual-ISP: Wann es sinnvoll ist

BGP ist sinnvoll, wenn Sie eigene öffentliche Präfixe announcen, Inbound/Outbound steuern oder echte Provider-Redundanz mit Policies brauchen. Mindeststandard sind Filter und max-prefix, sonst drohen Instabilität und Routenleaks.

• Eigene ASN und öffentliche Präfixe vorhanden
• Policy-Anforderungen: Traffic-Engineering, kontrollierter Inbound
• Mehr Aufwand: Design, Provider-Abhängigkeiten, Tests, Betrieb

Dual-ISP und VPN: Typische Stolpersteine

VPNs reagieren empfindlich auf Pfadwechsel. Planen Sie daher, wie VPN-Tunnel auf beiden ISPs funktionieren sollen (Dual-Hub, Dual-Peer, DPD/Rekey). Prüfen Sie immer Traffic, nicht nur SA-Up.

• Nur Primary VPN: Failover führt zu VPN-Ausfall (wenn kein Backup-Tunnel)
• No-NAT Regeln müssen für beide Pfade korrekt sein
• MTU/MSS: Overhead kann bei Providerwechsel zu Fragmentierung führen

VPN-Checks (Pflicht im Dual-ISP UAT)

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

End-to-End-Verifikation: Was im UAT getestet werden muss

Dual-ISP gilt erst als abgenommen, wenn sowohl Link-Down als auch Path-Down getestet wurden – und die wichtigsten Services (DNS, HTTPS, VPN, Business-Apps) nach Umschaltung funktionieren. Messen Sie Umschaltzeit und dokumentieren Sie Evidence.

• Baseline: RTT/Loss auf ISP1 und ISP2 messen
• Test 1: Link-Down ISP1 → Internet ok, DNS ok, VPN ok (wenn Scope)
• Test 2: Path-Down ISP1 (IP SLA Fail) → Umschaltung, kein Flapping
• Test 3: Failback → kontrollierte Rückübernahme
• Optional: Load Sharing Test → Flows verteilen, Return Path stabil

Evidence-Set (Copy/Paste)

show ip sla statistics
show track
show ip route 0.0.0.0
show ip nat translations
show crypto ipsec sa
show logging | include LINEPROTO|LINK-|IPSLAs
ping 1.1.1.1 repeat 20
traceroute 1.1.1.1

Typische Fehlerbilder und wie Sie sie vermeiden

Die meisten Dual-ISP-Probleme entstehen durch fehlende Path-Down-Erkennung, falsche Targets oder ungetesteten Failback. Nutzen Sie diese Liste als Design-Review-Check.

• Nur zweite Default-Route: Path-Down wird nicht erkannt
• Falsches IP SLA Target: Ziel bleibt erreichbar trotz Providerstörung
• PBR ohne Fallback: Traffic „blackholed“ bei Next-Hop-Ausfall
• VPN nicht redundant: Failover = Tunnel down
• Failback ohne Kontrolle: Flapping bei instabilem ISP
• Keine Alarme: Backup-Link tot, fällt erst im Ernstfall auf

Operability: Monitoring und Alarmierung für Dual-ISP

Dual-ISP muss überwacht werden, sonst ist Redundanz nur „auf dem Papier“. Definieren Sie Alarme für Link/Path, Default-Route-Status und VPN/Routing-Events.

• WAN Link Down/Flaps je ISP
• IP SLA Path-Down je ISP (kritisch)
• Default-Route-Change Events
• VPN SA Down/Flaps (wenn VPN genutzt)

CLI: Operability-Snapshot

show ip interface brief
show ip sla statistics
show track
show ip route 0.0.0.0
show logging | last 100

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.