Cisco-Router-Konfiguration für Dual-ISP: Failover-Design & Load Balancing

Eine Cisco-Router-Konfiguration für Dual-ISP (zwei Internetprovider) erhöht Verfügbarkeit und kann – richtig umgesetzt – auch die nutzbare Bandbreite verbessern. Entscheidend ist ein sauberes Failover-Design, das nicht nur „Link down“, sondern auch „Upstream kaputt“ erkennt, sowie ein kontrolliertes Load Balancing, das Applikationen und VPNs nicht ungewollt bricht. Dieser Leitfaden erklärt praxisnah typische Designs und zeigt CLI-Beispiele für Tracking, Failover und Lastverteilung.

Ziele und Grundbegriffe: Failover vs. Load Balancing

Dual-ISP kann zwei Ziele verfolgen: Ausfallsicherheit (Failover) oder Lastverteilung (Load Balancing). Viele Umgebungen brauchen beides, aber nicht jede Anwendung verträgt jede Balancing-Variante.

• Failover: ISP1 ist primär, ISP2 übernimmt bei Ausfall automatisch
• Active/Active: Beide Links werden gleichzeitig genutzt (Lastverteilung)
• Link-Status vs. Path-Status: Link kann „up“ sein, obwohl das Internet nicht erreichbar ist
• Symmetrie: Viele Sessions (VPN, Banking, SaaS) erwarten konsistente Quell-IP/Route

Design-Optionen im Vergleich

Die passende Variante hängt von Provider-Technik (statisch/DHCP/PPPoE), NAT, VPN-Anforderungen und der Frage ab, ob eingehende Dienste (Inbound) erreichbar sein müssen.

• Active/Standby mit Tracking: robust, simpel, sehr verbreitet
• ECMP (gleichwertige Default-Routen): einfache Lastverteilung, aber session-sensibel
• PBR (Policy-Based Routing): gezieltes Balancing nach VLAN/Applikation
• BGP Dual-Homing: Enterprise-Ansatz, optimale Kontrolle, höherer Aufwand

Failover-Design: Path-Tracking mit IP SLA und Objekt-Tracking

Ein gutes Failover schaltet nicht erst bei physischem Link-Down um, sondern wenn der Pfad ins Internet gestört ist (z. B. Provider-Routing, Upstream-Problem). Dazu wird IP SLA genutzt, um Ziele zu überwachen, und Tracking steuert die Default-Route.

Best Practices für IP SLA Ziele

• Nicht nur 1 Ziel überwachen: besser 2–3 Ziele (z. B. Provider-Gateway + Public DNS)
• Ziele pro ISP unterscheiden, damit Fehlersuche sauber bleibt
• Frequenz und Timeout realistisch wählen (z. B. 5s, 1–2 Retries)
• Monitoring aus dem jeweiligen WAN-Interface sourcen

Beispiel: ISP1 primär, ISP2 Backup (Default-Route mit Tracking)

interface GigabitEthernet0/0
 description WAN-ISP1
 ip address 198.51.100.2 255.255.255.252
 no shutdown
interface GigabitEthernet0/2

description WAN-ISP2

ip address 203.0.113.2 255.255.255.252

no shutdown
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

Failover-Verifikation (SOP-Checks)

show ip sla statistics
show track
show ip route 0.0.0.0
show interfaces counters errors
ping 8.8.8.8 source GigabitEthernet0/0
ping 8.8.8.8 source GigabitEthernet0/2

Load Balancing: Was wirklich funktioniert – und was Probleme macht

Lastverteilung ist nicht gleich Bandbreitenaddition für eine einzelne Session. In der Praxis wird pro Flow verteilt. Große Downloads bleiben oft auf einem Link, aber viele parallele Sessions profitieren deutlich.

ECMP (Equal-Cost Multi-Path) mit zwei Default-Routen

ECMP ist einfach: zwei Default-Routen mit gleichem Administrative Distance. Der Router verteilt Flows über beide Next-Hops. Vorteil: wenig Konfig. Nachteil: manche Applikationen reagieren empfindlich, wenn Sessions über unterschiedliche Quellpfade gehen.

ip route 0.0.0.0 0.0.0.0 198.51.100.1
ip route 0.0.0.0 0.0.0.0 203.0.113.1

Praxis-Hinweis zu NAT bei ECMP

Wenn beide Links NAT nutzen, muss sichergestellt sein, dass Return-Traffic zur richtigen öffentlichen Quell-IP zurückkommt. In vielen Filial-Designs ist daher PBR oder Active/Standby stabiler als „blindes“ ECMP.

Gezielte Lastverteilung mit PBR (Policy-Based Routing)

PBR ist ideal, wenn Sie definieren möchten, welcher Traffic über welchen ISP geht, z. B. Guest über ISP2, Business über ISP1, oder bestimmte Zielnetze (SaaS) über den schnelleren Link. Wichtig sind Tracking und ein Fallback, damit PBR bei ISP-Ausfall nicht Blackholing verursacht.

Typische PBR-Strategien

• Nach VLAN/Subnetz: z. B. Guest über ISP2, Users über ISP1
• Nach Anwendung/Ziel: z. B. Microsoft 365 über ISP1, Backups über ISP2
• Nach Priorität: kritische Systeme primär, weniger kritische sekundär

Beispiel: Guest-Netz über ISP2, Rest über ISP1 (mit Tracking)

