Multi-ISP VPN Resilience: Dual Uplinks ohne Tunnel-Flapping

Multi-ISP VPN Resilience ist das Versprechen, dass Standortvernetzung und Remote-Access auch dann stabil bleiben, wenn eine Internetleitung schwankt, ein Provider Routing-Probleme hat oder ein BGP-Backbone kurzzeitig instabil wird. In der Praxis sehen viele Dual-Uplink-Setups jedoch genau anders aus: Tunnel flapppen, Rekey schlägt sporadisch fehl, Sessions reißen bei jeder Mikrostörung ab, oder der Traffic pendelt zwischen ISP A und ISP B, bis Nutzer komplett aufgeben. Der Grund ist selten „zu wenig Redundanz“, sondern eine falsche Kopplung von Underlay- und Overlay-Signalen: Link-Status, NAT/CGNAT-Verhalten, DPD/Keepalives, Routing-Preferenzen und Health-Checks greifen nicht sauber ineinander. Professionelles Dual-ISP-Design bedeutet deshalb: stabile Umschaltung mit Hysterese, klare Pfadpräferenz statt nervösem ECMP, Tracking auf Service-Ebene statt nur auf Interface-Ebene, sowie ein VPN-Profil, das NAT-T, MTU/MSS und Rekey-Last realistisch berücksichtigt. Dieser Artikel zeigt, wie Sie Dual Uplinks ohne Tunnel-Flapping planen: Architekturpatterns, Failure Detection (IP SLA/BFD), Routing- und Policy-Strategien, typische Fallstricke und konkrete Guardrails für einen Betrieb, der auch unter Provider-Degradation stabil bleibt.

Warum Dual-Uplink-Designs so oft flapppen

Ein zweiter ISP löst nicht automatisch Stabilität. Im Gegenteil: Er erhöht die Anzahl möglicher Pfade und damit die Wahrscheinlichkeit für wechselnde Zustände. Tunnel-Flapping entsteht typischerweise, wenn Umschaltung zu aggressiv ist oder wenn unterschiedliche Ebenen unterschiedliche Wahrheiten „sehen“.

• Interface up, Internet kaputt: Der Link ist physisch aktiv, aber der Provider droppt Pakete oder hat Routing-Issues. Ohne Service-Tracking bleibt der Tunnel „scheinbar“ up.
• NAT- und Port-Mappings wechseln: Bei Provider-NAT, CGNAT oder wechselnden CPEs ändern sich UDP-Mappings; ohne passende Keepalives wirkt der Tunnel instabil.
• DPD/Keepalive zu aggressiv: Mikro-Loss oder Rekey-Delays werden als Peer-Down interpretiert, Tunnel wird gelöscht, Reconnect startet.
• ECMP ohne State-Konzept: Traffic verteilt sich, Rückwege werden asymmetrisch, stateful Firewalls/NAT brechen Sessions.
• Failback ohne Hysterese: Sobald ISP A „wieder da“ ist, wird zurückgeschaltet – oft zu früh, und das Ping-Pong beginnt.

Designziel: Stabilität vor „maximaler Umschaltgeschwindigkeit“

Viele Dual-ISP-Projekte optimieren auf schnelle Umschaltzeiten. Das klingt gut, führt aber häufig zu Flapping. Ein professionelles Zielbild priorisiert:

• Deterministische Pfade: Ein klar bevorzugter Primärpfad, ein kontrollierter Sekundärpfad.
• Degradation-aware Failover: Nicht nur „down“, sondern auch „schlecht“ erkennen – und richtig reagieren.
• Hysterese und Hold-down: Rückschaltung erst, wenn der Primärpfad über einen Zeitraum wirklich stabil ist.
• End-to-end Health: Nicht nur Link, sondern VPN-Data-Plane und reale Services müssen gesund sein.

Underlay vs. Overlay: Dual-ISP heißt zwei Layer sauber trennen

Ein belastbares Design trennt konsequent das Underlay (ISP-Links) vom Overlay (VPN). Underlay-Probleme dürfen nicht unkontrolliert in Overlay-Flapping übersetzen, und Overlay muss in der Lage sein, Underlay-Degradation korrekt zu interpretieren.

