Cisco Router High Availability (HA): Redundanzdesign für minimale Downtime

High Availability (HA) bei Cisco-Routern bedeutet: Ausfälle einzelner Komponenten (Router, Link, Provider, Strom, Interface) führen nicht zum Standortstillstand oder zu langen Unterbrechungen. „Redundanz“ ist dabei nur dann wirksam, wenn Failover-Kriterien, Konvergenzzeiten und Tests klar definiert sind. In der Praxis entscheidet das Design über die Downtime: Link-Down ist leicht, Path-Down (Link up, Internet down) ist der häufigere und tückischere Fall. Dieser Leitfaden zeigt ein praxistaugliches HA-Design für minimale Downtime – inklusive FHRP (HSRP/VRRP/GLBP), Dual-WAN-Failover, Tracking/IP SLA und Verifikation per CLI.

HA-Grundprinzip: Redundanz muss End-to-End wirken

HA ist nur dann erfolgreich, wenn sie den gesamten Pfad abdeckt: Gateway, WAN, Routing und (falls vorhanden) VPN. Redundanz nur an einer Stelle verschiebt das Problem, löst es aber nicht.

  • Gateway-Redundanz: Default-Gateway bleibt erreichbar (FHRP)
  • WAN-Redundanz: mehrere Uplinks/Provider, Path-Down-Erkennung
  • Routing-Redundanz: kontrollierte Default-Strategie und Konvergenz
  • VPN-Redundanz: Tunnel/Peers redundant (wenn Standortkritikalität hoch)

Komponenten- und Ausfallmodelle: Was Sie wirklich absichern müssen

Definieren Sie vor dem Design, welche Ausfälle abgedeckt werden müssen. Das ist die Basis für Budget, Scope und Acceptance Tests.

  • Router-Hardware: Gerät fällt aus
  • Strom: Netzteil/USV/PDUs, getrennte Stromkreise
  • Link: physischer WAN-Link down
  • Path: Upstream/Providerstörung bei Link up
  • LAN-Uplink: Trunk/Uplink zum Core/Switch down
  • Routing/VPN: Neighbor-/SA-Flaps, Rekey-Probleme

HA-Designoption 1: FHRP für Gateway-Redundanz (HSRP/VRRP/GLBP)

FHRP stellt ein virtuelles Default-Gateway bereit, das bei Routerausfall schnell übernimmt. HSRP ist in Cisco-Umgebungen häufig, VRRP ist herstellerneutral, GLBP kann zusätzlich Loadsharing liefern.

  • HSRP: Cisco-typisch, stabiler Standard im Enterprise
  • VRRP: interoperabel, wenn Multivendor
  • GLBP: Gateway-Loadsharing möglich, aber mehr Komplexität

HSRP-Beispiel (Gateway im VLAN)

interface Vlan20
 description USERS
 ip address 10.1.20.2 255.255.255.0
 standby 20 ip 10.1.20.1
 standby 20 priority 110
 standby 20 preempt
 standby 20 authentication md5 key-string <KEY>

HSRP-Verifikation

show standby brief
show standby vlan 20

FHRP-Designregeln: Preempt, Prioritäten und Failover-Trigger

Ein häufiger Fehler ist „Preempt überall an“ ohne Tracking. Dadurch kann ein Router trotz schlechter WAN-Qualität wieder Active werden und Instabilität erzeugen. Nutzen Sie Tracking, um Prioritäten dynamisch zu senken.

  • Preempt: sinnvoll, aber nur mit sauberem Tracking und Delay
  • Prioritäten: Active bevorzugt auf dem Router mit besserem Pfad
  • Tracking: WAN- oder Path-Events senken Priorität (verhindert falsche Active-Rolle)

HA-Designoption 2: Dual-WAN (Active/Standby oder Active/Active)

Dual-WAN ist der größte Downtime-Reduzierer, weil Providerstörungen häufiger sind als Routerausfälle. Entscheidend ist, ob Sie Active/Standby (einfach, robust) oder Active/Active (mehr Performance, mehr Komplexität) wählen.

  • Active/Standby: Standard in vielen Unternehmen, klarer Failover
  • Active/Active: Lastverteilung, benötigt Policy- und Symmetrie-Design
  • Wichtig: Link-Down und Path-Down getrennt behandeln