ip access-list extended ACL-GUEST
 permit ip 10.10.30.0 0.0.0.255 any
route-map PBR-GUEST permit 10

match ip address ACL-GUEST

set ip next-hop verify-availability 203.0.113.1 10 track 10
interface GigabitEthernet0/1.30

description VLAN30-GUEST

encapsulation dot1Q 30

ip address 10.10.30.1 255.255.255.0

ip policy route-map PBR-GUEST

Wichtig: PBR und NAT konsistent halten

Wenn Guest über ISP2 läuft, sollte NAT für Guest ebenfalls über ISP2 erfolgen. Sonst entstehen asymmetrische Pfade und schwer zu diagnostizierende Verbindungsabbrüche.

NAT-Design für Dual-ISP: Stabilität durch klare Regeln

Bei Dual-ISP ist NAT oft die größte Fehlerquelle. Ziel ist, dass Traffic, der über ISP1 rausgeht, auch mit der ISP1-Quelladresse genattet wird – und entsprechend für ISP2. Bei Failover muss klar sein, wie bestehende Sessions behandelt werden.

Empfohlene NAT-Ansätze

• Active/Standby: NAT nur auf dem aktiven Uplink (einfach, stabil)
• PBR-basiert: getrennte NAT-ACLs pro VLAN/ISP
• Session-Persistence beachten: bei Failover brechen bestehende NAT-Sessions meist ab

Beispiel: Getrennte NAT-ACLs für ISP1 und ISP2 (vereinfachtes Muster)

ip access-list standard NAT_ISP1
 permit 10.10.10.0 0.0.0.255
 permit 10.10.20.0 0.0.0.255
ip access-list standard NAT_ISP2

permit 10.10.30.0 0.0.0.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_ISP1 interface GigabitEthernet0/0 overload

ip nat inside source list NAT_ISP2 interface GigabitEthernet0/2 overload

VPN und Dual-ISP: Designregeln für stabile Tunnel

VPNs sind oft die ersten Kandidaten, die bei Dual-ISP-Problemen auffallen. Der Grund: Tunnelendpunkte, Selektoren und Routing müssen konsistent sein. Viele Unternehmen setzen daher ein Primary/Backup-Design mit klaren Peers oder nutzen dynamische Mechanismen (je nach Plattform und Gegenstelle).

• Primary/Backup-Tunnel: zwei Peers oder zwei Tunnelinterfaces, klare Priorität
• Keepalives/DPD: schnelle Erkennung von Peer-Ausfällen
• Routing über Tunnel: bevorzugt deterministisch (z. B. via AD/Tracking)
• MTU/MSS: bei VPN über beide ISPs konsistent halten

VPN-Checks (betrieblich wichtig)

show crypto ikev2 sa
show crypto ipsec sa
show crypto session detail
show ip route

Abnahme- und Failover-Tests: Was Sie zwingend testen sollten

Ein Dual-ISP-Design gilt erst als „fertig“, wenn Failover- und Rückschaltverhalten gemessen und dokumentiert sind. Tests sollten definieren, was „akzeptabel“ ist (z. B. Umschaltzeit, betroffene Services, Session-Abbrüche).

• ISP1-Ausfall: physisch (Link down) und logisch (Gateway/Internet nicht erreichbar)
• ISP2-Ausfall: analog testen, falls Active/Active oder Backup-Betrieb
• Rückschalten (Failback): kontrolliert, ohne Flapping (ggf. mit Delay/Threshold)
• NAT-Verhalten: neue Sessions erfolgreich, bestehende Sessions erwartbar abbrechend
• VPN: Tunnel-Neuaufbauzeit, erreichbare Netze, Applikationspfade

Beispiel: Standard-Post-Checks nach Umschaltung

show ip route 0.0.0.0
show track
show ip sla statistics
show interfaces counters errors
ping 8.8.8.8 source GigabitEthernet0/0
ping 8.8.8.8 source GigabitEthernet0/2
traceroute 1.1.1.1

Typische Stolpersteine bei Dual-ISP und wie Sie sie vermeiden

Dual-ISP ist robust, wenn Routing, NAT, PBR und VPN konsistent gedacht werden. Viele Probleme entstehen durch „gemischte“ Logik: PBR ohne Tracking, NAT ohne Trennung oder fehlende Tests für Path-Failures.

• Nur Link-Down-Erkennung: ISP-Routing kaputt, Router bleibt auf „totem“ Pfad
• ECMP ohne NAT-Design: asymmetrische Pfade, sporadische Abbrüche
• PBR ohne verify-availability: Blackholing bei ISP-Ausfall
• VPN ohne klare Priorität: Tunnel flappen, Routing instabil
• Kein Failback-Konzept: permanenter Backup-Betrieb oder unnötiges Flapping

Praxis-Tipp: Lastverteilung realistisch planen

Wenn das Ziel „mehr Bandbreite“ ist, prüfen Sie zuerst, ob Ihre Anwendungen von Flow-basierter Verteilung profitieren. Häufig ist ein Design „Business auf ISP1, Guest/Backups auf ISP2“ stabiler und im Alltag wirksamer als aggressives ECMP.

• Applikationen mit vielen parallelen Sessions profitieren am stärksten
• Session-sensitive Dienste gezielt auf einen ISP pinnen
• Load Balancing immer mit Monitoring und klaren SOPs betreiben

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.