Netzwerk-Redundanzfehler beheben Sie, indem Sie zuerst prüfen, welches Protokoll (HSRP, VRRP, GLBP, BGP oder LACP) den Failover steuern soll, den tatsächlichen Zustand mit den passenden Show-Befehlen abgleichen und dann Prioritäten, Hello-Timer, Trackings und physische Verbindungen korrigieren. Erst danach den Failover kontrolliert testen.
Symptome
- Ausfallzeit von mehreren Sekunden bis Minuten, obwohl ein zweiter Uplink oder Router bereitsteht
- Beide HSRP- oder VRRP-Peers melden gleichzeitig den Status Active bzw. Master
- Port-Channel zeigt suspended oder individual statt bundled auf einer Seite
- BGP-Sessions flappen zyklisch zwischen Established und Idle
- Spanning Tree blockiert nach Failover die falsche Uplink-Verbindung
Häufige Ursachen
Fehlkonfigurierte First-Hop-Redundanz
Ungleiche Prioritäten, fehlendes preempt oder abweichende virtuelle IPs führen dazu, dass HSRP- oder VRRP-Gruppen nicht korrekt umschalten oder in einen Split-Brain-Zustand geraten.
LACP-Aushandlung schlägt fehl
Unterschiedliche LACP-Modi (active/passive), abweichende Geschwindigkeiten oder inkonsistente Channel-Group-IDs verhindern, dass der Port-Channel bündelt. Der Ausfall einer Leitung reißt dann die gesamte Verbindung mit.
Object-Tracking fehlt oder greift nicht
HSRP/VRRP kennt zwar den Peer-Status, aber nicht den Zustand des Uplinks. Ohne IP SLA oder Interface-Tracking bleibt der Router aktiv, obwohl sein WAN-Interface längst tot ist.
STP-Topologie widerspricht dem Redundanzdesign
Falsche Root-Bridge-Wahl oder statische Portkosten sorgen dafür, dass Spanning Tree den geplanten Backup-Pfad dauerhaft blockiert oder nach Failover die falschen Ports öffnet.
BGP-Timer und Policies
Zu lange Keepalive-/Hold-Timer verzögern den Failover um Minuten. Fehlende BFD-Sitzungen oder asymmetrische Route-Maps können Backup-Pfade komplett unbrauchbar machen.
Schritt-für-Schritt-Lösung
- Redundanzdesign und Ist-Zustand dokumentieren
Bevor Sie etwas ändern, zeichnen Sie das Soll auf: Welcher Router soll pro VLAN aktiv sein, welcher Uplink ist primär, welches Protokoll trägt den Failover? Vergleichen Sie das mit dem Ist-Zustand aus den Configs. Ohne diese Basis reparieren Sie Symptome, nicht Ursachen. - HSRP- oder VRRP-Gruppenzustand prüfen
Führen Sie auf beiden Peers show standby brief bzw. show vrrp brief aus. Nur ein Gerät darf Active/Master sein, die virtuelle IP muss identisch sein und preempt sollte auf dem gewünschten Primärgerät gesetzt sein. Prüfen Sie zusätzlich Priorität, Gruppen-ID und Authentifizierung. - Uplink-Tracking konfigurieren
Binden Sie den Router-Status an den WAN-Uplink. Legen Sie ein IP SLA an, verknüpfen Sie es per track-Objekt und reduzieren Sie die HSRP-/VRRP-Priorität um mindestens den Wert, der einen Wechsel auslöst (Standard 10). So schaltet die Gruppe auch bei Uplink-Verlust ohne Peer-Ausfall um. - LACP- und EtherChannel-Bündel verifizieren
show etherchannel summary muss auf beiden Seiten SU (in use) zeigen. Prüfen Sie identische Modi (active/active oder active/passive, nie on gegen active), gleiche Duplex- und Speed-Einstellungen sowie identische Trunk-Konfiguration. Ein einziger abweichender Parameter kippt das Bündel. - Spanning Tree konsistent halten
Setzen Sie die Root Bridge bewusst per spanning-tree vlan x root primary und die Backup-Root auf dem sekundären Core. Kontrollieren Sie mit show spanning-tree, welche Ports Forwarding oder Blocking sind. Aktivieren Sie Rapid PVST+ oder MST, damit Failover in Sekunden statt in bis zu 50 Sekunden abläuft. - BGP-Failover mit BFD beschleunigen
Prüfen Sie show ip bgp summary auf stabile Sessions. Reduzieren Sie die Erkennungszeit durch Bidirectional Forwarding Detection statt sehr kurzer BGP-Timer, die die CPU belasten. Kontrollieren Sie Route-Maps und local-preference, damit der Backup-Pfad im Ernstfall wirklich installiert wird. - Kontrollierten Failover-Test fahren
Testen Sie im Wartungsfenster: Uplink am aktiven Router administrativ herunterfahren, dann den Router selbst neu laden, danach eine einzelne Leitung im Port-Channel trennen. Messen Sie jeweils Ausfallzeit und Paketverlust per Dauer-Ping und logging. Erst wenn alle drei Szenarien sauber greifen, ist die Redundanz belastbar. - Hardware- und Verkabelung ausschließen
Bleibt der Failover instabil, tauschen Sie SFPs, Patchkabel und Fasern paarweise. Prüfen Sie show interfaces auf CRC-Fehler, Input-Errors und Flaps. Redundanzprotokolle können defekte Optik nicht kompensieren, sie reagieren nur auf sie.
Typische Symptome, wahrscheinliche Ursache und erster Prüfschritt
| Symptom | Wahrscheinliche Ursache | Erster Prüfschritt |
|---|---|---|
| Beide Router Active | HSRP-Hellos werden nicht ausgetauscht | VLAN-Trunk und Gruppen-ID auf beiden Seiten prüfen |
| Failover dauert 30–50 Sekunden | Klassisches Spanning Tree statt Rapid PVST+/MST | show spanning-tree, Modus umstellen |
| Port-Channel suspended | LACP-Modus oder Speed ungleich | show etherchannel summary, Interface-Konfig vergleichen |
| Router bleibt Active trotz WAN-Ausfall | Kein Uplink-Tracking konfiguriert | IP SLA und track-Objekt an HSRP/VRRP binden |
| BGP-Session flappt | Hold-Timer zu kurz oder MTU-Problem | show ip bgp neighbors, MTU per ping df-bit testen |
| Backup-Pfad wird nie genutzt | Route-Map oder local-preference falsch | show ip route und Policy-Konfiguration prüfen |
So beugen Sie vor
- Konfigurations-Backups und Diffs versionieren, damit Änderungen nachvollziehbar bleiben
- Failover mindestens halbjährlich aktiv testen, nicht nur auf Papier prüfen
- Monitoring auf HSRP-State-Changes, LACP-Flaps und BGP-Session-Änderungen alarmieren
- Firmware auf Core- und Distribution-Geräten paarweise und geplant aktualisieren
Häufige Fragen
Warum schaltet HSRP nicht um, obwohl der WAN-Uplink weg ist?
HSRP überwacht standardmäßig nur seinen Peer, nicht den Uplink. Fällt beim aktiven Router nur die WAN-Seite aus, bleibt er in der Gruppe weiterhin Active. Sie müssen ein track-Objekt (etwa auf das Uplink-Interface oder eine IP SLA) definieren und die HSRP-Priorität an dessen Zustand koppeln.
Wie schnell sollte ein sauberer Failover ablaufen?
Mit Rapid PVST+ oder MST plus HSRP/VRRP sind unter einer Sekunde Ausfallzeit im LAN realistisch. Bei BGP mit BFD sprechen wir über wenige hundert Millisekunden, ohne BFD eher über mehrere Sekunden. Klassisches Spanning Tree ohne Optimierung kann dagegen bis zu 50 Sekunden benötigen.
Kann ich Failover im Produktivbetrieb einfach testen?
Nicht ohne Vorbereitung. Planen Sie ein Wartungsfenster, informieren Sie betroffene Fachbereiche und starten Sie mit dem am wenigsten kritischen Segment. Nutzen Sie Dauer-Pings, Syslog und SNMP-Traps, um Ausfallzeit und Konvergenz messbar zu dokumentieren, statt sich auf subjektive Eindrücke zu verlassen.