• Underlay Signale: Interface-Status, Paketverlust, RTT/Jitter, Provider-Gateway-Erreichbarkeit.
• Overlay Signale: IKE/TLS Handshake, Rekey-Erfolg, ESP/Data-Plane-Drops, DPD-Events.
• Routing Signale: BGP/OSPF Session State, Prefix-Withdraw/Announce, Preferenzen.

Für IKEv2-Mechanik ist RFC 7296 relevant, für IPsec-Architekturprinzipien RFC 4301.

Topologie-Patterns für Dual Uplinks

Dual ISP kann auf verschiedene Weisen umgesetzt werden. Die Wahl bestimmt, wie viel Komplexität Sie im Routing und im Failover-Tracking beherrschen müssen.

Pattern: Active/Standby Uplink mit kontrolliertem Failover

• Prinzip: ISP A ist primär, ISP B sekundär. VPN nutzt standardmäßig A.
• Vorteil: Sehr stabil, geringe Asymmetrie-Risiken, einfaches Troubleshooting.
• Nachteil: Sekundärkapazität wird im Normalbetrieb weniger genutzt.

Pattern: Dual-Hub (zwei VPN-Endpunkte) kombiniert mit Dual ISP

• Prinzip: Standort baut zwei Tunnels zu zwei Hubs (z. B. DC1/DC2 oder Region A/B), jeweils bevorzugt über ISP A, mit Fallback über ISP B.
• Vorteil: Schützt gegen Provider- und Hub-Ausfälle, Wartung ohne Downtime möglich.
• Risiko: Ohne klare Preferenzen drohen asymmetrische Pfade und „Tunnel-Suppe“.

Pattern: Active/Active Dual ISP (nur mit State-Konzept)

• Prinzip: Beide Uplinks werden parallel genutzt (ECMP/Load Sharing).
• Vorteil: Kapazitätsausnutzung, bessere Performance bei großen Standorten.
• Risiko: Asymmetrie und stateful Breaks; erfordert Session-Pinning, klare Symmetrie-Regeln oder State Sync.

Failure Detection: IP SLA statt „Link down“

Dual ISP ohne Flapping erfordert präzise Failure Detection. Interface-Down ist ein klarer Fall, aber die häufigsten Providerprobleme sind Partial Outages: Paketverlust, DNS-Probleme, BGP-Instabilität im Provider, Path-Blackholing. Aktive Checks (IP SLA oder herstelleräquivalent) sind deshalb Pflicht.

Welche Checks in Dual-ISP-Szenarien sinnvoll sind

• Underlay-Check pro ISP: ICMP/TCP zu Provider-Gateway oder stabilen Internet-Zielen, um echte Leitungsausfälle zu erkennen.
• Overlay-Check: TCP/HTTP/DNS zu internen Zielen über den Tunnel, um „Tunnel up, Service down“ zu erkennen.
• Mehrere Targets: Ein einzelnes Ziel kann selbst down sein; mehrere Targets reduzieren false positives.

Degradation erkennen: Nicht nur up/down

Flapping entsteht oft, weil ein Pfad zwischen „gut“ und „schlecht“ schwankt. Statt sofort umzuschalten, ist ein Degradation-Modell sinnvoll:

• Green: Loss und RTT im Normalbereich → Pfad aktiv.
• Yellow: Erhöhte RTT oder Loss → Preferenz senken, aber nicht hart failovern (je nach Serviceklasse).
• Red: Targets nicht erreichbar → Failover auslösen.

BFD: Schnell, aber empfindlich – nur mit Guardrails

BFD wird häufig genutzt, um Routing-Nachbarschaften schneller als mit klassischen Timern als „down“ zu erkennen. Über Internet-Underlays kann BFD jedoch zu empfindlich sein. Der Profi-Ansatz: BFD dort einsetzen, wo Underlay stabil genug ist, und die Parameter so wählen, dass kurze Jitter-Spitzen nicht sofort Flaps auslösen.

• Geeignet: Private Leitungen, kontrollierte Providerpfade, Cloud-Backbones.
• Vorsicht: Mobilfunk/CGNAT/„noisy“ Links; hier ist Stabilität wichtiger als Millisekunden-Failover.
• Kombination: BFD als schneller Indikator, aber Failover nur, wenn SLA/Service-Checks ebenfalls rot sind.

DPD/Keepalives und NAT-T: Dual ISP ist oft auch Dual NAT

