HA für Core-Router: VRRP, HSRP und GLBP sicher konfigurieren

Wenn das Default Gateway instabil wird, spürt das ganze Subnetz es sofort: Sessions reißen, ARP‑Einträge springen und Troubleshooting wird zur Daueraufgabe. Für HA für Core‑Router sind VRRP (Virtual Router Redundancy Protocol), HSRP (Hot Standby Router Protocol) und GLBP (Gateway Load Balancing Protocol) die üblichen Werkzeuge. Dieser Beitrag erklärt praxisnah, wie Sie diese Protokolle designen, konfigurieren und betreiben, damit Split‑Brain‑Szenarien vermieden werden – also Situationen, in denen mehrere Router gleichzeitig glauben, aktiv zu sein.

HA für Core-Router: Rolle von VRRP, HSRP und GLBP

VRRP, HSRP und GLBP stellen ein virtuelles Default Gateway (VIP) bereit. Ein Router antwortet für diese Adresse und leitet Traffic weiter, ein anderer steht standby. Wichtiger Hinweis: FHRP (First Hop Redundancy Protocol) sorgt nur für den ersten Hop; Routing‑Redundanz im Backbone, stabile L2‑Pfade und saubere Control‑Plane‑Policies sind notwendige Voraussetzungen.

Wann welches Protokoll?

• VRRP ist standardisiert (RFC) und in Multi‑Vendor‑Umgebungen oft erste Wahl.
• HSRP ist proprietär bei Cisco, bietet enge Integration zu Cisco‑Tracking/Monitoring.
• GLBP verteilt Gateway‑Last durch mehrere virtuelle MACs, erhöht dabei aber Komplexität (ARP‑Verhalten, Security‑Integration).

Worum es bei Split‑Brain wirklich geht und wie es sich zeigt

Split‑Brain in FHRP ist meist keine reine Protokoll‑Anomalie, sondern das Ergebnis fehlgeleiteter Signalisierung, L2‑Partitionen oder ungeeigneter Timings. Symptome im Betrieb:

• ARP/MAC‑Flapping: virtuelle MACs springen zwischen Ports.
• Asymmetrisches Routing: Pakete gehen raus, kommen aber über einen anderen Pfad zurück.
• Intermittierender Paketverlust oder lange Verbindungsaufbauszeiten nach Failover.

Typische Ursachen

• Kontrollpakete werden durch ACLs, Storm‑Control oder Multicast‑Limits blockiert.
• L2‑Partitionen oder inkonsistente Trunk/VLAN‑Konfigurationen.
• Preemption ohne Verzögerung während Routing‑Konvergenz.
• Tracking, das nur Link‑Up/Down prüft, aber kein echtes Forwarding erkennt (Blackholing).

Topologie‑Voraussetzungen: Basis für stabiles Failover

Bevor Sie Timers und Prioritäten feinjustieren, sichern Sie das Fundament:

• FHRP‑Teilnehmer müssen im selben VLAN/Subnetz (SVI/L3‑Interface) liegen.
• Konsistente Trunks/Port‑Channels und VLAN‑Allowed‑Lists zwischen Core und Access.
• STP‑Root‑Plan: Root Bridges und Edge‑Ports bewusst setzen (PortFast/Edge für Endgeräte).
• Separate Management/Keepalive‑Pfad als sekundärer Liveness‑Channel, wenn möglich.

Konfigurationsprinzipien: Priorität, Preemption, Timer, Tracking

Stabilität entsteht durch klare Regeln. Drei Kernelemente:

1. Eindeutige Prioritäten

Vermeiden Sie Gleichstand. Pro VLAN einen bevorzugten Master definieren und den Backup deutlich niedriger priorisieren. Das reduziert Rennsituationen.

2. Preemption mit Verzögerung

Preemption (der bessere Router übernimmt nach Wiederkehr) ist nützlich, aber nur mit Delay. Sonst drohen Flaps beim Neustart, solange Routing/Port‑Channels nicht konvergiert sind. Ein Preempt‑Delay gibt dem System Zeit, IGP‑Adjazenzen, BGP und LACP zu stabilisieren.

3. Tracking auf echte Erreichbarkeit

