VPN Failover ohne Flaps: Tracking, SLA, Routing und Session-Stabilität

VPN-Failover ist in der Praxis weniger ein „Tunnel hoch oder runter“-Problem, sondern ein Stabilitätsproblem: Wenn Tracking zu aggressiv ist, flappen Tunnels bei kurzen Loss-Spikes. Wenn Tracking zu träge ist, dauert der Ausfall zu lange. Und wenn Routing oder NAT-State nicht symmetrisch bleiben, brechen Sessions, obwohl der Tunnel „wieder da“ ist. Ein robustes Failover-Design verbindet deshalb vier Disziplinen: zuverlässige Path-Validation (IP SLA), sauberes Object Tracking mit Dampening, Routing-Entscheidungen mit klarer Priorität (statt ECMP-Chaos) und bewusster Umgang mit Session-Stabilität (State, Rekey, MTU). Dieser Artikel zeigt, wie du VPN Failover ohne Flaps auf Cisco Routern baust.

Warum VPNs flappen: Die häufigsten Root Causes

Flaps entstehen meist durch instabile Underlays (Internet/LTE), falsche Health Checks oder Timer, die auf transienten Packet Loss reagieren. Zusätzlich verschärfen Rekeys und PMTUD-Probleme die Situation, weil sie Mikrospikes erzeugen.

• Health Check zu „nah“ (nur Gateway ping) oder zu „zufällig“ (ein externer Host)
• Timer zu aggressiv: DPD/Keepalive/SLA ohne Delay
• Underlay Jitter/Loss: LTE, PPPoE, Congestion
• Rekey-Spikes: IKE/IPsec Rekey triggert kurze Unterbrechungen
• MTU/PMTUD: große Pakete droppen, Apps reconnecten

Designziel: Failover mit Hysterese statt „Up/Down Ping-Pong“

Ein stabiles Design nutzt Hysterese: ein Down muss eine gewisse Zeit stabil „down“ sein, bevor du schaltest, und ein Up muss stabil „up“ sein, bevor du zurückschwenkst. Das verhindert Flaps.

Hysterese (vereinfacht)

$\text{Switch}\leftarrow \text{Down > T\_down}, \text{Return}\leftarrow \text{Up > T\_up}$

• T_down: verhindert Switch bei kurzen Loss-Spikes
• T_up: verhindert „Bounce Back“ bei instabilem Recovery

Tracking richtig bauen: IP SLA + Track + Delay

IP SLA liefert die Messung, Track liefert den Zustand, Delay liefert die Hysterese. Der wichtigste Praxispunkt: SLA muss über den richtigen Uplink laufen (Source-Interface), sonst misst du das falsche.

IP SLA: realistischer Service-Check (TCP 443)

ip sla 10
 tcp-connect 1.1.1.1 443 source-interface GigabitEthernet0/0
 frequency 5
 timeout 1000
ip sla schedule 10 life forever start-time now

Track mit Delay (Flap-Schutz)

track 10 ip sla 10 reachability
 delay down 15 up 10

Mehr Robustheit: Composite Health statt Single Target

Ein einzelnes Ziel kann down sein, ohne dass dein Provider kaputt ist. Stabiler ist ein Composite: mehrere SLAs zu unterschiedlichen Zielen, und du schaltest nur, wenn mehrere gleichzeitig fehlschlagen. Dafür nutzt du Track Lists.

Zwei SLAs, OR-Logik (mindestens einer up)

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

delay down 15 up 10
track 101 list boolean or

object 10

object 11

Routing ohne Flaps: Priorität statt ECMP

ECMP über zwei Underlays ist für VPN-Failover häufig eine Flap-Quelle, weil einzelne Flows unterschiedlich geroutet werden und State (NAT/IPsec) asymmetrisch wird. Für stabile Failover-Edges ist „active/standby“ oft besser: ein primärer Pfad, ein sekundärer Pfad mit höherer Administrative Distance.

• Active/Standby: deterministisch, weniger Asymmetry
• ECMP: kann funktionieren, aber erfordert Flow-Pinning und State-Design
• Static + Tracking: einfach und robust

Floating Static Route mit Track

ip route 0.0.0.0 0.0.0.0 203.0.113.1 track 101
ip route 0.0.0.0 0.0.0.0 198.51.100.1 200

VPN-Failover und Session-Stabilität: Was du realistisch erwarten kannst

Viele Teams erwarten „nahtloses“ Failover. In klassischem IPsec ist das oft nicht realistisch, weil SAs, NAT-States und Pfadsymmetrie wechseln. Ziel ist daher: kontrolliertes Failover mit möglichst wenigen Resets, nicht „magisch ohne Unterbrechung“.