Viele Dual-ISP-Setups bringen unterschiedliche NAT-Realitäten mit sich: ISP A liefert öffentliche IP, ISP B hängt hinter NAT; oder beide nutzen CGNAT. Das beeinflusst VPN-Stabilität massiv, insbesondere bei UDP/4500 (NAT-T) und bei Idle-Timeouts. NAT-T-Mechanik ist in RFC 3948 beschrieben.

• Keepalive-Strategie: UDP-Mappings dürfen nicht auslaufen; sonst wirkt der Tunnel nach Idle „tot“.
• DPD nicht aggressiv: DPD muss Rekey- und Jitter-Delays tolerieren, sonst wird jede Degradation zum Tunnel-Reset.
• Failover zwischen NAT-Realitäten: Umschaltung ISP A ↔ ISP B kann neue externe Ports/Mappings erzeugen; das muss das Design einkalkulieren.

Routing-Strategien: Stabiler Pfadwechsel ohne Asymmetrie

Dual ISP bedeutet oft mehrere Default Routes, mehrere Tunnels und mehrere mögliche Rückwege. Die zentrale Frage lautet: Wie stellen Sie sicher, dass Hin- und Rückweg konsistent sind, insbesondere bei stateful Firewalls/NAT?

Primary/Secondary über BGP-Preferenzen

In größeren Designs ist BGP über IPSec häufig die stabilste Methode, weil Sie Präferenzen, Withdraw und Policies sauber abbilden können. Grundlagen zu BGP liefert RFC 4271.

• Local Preference: Primärpfad höher, Sekundärpfad niedriger.
• Health-gated Advertisements: Präfixe nur announcen, wenn der Pfad wirklich gesund ist.
• Symmetrie: Preferenzen müssen in beide Richtungen konsistent sein, sonst entsteht asymmetrisches Routing.

Statische Routen mit Tracking (kleine Umgebungen)

• Pattern: Default Route über ISP A, Backup über ISP B, beide an SLA-Tracking gekoppelt.
• Risiko: Rückwege und transitive Pfade können trotzdem asymmetrisch werden, wenn die Gegenseite anders entscheidet.
• Guardrail: Klare Return-Path-Strategie und Tests in beide Richtungen.

ECMP über beide ISPs: Nur mit State-Konzept

• Problem: ECMP kann Hin-/Rückwege verteilen, NAT/Firewall-States brechen.
• Lösung: Flow-Pinning, Symmetrieregeln, oder state sync – je nach Plattform und Risikoappetit.

Hysterese und Failback: Der Schlüssel gegen Tunnel-Flapping

Viele Umgebungen sind im Failover gut, aber im Failback schlecht. Sobald der primäre ISP kurz wieder besser ist, wird zurückgeschaltet – und kurz danach wieder weg. Das erzeugt Ping-Pong und zerstört Sessions. Eine saubere Failback-Logik braucht:

• Hold-down Timer: Nach Failover bleibt der neue Pfad für eine Mindestzeit aktiv.
• Stabilitätsfenster: Primärpfad muss über X Minuten SLA-green sein, bevor zurückgeschaltet wird.
• Graceful Return: Preferenzen schrittweise erhöhen, nicht sofort „hart“ zurückschalten.

MTU/MSS und PMTUD: Dual ISP kann zwei verschiedene MTUs bedeuten

Dual ISP kann bedeuten: ISP A hat eine effektive MTU von 1500, ISP B nur 1492 (PPPoE) oder weniger durch zusätzliche Provider-Encapsulation. Wenn Sie beim Failover plötzlich einen Pfad mit kleinerer MTU nutzen, entstehen PMTUD-Blackholes und „nur manche Apps gehen nicht“. PMTUD-Hintergründe finden Sie in RFC 1191 (IPv4) und RFC 8201 (IPv6).

• Konservative Tunnel-MTU: Standardisieren Sie MTU so, dass beide ISPs funktionieren.
• MSS-Clamping: Besonders wichtig, um TCP-Segmente failover-resistent zu machen.
• ICMP nicht blind blocken: PMTUD braucht Feedback, sonst entstehen Blackholes.

Observability: Woran Sie Flapping früh erkennen

Ohne Telemetrie ist Dual-ISP-Failover eine Black Box. Für stabile Resilienz brauchen Sie Metriken, die Underlay- und Overlay-Ereignisse korrelieren.