Interface‑Tracking ist Basis; erweitern Sie mit Route‑Tracking (Default‑Route/IGP‑Neighbor) und IP SLA (aktive Messung) gegen einen stabilen Next‑Hop. Wichtig: Tracking‑Ziele dürfen nicht selbst vom zu überprüfenden FHRP abhängen – sonst entsteht eine Rückkopplung und möglicher Split‑Brain‑Trigger.

Praxis‑Konfigurationsbeispiele (orientierend)

Die Befehle sind vendor‑abhängig; hier strukturierte Beispiele in Cisco‑Syntax, die zeigen, wie Preempt Delay, Priority und Tracking kombiniert werden.

VRRP – Preempt‑Delay und Tracking (Beispiel)

interface Vlan10
 ip address 10.10.10.2 255.255.255.0
 vrrp 10 ip 10.10.10.1
 vrrp 10 priority 120
 vrrp 10 preempt delay minimum 60
 vrrp 10 track interface Port-Channel1 decrement 40
 vrrp 10 track route 0.0.0.0/0 decrement 30

HSRP – Active/Standby mit IP SLA‑Tracking (Beispiel)

ip sla 10
 icmp-echo 8.8.8.8 source-ip 10.10.10.2
 frequency 10
ip sla schedule 10 life forever start-time now
track 10 ip sla 10 reachability

interface Vlan10
 ip address 10.10.10.3 255.255.255.0
 standby 10 ip 10.10.10.1
 standby 10 priority 110
 standby 10 preempt delay minimum 60
 standby 10 track 10 decrement 30

GLBP – nur bei Bedarf an Gateways‑Load

interface Vlan10
 ip address 10.10.10.4 255.255.255.0
 glbp 10 ip 10.10.10.1
 glbp 10 priority 120
 glbp 10 preempt delay minimum 60
 glbp 10 load-balancing round-robin
 glbp 10 track Port-Channel1 decrement 30

IP SLA, BFD und Failover‑Beschleunigung

FHRP‑Timer allein sind oft nicht der richtige Hebel für schnelle, sichere Failover. Zwei ergänzende Mechanismen sind in der Praxis sehr wirkungsvoll:

IP SLA (aktive Erreichbarkeitsprüfung)

IP SLA führt aktive Messungen (ICMP/TCP/UDP) gegen einen stabilen Zielhost durch. Verwenden Sie IP SLA als Track‑Objekt für FHRP, so entscheidet nicht ein Link‑Down, sondern echte Upstream‑Erreichbarkeit. Achten Sie auf Zielauswahl: Nutzen Sie einen Next‑Hop im Carrier‑Netz oder Cloud‑Peer, der nicht über das zu testende Gateway hindurchreicht.

BFD (Bidirectional Forwarding Detection)

BFD ist ein sehr schneller Liveness‑Mechanismus, der zwischen Routing‑Peers oder über Tunnel läuft. BFD erkennt Forwarding‑Ausfälle in Millisekunden und kann IGP‑Adjazenzen schneller auflösen; als Folge sollte FHRP‑Tracking Route/IGP‑State einbeziehen, statt nur Interface‑Status.

! Beispiel für einfache BFD Template und Interface‑Aktivierung
bfd-template single-hop BFD_FAST
 interval 50 min_rx 50 multiplier 3
!
interface GigabitEthernet0/0
 ip address 192.0.2.2 255.255.255.252
 bfd interval 50 min_rx 50 multiplier 3

FHRP über VPNs, MPLS oder entfernte Standorte

FHRP über WAN/Provider‑Netze ist ein häufiger Fehlerursprung. FHRP ist für LAN‑Segment‑Redundanz gedacht; über L3‑Netze entstehen leicht Split‑Brain‑Situationen, da Control‑Plane‑Pakete und Datenpfade auseinanderfallen können.

Best Practices für Multi‑Site

• FHRP nur lokal anwenden; für Site‑Redundanz Routing (BGP/OSPF) und Anycast verwenden.
• Wenn FHRP über ein Shared‑L2 gebaut wird (z. B. L2‑MPLS), stellen Sie sicher, dass Control‑Pakete den gleichen Pfad wie Client‑Traffic nutzen.
• Bei IPsec/GRE‑Tunneln: vermeiden Sie, dass IP‑SLA‑Targets oder Tracking‑Ziele selbst über das getrackte Gateway laufen.

Diagnose‑Praxis: Prüfreihenfolge bei Ausfällen

