VRRP verstehen

VRRP-Unterschiede bei QFabric-Systemen

Die Konfiguration von Servern in Ihrem Netzwerk mit statischen Routen zu einem Standard-Gateway minimiert den Konfigurationsaufwand und die Komplexität und reduziert den Verarbeitungsaufwand. Ein Ausfall des Standard-Gateways führt jedoch in der Regel zu einem katastrophalen Ereignis, bei dem die Server isoliert werden. Mit dem Virtual Router Redundancy Protocol (VRRP) können Sie dynamisch alternative Gateways für Server bereitstellen, wenn das primäre Gateway ausfällt.

Switches, die mit VRRP konfiguriert sind, teilen sich eine virtuelle IP-Adresse (VIP). Dies ist die Adresse, die Sie als Standardroute auf den Servern konfigurieren. Im normalen VRRP-Betrieb ist einer der Switches der primäre VRRP-Switch, was bedeutet, dass er die VIP besitzt und das aktive Standard-Gateway ist. Bei den anderen Geräten handelt es sich um Backups. Die Switches weisen Primär- und Backup-Rollen basierend auf den von Ihnen konfigurierten Prioritäten dynamisch zu. Wenn der primäre Switch ausfällt, wird der Backup-Switch mit der höchsten Priorität zum primären Switch und übernimmt innerhalb weniger Sekunden den Besitz der VIP. Dies geschieht ohne jegliche Interaktion mit den Servern.

Sie können zwei QFabric-Systeme so konfigurieren, dass sie an einer VRRP-Konfiguration teilnehmen, als ob es sich um zwei eigenständige Switches handeln würde. Im normalen VRRP-Betrieb kann jedoch immer nur ein System das primäre System für eine bestimmte VRRP-Gruppe sein, was bedeutet, dass nur ein System als Standard-Gateway mit der für die Gruppe konfigurierten VIP fungieren kann. Wenn Sie VRRP über zwei QFabric-Systeme ausführen, möchten Sie möglicherweise, dass beide Systeme gleichzeitig die VIP verwenden, um als Gateway zu fungieren und Datenverkehr weiterzuleiten. Um dies zu erreichen, können Sie einen Firewall-Filter konfigurieren, um die VRRP-Werbepakete zwischen den QFabric-Systemen auf der Verbindung zwischen den beiden Netzwerkknotengruppen zu blockieren. Wenn Sie dies tun, fungieren beide QFabric-Systeme als primärer Datenverkehr und leiten den Datenverkehr weiter, der von der VIP empfangen wird (dies ist die Standard-Gateway-Adresse, die Sie auf Servern konfigurieren, die mit beiden QFabric-Systemen verbunden sind). Wenn Sie vMotion von VMware verwenden, können virtuelle Maschinen mit dieser Konfiguration zwischen Servern wechseln, die mit den QFabric-Systemen verbunden sind, ohne deren Standard-Gateway-Informationen zu aktualisieren. Beispielsweise kann eine virtuelle Maschine, die auf einem Server ausgeführt wird, der mit einem QFabric-System in Datencenter A verbunden ist, auf einen Server übergehen, der mit einem QFabric-System in Datencenter B verbunden ist, ohne dass eine neue Gateway-IP-Adresse und eine neue MAC-Adresse aufgelöst werden müssen, da beide QFabric-Systeme dieselbe VIP verwenden.

Konfigurationsdetails

Die Konfiguration einer VRRP-Gruppe über zwei QFabric-Systeme hinweg ähnelt der Konfiguration von VRRP auf zwei Switches. Die wichtigsten Unterschiede sind hier aufgeführt:

• Alle Schnittstellen in beiden QFabric-Systemen, die am VRRP teilnehmen, müssen Mitglieder desselben VLANs sein.

• Sie müssen in diesem VLAN auf beiden QFabric-Systemen geroutete VLAN-Schnittstellen (RVIs) erstellen.

• Die IP-Adressen, die Sie beiden RVIs zuweisen, müssen sich im selben Subnetz befinden.

• Sie müssen VRRP auf den RVIs konfigurieren.