Path-Down-Erkennung: IP SLA + Tracking als Pflichtbaustein

Link-Down wird automatisch erkannt, Path-Down nicht. IP SLA prüft Reachability zu definierten Targets, Tracking steuert Default-Routen, FHRP-Prioritäten oder Policy-Routen.

IP SLA + Track (Beispiel)

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

Default-Routen mit Tracking (Primary/Backup)

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 IP SLA/Tracking

show ip sla statistics
show track
show ip route 0.0.0.0

HA-Designoption 3: VPN-Redundanz (wenn Standortkritikalität hoch ist)

Wenn zentrale Ressourcen nur über VPN erreichbar sind, ist VPN ein HA-Bestandteil. Redundanz entsteht durch duale Peers (Dual-Hub), klare Rekey/DPD-Parameter und Traffic-basierte Validierung.

  • Dual-Hub: zwei Headends, Branch baut redundante Tunnel
  • Failover-Kriterien: SA down oder Traffic-Fail (nicht nur „up“)
  • Abnahme: SA-Status + Paketzähler + Applikationstest

VPN-Checks (Pflicht)

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

Minimale Downtime: Konvergenzzeit und Timer-Strategie

„Minimale Downtime“ ist eine Zeitmessung. Definieren Sie Zielwerte und prüfen Sie, welche Mechanismen (FHRP, Tracking, Routing) die Umschaltung bestimmen. Zu aggressive Timer erhöhen Flap-Risiko.

  • Ziel: Umschaltzeit in Sekunden bis wenige Dutzend Sekunden (realistisch)
  • Tracking-Frequenz: höher = schneller, aber mehr Sensitivität
  • Failback: kontrolliert, ggf. verzögert, um Flapping zu vermeiden

Messlogik: Ausfallzeit berechnen

Ausfallzeit = Detektion + Konvergenz + Applikations-Retry

HA-Acceptance Tests: Was zwingend getestet werden muss

HA ist nur abgenommen, wenn Failover-Szenarien getestet wurden. Testen Sie Link-Down und Path-Down getrennt und messen Sie die Umschaltzeit. Dokumentieren Sie Evidence (CLI/Logs).

  • Test 1: Router Active fällt aus (FHRP übernimmt)
  • Test 2: WAN Primary Link-Down (Default wechselt, Internet ok)
  • Test 3: WAN Primary Path-Down (IP SLA triggert Wechsel)
  • Test 4: Failback (Rückübernahme ohne Flapping)
  • Optional: VPN-Failover (Dual-Hub) inkl. Traffic-Nachweis

HA-Evidence-Set (Copy/Paste)

show standby brief
show ip sla statistics
show track
show ip route 0.0.0.0
show logging | include LINEPROTO|LINK-|IPSLAs|HSRP|VRRP
ping 1.1.1.1 repeat 20
traceroute 1.1.1.1

Operability: Monitoring und Alarmierung für HA

HA ohne Monitoring führt zu „schleichenden“ Ausfällen (ein Link tot, niemand merkt es). Definieren Sie Alarme für Link/Path, FHRP-Rollenwechsel und VPN/Routing-Flaps.

  • Alarme: Link down, Path down (IP SLA), Default-Route fehlt
  • FHRP: Role Change/State Change (Active/Standby Wechsel)
  • Routing: Neighbor down/flaps
  • VPN: SA down/flaps, Rekey/DPD Errors

CLI: Operability-Snapshot

show interfaces counters errors
show ip route 0.0.0.0
show standby brief
show ip sla statistics
show track
show logging | last 100

Typische HA-Fehlerbilder (und wie Sie sie vermeiden)

Viele HA-Probleme entstehen durch fehlendes Tracking, falsche Prioritäten oder ungetestete Failback-Szenarien. Nutzen Sie diese Liste als Review-Check.

  • Preempt ohne Tracking: falscher Router wird Active trotz schlechtem WAN
  • Nur Link-Down getestet: Path-Down bleibt unentdeckt
  • Failback ohne Delay: Flapping nach Providerinstabilität
  • VPN nur „SA up“ geprüft: Traffic-Problem bleibt verborgen
  • Keine Alarme: Backup-Link tot, aber niemand merkt es

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.

Related Articles