Eine feste Prüfkette vermeidet Zeitverlust. Ziel: zuerst klären, ob FHRP Ursache oder Symptom ist. Ergänzend zu den Grundprüfungen in der Basisversion hier erweiterte Prüfungen und Packet‑Capture‑Beispiele.

Schritt 1 – FHRP‑Status prüfen

show vrrp brief
show standby brief
show glbp brief
show logging | include VRRP|HSRP|GLBP|STATE|TRACK

Schritt 2 – MAC/ARP‑Sicht

show mac address-table vlan 10 | include 0000.5e00
show mac address-table move update
show ip arp | include 10.10.10.1

Schritt 3 – Kontrolltraffic und ACLs prüfen

show interface Vlan10 counters
show ip igmp snooping groups vlan 10
show access-lists | include 112|HSRP|GLBP

Stellen Sie sicher, dass FHRP‑Kontrollpakete nicht durch ACLs, QoS oder Storm‑Control verworfen werden. Für VRRP wird das IP‑Protokoll 112 verwendet; tcpdump kann helfen, Control‑Pakete zu sehen.

# Beispiel: VRRP‑Pakete mit tcpdump auffangen
tcpdump -nni eth0 'ip[9] == 112' -vv

Schritt 4 – Routing/Forwarding prüfen

show ip route 0.0.0.0/0
show ip ospf neighbor
show bgp summary
ping <upstream-next-hop> source <SVI-IP>

Ein Master kann Up‑State melden, aber upstream Blackholing haben – das zeigt, dass Tracking unzureichend ist.

Schritt 5 – Client‑Perspektive

Auf Clients ARP‑Entry, Traceroute (erster Hop) und Session‑Erhalt prüfen. Firewalls und uRPF können Verbindungen bei asymmetrischem Routing abbrechen.

Testfälle für kontrollierte Changes

Führen Sie Failover‑Tests in kontrollierten Schritten durch und dokumentieren Sie Verhalten und Metriken. Empfohlene Testfälle:

1. Simulierter Uplink‑Ausfall am Master (Link‑Down am Uplink).
2. Interface‑Shutdown am Master (prüft Tracking‑Response).
3. Preemption‑Reinsertion: Master rebooten und beobachten, ob Preempt‑Delay Flapping verhindert.
4. IP SLA Target unreachable: prüfen, ob Track‑Objekt das FHRP triggert.
5. MAC‑Flap‑Stresstest: mehrmaliges Up/Down an Access‑Ports und Beobachtung der Flap‑Rate.
6. VPN‑Failover: Carrier‑Einsatz mit BGP‑Failover und Prüfung auf asymmetrische Pfade.

Operational Runbook – Kurzcheckliste

• Ist das FHRP‑VLAN konsistent auf allen beteiligten Switches?
• Wer ist der geplante Master pro VLAN (Priority Dokumentation)?
• Sind IP SLA Targets unabhängig und erreichbar?
• Sind Control‑Plane‑Pakete (z. B. VRRP) in ACLs erlaubt?
• Gibt es Alerts für MAC‑Flaps, FHRP‑State‑Changes und IP SLA‑Verluste?

Spezielle Security‑Aspekte

Sicherheitstools wie Dynamic ARP Inspection (DAI), IP Source Guard oder RA Guard können Failover stören, wenn Trust‑Ports nicht sauber gesetzt sind. Vergewissern Sie sich, dass Access‑Switches die GARP/NA/Gratuitous‑ARP der Gateways zulassen und dass ACLs Kontrolltraffic nicht filtern.

Fazit und Empfehlungen

HA für Core‑Router ist weniger reine Konfiguration als Systemdesign: klare L2‑Pfade, priorisierte Master‑Regeln, Preemption mit Verzögerung, Tracking auf echte Erreichbarkeit und aussagekräftiges Monitoring verhindern die meisten Split‑Brain‑Fälle. Testen Sie kontrollierte Failover‑Szenarien, dokumentieren Sie Abhängigkeiten (VLAN, Trunk, Tracking‑Targets) und halten Sie einfache Rückfalloptionen bereit. In Multi‑Site‑ oder VPN‑Szenarien bevorzugen Sie lokale FHRP‑Instanzen und setzen auf Routing/Anycast für Standort‑Redundanz. So wird Gateway‑Redundanz im Betrieb belastbar und vorhersagbar.