• Bestehende TCP Sessions brechen häufig bei Pfadwechsel
• UDP/VoIP erholt sich schneller, wirkt aber jittery
• Stateful NAT/Firewall ohne State-Sync: Failover = Session Reset

VTI + Routing: Der sauberste Failover-Mechanismus für Site-to-Site

Route-based VPNs (VTI) sind im Failover oft stabiler als Crypto Maps, weil Routing über ein Interface entscheidet und du Health/Withdraw sauber koppeln kannst. In Kombination mit BGP withdrawt du Prefixes bei Tunnel-Failure – das reduziert „stale routes“.

• Tunnel down → BGP down → Routes weg
• Keine statischen „toten“ Routes
• Policy (LocalPref) steuert Primär/Backup

BGP über VTI (Failover Pattern)

interface Tunnel100
 tunnel protection ipsec profile IPSEC-PROF
 bfd interval 300 min_rx 300 multiplier 3
router bgp 65000

neighbor 169.254.100.2 remote-as 65100

neighbor 169.254.100.2 fall-over bfd

neighbor 169.254.100.2 maximum-prefix 500 90 restart 5

Rekey und DPD: Flap-Trigger entschärfen

Rekeys und DPD sind notwendig, können aber flappen, wenn Werte zu aggressiv sind. Besonders auf Internet-Underlays sind moderate DPD-Werte und saubere Lifetimes sinnvoll. Vermeide „alle Tunnels rekeyen gleichzeitig“ durch Standardisierung und – wenn möglich – Staggering.

• DPD nicht „zu hart“ auf Loss-Spikes
• Lifetimes nicht unnötig kurz (sonst Rekey-Frequenz hoch)
• Monitoring: Rekey-Zeiten mit Flaps korrelieren

DPD Pattern (IKEv2)

crypto ikev2 profile IKEV2-PROF
 dpd 10 3 on-demand

MTU/PMTUD: Failover wirkt „kaputt“, obwohl Tunnel up

Nach Failover ändern sich Pfade, MTU und Overheads. Wenn PMTUD/ICMP blockiert ist, entstehen Blackholes: kleine Pakete gehen, große nicht. Das sieht wie „VPN instabil“ aus, ist aber MTU. MSS Clamping auf dem Tunnel reduziert dieses Risiko massiv.

MSS Clamping (Pattern)

interface Tunnel100
 ip tcp adjust-mss 1360

Praktische Betriebsregeln: Was sich bewährt hat

Stabile VPN-Failover-Deployments folgen wenigen Regeln: Health Checks müssen realistisch sein, Failover muss gedämpft sein, und Routing muss deterministisch bleiben.

• Mindestens 2 SLA Targets pro Uplink (Composite Health)
• Delay down/up standardisieren (z. B. 10–20s down, 5–15s up)
• Active/Standby statt ECMP für NAT/IPsec Edge
• VTI + BGP bevorzugen, wenn Skalierung/Flexibilität wichtig ist
• MSS Clamping als Standard bei Internet-Underlays

Troubleshooting: Wenn Failover „flapt“ oder Sessions sterben

Bei Failover-Problemen prüfst du zuerst, ob SLA/Track flappen, dann ob Routing tatsächlich umschaltet, und erst dann IPsec-States. So vermeidest du, dass du im Crypto debugst, obwohl der Trigger im Underlay liegt.

Checkliste

show ip sla summary
show ip sla statistics
show track brief
show ip route 0.0.0.0
show crypto ikev2 sa
show crypto ipsec sa
show interfaces | include drops|error

Quick-Runbook: VPN Failover ohne Flaps (Copy & Paste)

Dieses Muster kombiniert SLA, Track-Delay, Composite Health und Floating Default Route. Passe Interfaces, Ziele und Gateways an.

ip sla 10
 tcp-connect 1.1.1.1 443 source-interface GigabitEthernet0/0
 frequency 5
 timeout 1000
ip sla schedule 10 life forever start-time now
ip sla 11

icmp-echo 8.8.8.8 source-interface GigabitEthernet0/0

frequency 5

timeout 1000

ip sla schedule 11 life forever start-time now
track 10 ip sla 10 reachability

delay down 15 up 10

track 11 ip sla 11 reachability

delay down 15 up 10
track 101 list boolean or

object 10

object 11
ip route 0.0.0.0 0.0.0.0 203.0.113.1 track 101

ip route 0.0.0.0 0.0.0.0 198.51.100.1 200

Konfiguration speichern

Router# copy running-config startup-config

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.