• Beide RVIs müssen Mitglieder derselben VRRP-Gruppe sein. Dies ermöglicht es den beiden QFabric-Systemen, eine virtuelle IP-Adresse zu teilen.

In den folgenden Tabellen sind die Elemente einer VRRP-Beispielkonfiguration aufgeführt, die auf zwei QFabric-Systemen ausgeführt wird: QFabric-System A und QFabric-System B. Dieses Beispiel ist so konfiguriert, dass beide QFabric-Systeme als VRRP-Primärsystem für VIP 10.1.1.50/24 fungieren und es wird davon ausgegangen, dass ein Firewall-Filter die VRRP-Ankündigungen zwischen den Systemen blockiert. Tabelle 1 listet die erforderlichen Eigenschaften der RVIs in der Beispielkonfiguration auf.

Sie müssen VRRP auf den RVIs auf beiden QFabric-Systemen konfigurieren. Tabelle 2 listet die Elemente einer VRRP-Beispielkonfiguration auf jedem RVI auf. Beachten Sie, dass mit Ausnahme der Priorität die Parameter auf beiden Systemen identisch sein müssen .

Tabelle 3 listet alle Schnittstellen auf QFabric-System A in der Beispielkonfiguration auf und gibt an, mit welchen Schnittstellen sie verbunden sind.

Tabelle 4 listet alle Schnittstellen auf QFabric-System B in der Beispielkonfiguration auf und gibt an, mit welchen Schnittstellen sie verbunden sind.

VRRP-Unterstützung für Junos OS

In Versionen vor Version 12.2 unterstützte Junos OS RFC 3768, Virtual Router Redundancy Protocol (VRRP) (für IPv4) und Internet draft-ietf-vrrp-ipv6-spec-08, Virtual Router Redundancy Protocol für IPv6.

VRRPv3 wird nicht auf Routern unterstützt, die Versionen vor Junos OS Version 12.2 verwenden, und wird auch nicht für IPv6 auf QFX10000-Switches unterstützt.

Ab Version 12.2 unterstützt Junos OS:

• RFC 3768, Virtual Router Redundancy Protocol (VRRP)

• RFC 5798, Virtual Router Redundancy Protocol (VRRP) Version 3 für IPv4 und IPv6

• RFC 6527, Definitionen verwalteter Objekte für Virtual Router Redundancy Protocol Version 3 (VRRPv3)

IPv6 VRRP Prüfsumme – Verhaltensunterschiede

Sie müssen die folgenden Prüfsummenunterschiede berücksichtigen, wenn Sie IPv6-VRRP-Netzwerke aktivieren:

• In Versionen vor Junos OS Release 12.2 wird bei der Konfiguration von VRRP für IPv6 die VRRP-Prüfsumme gemäß Abschnitt 5.3.8 von RFC 3768, Virtual Router Redundancy Protocol (VRRP) berechnet.

• Ab Junos OS Version 12.2 wird bei der Konfiguration von VRRP für IPv6 die VRRP-Prüfsumme gemäß Abschnitt 5.2.8 von RFC 5798, Virtual Router Redundancy Protocol (VRRP) Version 3 für IPv4 und IPv6, berechnet, unabhängig davon, ob VRRPv3 aktiviert ist oder nicht.

  Darüber hinaus wird der Pseudoheader nur bei der Berechnung der IPv6-VRRP-Prüfsumme berücksichtigt. Der Pseudoheader wird bei der Berechnung der IPv4-VRRP-Prüfsumme nicht berücksichtigt.

  Damit der Router mit Junos OS Version 12.2 (oder höheren Junos OS-Versionen) IPv6 mit dem Router interoperiert, auf dem eine Junos OS-Version vor Version 12.2 ausgeführt wird, fügen Sie die checksum-without-pseudoheader Konfigurationsanweisung auf der Hierarchieebene des Routers ein, auf dem [edit protocols vrrp] Junos OS Version 12.2 oder höher ausgeführt wird.