Weiterführende Prüfungen und Anmerkungen

Wenn Sie auf persistente Probleme stoßen, ist eine sequenzielle Isolierung empfehlenswert: zunächst L2 vollständig validieren, dann FHRP‑Control, anschließend Routing und zuletzt Applikations‑Layer‑Symptome. Eine strukturierte Dokumentation aller Failover‑Tests und der akzeptierten Baselines minimiert „War‑Room“‑Einsätze und beschleunigt Incident‑Resolution.

Betrieb, Monitoring und Notfallmaßnahmen für HA für Core‑Router

Zusätzlich zur Konfiguration ist der tägliche Betrieb entscheidend: Beobachtung, Datensicherung, Change‑Kontrolle und klar definierte Notfallmaßnahmen reduzieren Ausfallzeiten deutlich. Dieser Abschnitt liefert praxisnahe Hinweise, welche Metriken Sie erfassen sollten, wie Sie schnelle Gegenmaßnahmen einleiten und wie Automatisierung die Zuverlässigkeit erhöht.

Welche Kennzahlen wirklich zählen

• FHRP‑State‑Changes pro Minute: plötzliche Zunahmen deuten auf Flapping oder Preempt‑Probleme hin.
• MAC‑Table‑Flaps und Anzahl unterschiedlicher Ports pro virtueller MAC: Frühindikator für L2‑Partitionen.
• IP SLA‑Erreichbarkeitsverluste und BFD‑Session‑Resets: zeigen echte Forwarding‑Ausfälle.
• Control‑Plane‑Drops (ACL/QoS/CP‑Policing): wenn Router CPU‑lastig ist, gehen Signalisierungspakete verloren.

Monitoring‑ und Alert‑Regeln (empfohlen)

• Alarm, wenn FHRP‑State‑Changes > 3 in 5 Minuten.
• Warnung bei MAC‑Flap‑Rate > X pro Minute (wert abhängig von Umgebung).
• Kritisch bei IP SLA‑Loss > 5% über 1 Minute oder BFD‑Down.

Schnelle Notfallmaßnahmen (Runbook‑Auszug)

1. Isolieren: betroffene VLAN‑Trunks zuordnen und ggf. Ports temporär in „errdisable“ setzen, um Flapping zu stoppen.
2. Stabilisieren: Preemption temporär deaktivieren oder Preempt‑Delay erhöhen, bis Upstream‑Adjazenzen stehen.
3. ARP‑Refresh: auf Edge‑Switches gratuitous ARP erlauben und Clients bei Bedarf ARP‑Cache leeren.
4. Fallback: Master‑Priorität manuell setzen (mit dokumentierter Rücksetzung) falls automatisches Failover nicht zuverlässig arbeitet.

Beispiele für schnelle Operator‑Befehle:

# Konfigurationssicherung vom Router (via SCP/SSH)
scp admin@10.0.0.1:/running-config ./backup/10.0.0.1.cfg

# Syslog filtern nach FHRP‑Events
ssh syslogserver 'grep -E "VRRP|HSRP|GLBP|STATE|TRACK" /var/log/syslog | tail -n 200'

# Client‑ARP auf Linux leeren
sudo ip neigh flush all

Automatisierung und Änderungsmanagement

Halten Sie FHRP‑Konfigurationen in einem Git‑Repository, prüfen Sie Änderungen via CI (Linting, syntaktische Validierung von Templates) und führen Sie geplante Tests in einem Lab‑Emulator (GNS3、EVE‑NG) aus. Versionierte Backups erlauben schnelles Rollback nach fehlerhaften Changes.

Langfristige Maßnahmen

Führen Sie regelmäßige Chaos‑Tests (kontrollierte Link‑Downs, IP‑SLA‑Targets unreachability) und dokumentieren Sie Messwerte sowie akzeptable Baselines. So erkennen Sie schleichende Verschlechterungen, bevor Anwender betroffen sind. Dokumentation, automatisierte Backups und ein klarer Notfallpfad machen HA für Core‑Router im Betrieb wirklich belastbar.

Für dieses Thema sind auch Vrrp Konfigurieren und Hsrp Konfigurieren wichtig. Der Beitrag ordnet diese Aspekte verständlich ein und zeigt, worauf es im Alltag ankommt.