• SLA-Metriken pro ISP: RTT, Loss, Jitter, Success Rate, Target-Erreichbarkeit.
• VPN-Metriken: Tunnel up/down, DPD-Timeouts, Rekey-Failures, NAT-T-Indikatoren, CPU-Spikes.
• Routing-Metriken: BGP/OSPF Flaps, Prefix-Counts, Withdraw/Announce Events, Convergence Time.
• Session-Metriken: Reconnect-Raten, gleichzeitige Sessions, Abbrüche nach Failover.

Häufige Fehler und Anti-Patterns

• Failover nur auf Interface-Down: Partial Outages bleiben unentdeckt, Blackholing tritt auf.
• Zu aggressive DPD/BFD: Mikro-Jitter triggert Tunnel-Resets und Flapping.
• Failback ohne Stabilitätsfenster: Ping-Pong zwischen ISPs, massiver Sessionverlust.
• ECMP ohne State-Konzept: Asymmetrische Rückwege brechen NAT/Firewall-States.
• Keine MTU-Strategie: Failover erzeugt PMTUD-Blackholes und „nur manche Apps“.
• Keine Governance: Tracking-Regeln sind pro Standort anders; Drift macht das Verhalten unberechenbar.

Checkliste: Dual Uplinks ohne Tunnel-Flapping

• Topologie wählen: Für die meisten Standorte Primary/Secondary; Active/Active nur mit State-Konzept.
• SLA/Service-Checks definieren: Underlay-Targets und Overlay-Targets (DNS/TCP/HTTP), mehrere Ziele pro ISP.
• Degradation-Model einführen: Green/Yellow/Red statt rein up/down, um Flapping zu vermeiden.
• DPD/Keepalive robust: NAT-T und Idle-Timeouts berücksichtigen; nicht aggressiv konfigurieren.
• Routing konsistent: Preferenzen spiegeln, Prefix-Filter setzen, Health-gated Advertisements nutzen.
• Hysterese für Failback: Hold-down und Stabilitätsfenster, damit Rückschaltung nicht ping-pongt.
• MTU/MSS standardisieren: Konservative MTU, MSS-Clamping, PMTUD-fähige ICMP-Policy.
• Tests unter Last: Planned/unplanned Failover, Partial Failures, Rekey-Spitzen, Voice/Video.
• Observability verpflichtend: SLA-, VPN-, Routing- und Session-Metriken korrelieren und alarmieren.

Cisco Netzwerkdesign, CCNA Support & Packet Tracer Projekte

Cisco Networking • CCNA • Packet Tracer • Network Configuration

Ich biete professionelle Unterstützung im Bereich Cisco Computer Networking, einschließlich CCNA-relevanter Konfigurationen, Netzwerkdesign und komplexer Packet-Tracer-Projekte. Die Lösungen werden praxisnah, strukturiert und nach aktuellen Netzwerkstandards umgesetzt.

Diese Dienstleistung eignet sich für Unternehmen, IT-Teams, Studierende sowie angehende CCNA-Kandidaten, die fundierte Netzwerkstrukturen planen oder bestehende Infrastrukturen optimieren möchten. Finden Sie mich auf Fiverr.

Leistungsumfang:

• Netzwerkdesign & Topologie-Planung

• Router- & Switch-Konfiguration (Cisco IOS)

• VLAN, Inter-VLAN Routing

• OSPF, RIP, EIGRP (Grundlagen & Implementierung)

• NAT, ACL, DHCP, DNS-Konfiguration

• Troubleshooting & Netzwerkoptimierung

• Packet Tracer Projektentwicklung & Dokumentation

• CCNA Lern- & Praxisunterstützung

Lieferumfang:

• Konfigurationsdateien

• Packet-Tracer-Dateien (.pkt)

• Netzwerkdokumentation

• Schritt-für-Schritt-Erklärungen (auf Wunsch)

Arbeitsweise:Strukturiert • Praxisorientiert • Zuverlässig • Technisch fundiert

CTA:
Benötigen Sie professionelle Unterstützung im Cisco Networking oder für ein CCNA-Projekt?
Kontaktieren Sie mich gerne für eine Projektanfrage oder ein unverbindliches Gespräch. Finden Sie mich auf Fiverr.