• Das tcpdump Dienstprogramm in Junos OS Version 12.2 und höher berechnet die VRRP-Prüfsumme gemäß RFC 5798, Virtual Router Redundancy Protocol (VRRP) Version 3 für IPv4 und IPv6. Daher wird beim tcpdump Parsen von IPv6-VRRP-Paketen, die von älteren Junos OS-Versionen (vor Junos OS Version 12.2) empfangen werden, die bad vrrp cksum folgende Meldung angezeigt:

  Sie können diese Meldung ignorieren, da sie nicht auf einen VRRP-Fehler hinweist.

VRRP-Interoperabilität

In Versionen vor Junos OS Version 12.2 folgte VRRP (IPv6) dem Internet-Entwurf draft-ietf-vrrp-ipv6-spec-08, aber die Prüfsumme wurde basierend auf RFC 3768 Abschnitt 5.3.8 berechnet. Ab Version 12.2 folgt VRRP (IPv6) RFC 5798 und die Prüfsumme wird basierend auf RFC 5798 Abschnitt 5.2.8 berechnet. Aufgrund der unterschiedlichen VRRP-Prüfsummenberechnungen kann IPv6-VRRP, das auf Routern konfiguriert ist, die Junos OS Version 12.2 und höher verwenden, nicht mit IPv6-VRRP zusammenarbeiten, die in Versionen vor Junos OS Version 12.2 konfiguriert wurden.

Damit der Router mit Junos OS Version 12.2 (oder späteren Junos OS-Versionen) IPv6 VRRP mit dem Router interoperiert, auf dem Junos OS-Versionen vor Version 12.2 ausgeführt werden, schließen Sie die checksum-without-pseudoheader Konfigurationsanweisung auf der [edit protocols vrrp] Hierarchieebene in den Router mit Junos OS Version 12.2 oder höher ein.

Hier sind einige allgemeine Punkte, die Sie über VRRP-Interoperabilität wissen sollten:

• Wenn Sie VRRPv3 (IPv4 oder IPv6) auf Routern konfiguriert haben, die Junos OS Version 12.2 oder höher verwenden, funktioniert es nicht mit Routern, die Junos OS Version 12.1 oder frühere Versionen verwenden. Dies liegt daran, dass nur Junos OS Version 12.2 und höher VRRPv3 unterstützen.

• VRRP (IPv4 oder IPv6), das auf Routern konfiguriert ist, die Junos OS Version 12.2 und höher verwenden, funktioniert mit VRRP (IPv4 oder IPv6), das auf Routern konfiguriert ist, die Versionen vor Junos OS Version 12.2 verwenden.

• VRRPv3 für IPv4 arbeitet nicht mit den vorherigen Versionen von VRRP zusammen. Wenn VRRPv2-IPv4-Ankündigungspakete von einem Router empfangen werden, auf dem VRRPv3 aktiviert ist, wechselt der Router in den Backup-Zustand, um zu vermeiden, dass mehrere Primärdateien im Netzwerk erstellt werden. Aufgrund dieses Verhaltens müssen Sie vorsichtig sein, wenn Sie VRRPv3 in Ihren vorhandenen VRRPv2-Netzwerken aktivieren. Weitere Informationen finden Sie unter Upgrade von VRRPv2 auf VRRPv3 .

  Anmerkung:

  VRRPv3-Ankündigungspakete werden von den Routern ignoriert, auf denen frühere Versionen von VRRP konfiguriert sind.

Upgrade von VRRPv2 auf VRRPv3

Aktivieren Sie VRRPv3 in Ihrem Netzwerk nur, wenn VRRPv3 auf allen VRRP-Routern in Ihrem Netzwerk aktiviert werden kann.

Aktivieren Sie VRRPv3 in Ihrem VRRPv2-Netzwerk nur, wenn Sie ein Upgrade von VRRPv2 auf VRRPv3 durchführen. Das Mischen der beiden Versionen von VRRP ist keine dauerhafte Lösung.

Das Upgrade von VRRPv2 auf VRRPv3 muss sehr sorgfältig durchgeführt werden, um Datenverkehrsverluste zu vermeiden.

• Es ist nicht möglich, VRRPv3 auf allen Routern gleichzeitig zu konfigurieren.

• Während der Übergangszeit werden sowohl VRRPv2 als auch VRRPv3 im Netzwerk betrieben.

• Durch das Ändern der VRRP-Versionen wird der Zustandsautomat für alle VRRP-Gruppen neu gestartet.

• VRRPv3 (für IPv4)-Router verwenden standardmäßig den Backup-Status, wenn sie VRRPv2-Ankündigungspakete (für IPv4) erhalten.

• VRRPv2 (für IPv4) Pakete erhalten immer die höchste Priorität.

• Prüfsummenunterschiede zwischen VRRPv2 und VRRPv3 (für IPv6) können mehrere primäre Router erstellen.

  Deaktivieren Sie VRRPv3 (für IPv6) auf den Backup-Routern während des Upgrades, um zu vermeiden, dass mehrere primäre Router erstellt werden.

Tabelle 5 veranschaulicht die Schritte und Ereignisse, die während eines Übergangs von VRRPv2 zu VRRPv3 stattfinden. In Tabelle 5 sind zwei VRRPv2-Router, R1 und R2, in zwei Gruppen, G1 und G2, konfiguriert. Router R1 fungiert als primärer Router für G1 und Router R2 als primärer Router für G2.

Wenn Sie VRRPv3 aktivieren, stellen Sie sicher, dass VRRPv3 auf allen VRRP-Routern im Netzwerk aktiviert ist, da VRRPv3 (IPv4) nicht mit den vorherigen Versionen von VRRP zusammenarbeitet. Wenn beispielsweise VRRPv2-IPv4-Ankündigungspakete von einem Router empfangen werden, auf dem VRRPv3 aktiviert ist, wechselt der Router in den Backup-Zustand, um zu vermeiden, dass mehrere Primärserver im Netzwerk erstellt werden.

Sie können VRRPv3 aktivieren, indem Sie die Anweisung version-3 auf der [edit protocols vrrp] Hierarchieebene konfigurieren (für IPv4- oder IPv6-Netzwerke). Konfigurieren Sie die gleiche Protokollversion auf allen VRRP-Routern im LAN.

Funktionsweise von VRRPv3 Funktionen

Einige Funktionen von Junos OS unterscheiden sich in VRRPv3 von früheren VRRP-Versionen.

• VRRPv3-Authentifizierung
• VRRPv3 Ankündigungsintervalle
• Einheitliche ISSU für VRRPv3

Wenn die Failoververzögerung nicht konfiguriert ist

Ohne konfigurierte Failoververzögerung sieht die Abfolge der Ereignisse für VRRP-Sitzungen, die von der Routing-Engine aus betrieben werden, wie folgt aus:

1. Wenn die erste VRRP-Gruppe, die von der Routing-Engine erkannt wird, ihren Status ändert und der neue Status primär ist, generiert die Routing-Engine die entsprechenden VRRP-Ankündigungsmeldungen. Die Packet Forwarding Engine wird über die Zustandsänderung informiert, sodass Hardwarefilter für diese Gruppe unverzüglich neu programmiert werden. Der neue primäre Server sendet dann eine kostenlose ARP-Nachricht an die VRRP-Gruppen.

2. Die Verzögerung des Failover-Timers wird gestartet. Standardmäßig ist der Failover-Verzögerungs-Timer wie folgt:

   • 500 Millisekunden: Wenn das konfigurierte VRRP-Ansageintervall weniger als 1 Sekunde beträgt.

   • 2 Sekunden: Das konfigurierte VRRP-Ansageintervall beträgt 1 Sekunde oder mehr und die Gesamtzahl der VRRP-Gruppen auf dem Router beträgt 255.

   • 10 Sekunden: Das konfigurierte VRRP-Ansageintervall beträgt mindestens 1 Sekunde und die Anzahl der VRRP-Gruppen auf dem Router beträgt mehr als 255.

3. Die Routing-Engine führt eine Statusänderung für nachfolgende VRRP-Gruppen durch. Jedes Mal, wenn es eine Zustandsänderung gibt und der neue Status für eine bestimmte VRRP-Gruppe primär ist, generiert die Routing-Engine die entsprechenden VRRP-Ankündigungsmeldungen. Die Kommunikation mit der Packet Forwarding Engine wird jedoch unterdrückt, bis der Timer für die Failoververzögerung abläuft.

4. Nach Ablauf des Failoververzögerungs-Timers sendet die Routing-Engine eine Nachricht über alle VRRP-Gruppen, die den Status ändern konnten, an die Packet Forwarding Engine. Als Konsequenz werden Hardwarefilter für diese Gruppen neu programmiert, und für die Gruppen, deren neuer Status primär ist, werden kostenlose ARP-Nachrichten gesendet.

Dieser Vorgang wird so lange wiederholt, bis der Zustandsübergang für alle VRRP-Gruppen abgeschlossen ist.

Daher wird ohne Konfiguration der Failover-Verzögerung der vollständige Zustandsübergang (einschließlich der Zustände auf der Routing-Engine und der Packet Forwarding Engine) für die erste VRRP-Gruppe sofort durchgeführt, während der Zustandsübergang auf der Packet Forwarding Engine für die verbleibenden VRRP-Gruppen um mindestens 0,5 bis 10 Sekunden verzögert wird, abhängig von den konfigurierten VRRP-Ansagetimern und der Anzahl der VRRP-Gruppen. Während dieses Zwischenzustands kann der Empfang von Datenverkehr für VRRP-Gruppen für Zustandsänderungen, die auf der Packet Forwarding Engine noch nicht abgeschlossen wurden, aufgrund einer verzögerten Neukonfiguration von Hardwarefiltern auf der Ebene der Packet Forwarding Engine unterbrochen werden.

Wenn die Failoververzögerung konfiguriert ist

Wenn die Failoververzögerung konfiguriert ist, wird die Abfolge der Ereignisse für VRRP-Sitzungen, die von der Routing-Engine ausgeführt werden, wie folgt geändert:

1. Die Routing-Engine erkennt, dass einige VRRP-Gruppen eine Zustandsänderung erfordern.

2. Die Failover-Verzögerung beginnt für den konfigurierten Zeitraum. Der zulässige Timerbereich für die Failoververzögerung beträgt 50 bis 100000 Millisekunden.

3. Die Routing-Engine führt eine Statusänderung nach der anderen für die VRRP-Gruppen durch. Jedes Mal, wenn es eine Zustandsänderung gibt und der neue Status für eine bestimmte VRRP-Gruppe primär ist, generiert die Routing-Engine die entsprechenden VRRP-Ankündigungsmeldungen. Die Kommunikation mit der Packet Forwarding Engine wird jedoch unterdrückt, bis der Timer für die Failoververzögerung abläuft.

4. Nach Ablauf des Failoververzögerungs-Timers sendet die Routing-Engine eine Nachricht über alle VRRP-Gruppen, die den Status ändern konnten, an die Packet Forwarding Engine. Als Konsequenz werden Hardwarefilter für diese Gruppen neu programmiert, und für die Gruppen, deren neuer Status primär ist, werden kostenlose ARP-Nachrichten gesendet.

Dieser Vorgang wird so lange wiederholt, bis der Zustandsübergang für alle VRRP-Gruppen abgeschlossen ist.

Wenn also die Failoververzögerung konfiguriert ist, wird sogar der Status der Packet Forwarding Engine für die erste VRRP-Gruppe zurückgestellt. Der Netzbetreiber hat jedoch den Vorteil, dass er einen Failover-Verzögerungswert konfigurieren kann, der am besten zu den Anforderungen der Netzwerkbereitstellung passt, um minimale Ausfälle während der VRRP-Zustandsänderung zu gewährleisten.

Die Failoververzögerung wirkt sich nur auf VRRP-Sitzungen aus, die vom VRRP-Prozess (vrrpd) auf der Routing-Engine ausgeführt werden. Bei VRRP-Sitzungen, die an die Packet Forwarding Engine verteilt werden, hat die Konfiguration der Failoververzögerung keine Auswirkungen.