VRRP verstehen
Mit dem Virtual Router Redundancy Protocol (VRRP) lassen sich virtuelle redundante Routing-Plattformen in einem LAN erstellen, sodass der Datenverkehr über das LAN geroutet werden kann, ohne auf eine einzige Routing-Plattform angewiesen zu sein.
VRRP verstehen
Für Ethernet, Fast Ethernet, Gigabit Ethernet, 10-Gigabit Ethernet und logische Schnittstellen können Sie das Virtual Router Redundancy Protocol (VRRP) oder VRRP für IPv6 konfigurieren. VRRP ermöglicht es Hosts in einem LAN, redundante Routing-Plattformen in diesem LAN zu nutzen, ohne dass mehr als die statische Konfiguration einer einzelnen Standardroute auf den Hosts erforderlich ist. Die VRRP-Routing-Plattformen teilen sich die IP-Adresse, die der auf den Hosts konfigurierten Standardroute entspricht. Zu jeder Zeit ist eine der VRRP-Routing-Plattformen die primäre (aktive) und die anderen sind Backups. Wenn die primäre Routing-Plattform ausfällt, wird eine der Backup-Routing-Plattformen zur neuen primären Routing-Plattform, die eine virtuelle Standard-Routing-Plattform bereitstellt und das Routing des Datenverkehrs über das LAN ermöglicht, ohne sich auf eine einzige Routing-Plattform zu verlassen. Mittels VRRP kann ein Backup-Gerät innerhalb weniger Sekunden ein ausgefallenes Standardgerät übernehmen. Dies geschieht mit minimalem VRRP-Datenverkehr und ohne Interaktion mit den Hosts. Das Virtual Router Redundancy-Protokoll wird auf Verwaltungsschnittstellen nicht unterstützt.
Geräte, auf denen VRRP ausgeführt wird, wählen dynamisch Primär- und Backup-Geräte aus. Sie können auch die Zuweisung von Primär- und Sicherungsgeräten mit Prioritäten von 1 bis 255 erzwingen, wobei 255 die höchste Priorität ist. Im VRRP-Betrieb sendet das primäre Standardgerät in regelmäßigen Abständen Ankündigungen an Sicherungsgeräte. Das Standardintervall beträgt 1 Sekunde. Wenn ein Backup-Gerät für einen festgelegten Zeitraum keine Ankündigung erhält, übernimmt das Backup-Gerät mit der nächsthöheren Priorität die Rolle des primären Geräts und beginnt mit der Weiterleitung von Paketen.
Die Priorität 255 kann für geroutete VLAN-Schnittstellen (RVIs) nicht festgelegt werden.
Um den Netzwerkverkehr zu minimieren, ist VRRP so konzipiert, dass nur das Gerät, das als primäres Gerät fungiert, zu einem bestimmten Zeitpunkt VRRP-Werbung aussendet. Die Backup-Geräte senden keine Werbung, bis sie die Hauptrolle übernehmen.
VRRP für IPv6 bietet einen viel schnelleren Switchover zu einem alternativen Standard-Router als IPv6-Neighbor-Discovery-Verfahren. Typische Bereitstellungen verwenden nur einen Backup-Router.
Verwechseln Sie die primären und Backup-Routing-Plattformen von VRRP nicht mit den primären und Backup-Komponenten-Switches einer Virtual Chassis-Konfiguration . Die primären und Backup-Mitglieder einer Virtual Chassis-Konfiguration bilden einen einzigen Host. In einer VRRP-Topologie fungiert ein Host als primäre Routing-Plattform und ein anderer als Backup-Routing-Plattform, wie in Abbildung 3 dargestellt.
VRRP ist in RFC 3768, Virtual Router Redundancy Protocol, definiert. VRRP für IPv6 ist in draft-ietf-vrrp-ipv6-spec-08.txt Virtual Router Redundancy Protocol für IPv6 definiert. Siehe auch draft-ietf-vrrp-unified-mib-06.txt, Definitionen verwalteter Objekte für VRRP über IPv4 und IPv6.
Obwohl VRRP gemäß RFC 3768 keine Authentifizierung unterstützt, unterstützt die Junos OS-Implementierung von VRRP die Authentifizierung gemäß RFC 2338. Diese Unterstützung wird durch die Abwärtskompatibilitätsoptionen in RFC 3768 erreicht.
Auf den Switches EX2300 und EX3400 muss das VRRP-Protokoll mit einem Hello-Intervall von 2 Sekunden oder mehr mit einem Totintervall von mindestens 6 Sekunden konfiguriert werden, um Flaps bei CPU-intensiven Betriebsereignissen wie Routing-Engine-Umschaltung, Schnittstellen-Flaps und umfassender Datenerfassung von der Paketweiterleitungs-Engine zu vermeiden.
Abbildung 1 zeigt eine grundlegende VRRP-Topologie. In diesem Beispiel wird auf den Routern A, B und C VRRP ausgeführt und zusammen ein virtueller Router gebildet. Die IP-Adresse dieses virtuellen Routers lautet 10.10.0.1 (dieselbe Adresse wie die physische Schnittstelle von Router A).
Da der virtuelle Router die IP-Adresse der physischen Schnittstelle von Router A verwendet, ist Router A der primäre VRRP-Router, während die Router B und C als Backup-VRRP-Router fungieren. Die Clients 1 bis 3 sind mit der standardmäßigen Gateway-IP-Adresse 10.10.0.1 konfiguriert. Als primärer Router leitet Router A Pakete weiter, die an seine IP-Adresse gesendet werden. Wenn der primäre virtuelle Router ausfällt, wird der mit der höheren Priorität konfigurierte Router zum primären virtuellen Router und stellt einen unterbrechungsfreien Service für die LAN-Hosts bereit. Wenn Router A wiederhergestellt ist, wird er wieder zum primären virtuellen Router.
In einigen Fällen gibt es während einer Inherit-Sitzung einen kleinen Zeitraum, in dem sich zwei Router im Primär-Primär-Status befinden. In solchen Fällen senden die VRRP-Gruppen, die den Status erben, alle 120 Sekunden VRRP-Ankündigungen. Es dauert also bis zu 120 Sekunden, bis sich die Router erholen, nachdem sie vom primären Primär-Primär-Zustand in den Primary-Backup-Status gewechselt sind.
Router der ACX-Serie können bis zu 64 VRRP-Gruppeneinträge unterstützen. Dies kann eine Kombination aus IPv4- oder IPv6-Familien sein. Wenn eine der Produktfamilien (IPv4 oder IPv6) ausschließlich für VRRP konfiguriert ist, werden 64 eindeutige VRRP-Gruppenbezeichner unterstützt. Wenn beide IPv4- und IPv6-Familien dieselbe VRRP-Gruppe verwenden, werden nur 32 eindeutige VRRP-Bezeichner unterstützt.
Router der ACX-Serie unterstützen VRRP Version 3 für IPv6-Adressen.
Der ACX5448-Router unterstützt RFC 3768 VRRP Version 2 und RFC 5798 VRRP Version 3. Der ACX5448-Router unterstützt auch die Konfiguration von VRRP über aggregiertes Ethernet und integrierte Routing- und Bridging-Schnittstellen (IRB).
Die folgenden Einschränkungen gelten für die Konfiguration von VRRP auf dem ACX5448-Router:
-
Konfigurieren Sie maximal 16 VRRP-Gruppen.
-
Das Zusammenspiel von VRRP Version 2 und VRRP Version 3 wird nicht unterstützt.
-
Die VRRP-Delegatverarbeitung wird nicht unterstützt.
-
VRRP Version 2-Authentifizierung wird nicht unterstützt.
Abbildung 1 zeigt eine grundlegende VRRP-Topologie mit Switches der EX-Serie. In diesem Beispiel wird auf den Switches A, B und C VRRP ausgeführt, und zusammen bilden sie eine virtuelle Routing-Plattform. Die IP-Adresse dieser virtuellen Routing-Plattform lautet 10.10.0.1 (dieselbe Adresse wie die physische Schnittstelle von Switch A).
der EX-Serie
Abbildung 3 zeigt eine grundlegende VRRP-Topologie unter Verwendung von Virtual Chassis-Konfigurationen. Switch A, Switch B und Switch C bestehen jeweils aus mehreren miteinander verbundenen Ethernet-Switches EX4200 von Juniper Networks. Jede Virtual Chassis-Konfiguration arbeitet als einzelner Switch, auf dem VRRP ausgeführt wird, und zusammen bilden sie eine virtuelle Routing-Plattform. Die IP-Adresse dieser virtuellen Routing-Plattform lautet 10.10.0.1 (dieselbe Adresse wie die physische Schnittstelle von Switch A).
Da die virtuelle Routing-Plattform die IP-Adresse der physischen Schnittstelle von Switch A verwendet, ist Switch A die primäre VRRP-Routing-Plattform, während Switch B und Switch C als Backup-VRRP-Routing-Plattformen fungieren. Die Clients 1 bis 3 sind mit der standardmäßigen Gateway-IP-Adresse konfiguriert 10.10.0.1 , da der primäre Router, Switch A, an seine IP-Adresse gesendete Pakete weiterleitet. Wenn die primäre Routing-Plattform ausfällt, wird der mit der höheren Priorität konfigurierte Switch zur primären virtuellen Routing-Plattform und bietet einen unterbrechungsfreien Service für die LAN-Hosts. Wenn Switch A wiederhergestellt ist, wird er wieder zur primären virtuellen Routing-Plattform.
VRRP und VRRP für IPv6 – Übersicht
Sie können das Virtual Router Redundancy Protocol (VRRP) und VRRP für IPv6 für die folgenden Schnittstellen konfigurieren:
Ethernet (Ethernet)
Fast Ethernet
Tri-Rate Ethernet Kupfer
Gigabit-Ethernet
10-Gigabit Ethernet LAN/WAN PIC
Logische Ethernet-Schnittstellen
VRRP und VRRP für IPv6 ermöglichen es Hosts in einem LAN, redundante Router in diesem LAN zu nutzen, ohne dass mehr als die statische Konfiguration einer einzelnen Standardroute auf den Hosts erforderlich ist. Die VRRP-Router teilen sich die IP-Adresse, die der auf den Hosts konfigurierten Standardroute entspricht. Zu jeder Zeit ist einer der VRRP-Router der primäre (aktive) und die anderen sind Backups. Wenn der primäre Router ausfällt, wird einer der Backup-Router zum neuen primären Router, wodurch immer ein virtueller Standard-Router zur Verfügung steht und der Datenverkehr im LAN geroutet werden kann, ohne sich auf einen einzelnen Router zu verlassen.
VRRP ist in RFC 3768, Virtual Router Redundancy Protocol, definiert.
Übersichtsinformationen zu VRRP und VRRP für IPv6, Konfigurationsrichtlinien und Zusammenfassungen finden Sie im Benutzerhandbuch für hohe Verfügbarkeit von Junos OS.
Unterstützung von Junos OS für VRRPv3
Der Vorteil der Verwendung von VRRPv3 besteht darin, dass VRRPv3 sowohl IPv4- als auch IPv6-Adressfamilien unterstützt, während VRRPv2 nur IPv4-Adressen unterstützt.
In den folgenden Themen werden die Unterstützung und Interoperabilität von VRRPv3 durch Junos OS sowie einige Unterschiede zwischen VRRPv3 und seinen Vorläufern beschrieben:
- Unterstützung für Junos OS VRRP
- IPv6 VRRP-Prüfsummen-Verhaltensunterschiede
- VRRP-Interoperabilität
- Upgrade von VRRPv2 auf VRRPv3
- Funktionalität der VRRPv3-Funktionen
Unterstützung für Junos OS VRRP
In Versionen vor Version 12.2 unterstützte Junos OS RFC 3768, Virtual Router Redundancy Protocol (VRRP) (für IPv4) und Internet draft draft-ietf-vrrp-ipv6-spec-08, Virtual Router Redundancy Protocol für IPv6.
VRRPv3 wird auf Routern, die Versionen vor Junos OS Version 12.2 verwenden, nicht unterstützt und wird auch nicht für IPv6 auf QFX10000-Switches unterstützt.
VRRPv3 für IPv6 wird auf QFX10002-60C 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)
VRRP (für IPv6) auf Routern, die Junos OS Version 12.2 und höher verwenden, ist aufgrund der Unterschiede in den VRRP-Prüfsummenberechnungen nicht mit VRRP (für IPv6) auf Routern mit früheren Junos OS-Versionen kompatibel. Siehe IPv6 VRRP Prüfsummen-Verhaltensunterschiede.
IPv6 VRRP-Prüfsummen-Verhaltensunterschiede
Sie müssen die folgenden Prüfsummenunterschiede berücksichtigen, wenn Sie IPv6-VRRP-Netzwerke aktivieren:
In Versionen vor Junos OS Version 12.2 wird die VRRP-Prüfsumme bei Konfiguration von VRRP für IPv6 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 neueren Junos OS-Versionen) IPv6-VRRP mit dem Router interoperiert, auf dem eine Junos OS-Version vor Version 12.2 ausgeführt wird, fügen Sie die
checksum-without-pseudoheaderKonfigurationsanweisung auf Hierarchieebene[edit protocols vrrp]in den Router ein, auf dem Junos OS Version 12.2 oder höher ausgeführt wird.Das
tcpdumpDienstprogramm 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. Wenntcpdumpalso IPv6-VRRP-Pakete analysiert werden, die von älteren Junos OS-Versionen (vor Junos OS Version 12.2) empfangen werden, wird diebad vrrp cksumfolgende Meldung angezeigt:23:20:32.657328 Out ... -----original packet----- 00:00:5e:00:02:03 > 33:33:00:00:00:12, ethertype IPv6 (0x86dd), length 94: (class 0xc0, hlim 255, next-header: VRRP (112), length: 40) fe80::224:dcff:fe47:57f > ff02::12: VRRPv3-advertisement 40: vrid=3 prio=100 intvl=100(centisec) (bad vrrp cksum b4e2!) addrs(2): fe80::200:5eff:fe00:3,2001:4818:f000:14::1 3333 0000 0012 0000 5e00 0203 86dd 6c00 0000 0028 70ff fe80 0000 0000 0000 0224 dcff fe47 057f ff02 0000 0000 0000 0000 0000 0000 0012 3103 6402 0064 b4e2 fe80 0000 0000 0000 0200 5eff fe00 0003 2001 4818 f000 0014 0000 0000 0000 0001Sie 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 Unterschiede bei der Berechnung der VRRP-Prüfsumme ist IPv6 VRRP, das auf Routern konfiguriert ist, die Junos OS Version 12.2 und höher verwenden, nicht mit IPv6 VRRP kompatibel, das in Versionen vor Junos OS Version 12.2 konfiguriert wurde.
Damit der Router mit Junos OS Version 12.2 (oder neueren Junos OS-Versionen) IPv6-VRRP mit dem Router interoperiert, auf dem Junos OS-Versionen vor Version 12.2 ausgeführt werden, fügen Sie die checksum-without-pseudoheader Konfigurationsanweisung auf der [edit protocols vrrp] Hierarchieebene im 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 VRRPv3 nur von Junos OS Version 12.2 und höher unterstützt wird.
VRRP (IPv4 oder IPv6), konfiguriert auf Routern, die Junos OS Version 12.2 und höher verwenden, interoperiert mit VRRP (IPv4 oder IPv6), konfiguriert auf Routern, die Versionen vor Junos OS Version 12.2 verwenden.
VRRPv3 für IPv4 ist nicht mit den vorherigen Versionen von VRRP kompatibel. Wenn VRRPv2 IPv4-Werbepakete von einem Router empfangen werden, auf dem VRRPv3 aktiviert ist, wechselt der Router in den Backup-Zustand, um zu vermeiden, dass mehrere primäre Verbindungen 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 .
Hinweis: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.
Ein VRRP-Versionswechsel wird als katastrophal und störend angesehen und verläuft möglicherweise nicht ohne Folgen. Die Dauer des Paketverlusts hängt von vielen Faktoren ab, wie z. B. der Anzahl der VRRP-Gruppen, den beteiligten Schnittstellen und FPCs und der Last anderer Services und Protokolle, die auf dem Router ausgeführt werden.
Ein Upgrade von VRRPv2 auf VRRPv3 muss aus folgenden Gründen 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 arbeiten sowohl VRRPv2 als auch VRRPv3 im Netzwerk.
Beim Ändern von VRRP-Versionen wird der Zustandsautomat für alle VRRP-Gruppen neu gestartet.
VRRPv3-Router (für IPv4) verwenden standardmäßig den Backup-Status, wenn sie VRRPv2-Werbepakete (für IPv4) erhalten.
VRRPv2-Pakete (für IPv4) 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 1 veranschaulicht die Schritte und Ereignisse, die während eines Übergangs von VRRPv2 zu VRRPv3 stattfinden. In Tabelle 1 sind zwei VRRPv2-Router, R1 und R2, in zwei Gruppen konfiguriert, G1 und G2. Router R1 fungiert als primärer Router für G1 und Router R2 als primärer Router für G2.
|
|
For IPv4 |
For IPv6 |
|
|
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 interoperiert. Wenn beispielsweise VRRPv2-IPv4-Werbepakete von einem Router empfangen werden, auf dem VRRPv3 aktiviert ist, wechselt der Router in den Backup-Zustand, um zu vermeiden, dass mehrere primäre Verbindungen im Netzwerk erstellt werden.
Sie können VRRPv3 aktivieren, indem Sie die version-3 Anweisung auf der [edit protocols vrrp] Hierarchieebene konfigurieren (für IPv4- oder IPv6-Netzwerke). Konfigurieren Sie auf allen VRRP-Routern im LAN dieselbe Protokollversion.
Funktionalität der VRRPv3-Funktionen
Einige Funktionen von Junos OS unterscheiden sich in VRRPv3 von früheren VRRP-Versionen.
VRRPv3-Authentifizierung
Wenn VRRPv3 (für IPv4) aktiviert ist, lässt es keine Authentifizierung zu.
Die
authentication-typeand-Anweisungenauthentication-keykönnen nicht für VRRP-Gruppen konfiguriert werden.Sie müssen eine Nicht-VRRP-Authentifizierung verwenden.
VRRPv3 Werbeintervalle
VRRPv3-Ankündigungsintervalle (für IPv4 und IPv6) müssen mit der fast-interval Anweisung auf Hierarchieebene [edit interfaces interface-name unit 0 family inet address ip-address vrrp-group group-name] festgelegt werden.
Verwenden Sie die
advertise-intervalAnweisung (für IPv4) nicht.Verwenden Sie die
inet6-advertise-intervalAnweisung (für IPv6) nicht.
Unified ISSU für VRRPv3
In Junos OS Version 15.1 werden Designänderungen für VRRP Unified In-Service Software Upgrade (ISSU) vorgenommen, um die folgenden Funktionen zu erreichen:
Behalten Sie die Protokollnachbarschaft zu Peer-Routern während einer vereinheitlichten ISSU bei. Protokolladjacance, die auf Peer-Routern für den Router erstellt wird, der eine einheitliche ISSU durchläuft, sollte nicht flattern, was bedeutet, dass VRRP auf dem Remote-Peer-Router nicht flattern sollte.
Aufrechterhaltung der Interoperabilität mit wettbewerbsfähigen oder ergänzenden Geräten.
Aufrechterhaltung der Interoperabilität mit anderen Junos OS-Versionen und anderen Juniper Netzwerkprodukten.
Die Werte der folgenden Konfigurationen (auf Hierarchieebene [edit interfaces interface-name unit 0 family inet address ip-address vrrp-group group-name] ) müssen auf Maximalwerten gehalten werden, um eine einheitliche ISSU zu unterstützen:
Auf dem primären Router muss das Ankündigungsintervall (die
fast-intervalAnweisung) bei 40950 Millisekunden gehalten werden.Auf dem Backup-Router muss das primäre Ausfallintervall (die
advertisements-thresholdAnweisung) auf dem größten Schwellenwert gehalten werden.
Dieses einheitliche VRRP-ISSU-Design funktioniert nur für VRRPv3. Es wird auf VRRPv1 oder VRRPv2 nicht unterstützt. Weitere Einschränkungen sind die folgenden:
Das VRRP Unified ISSU kümmert sich nur um VRRP. Die Paketweiterleitung liegt in der Verantwortung der Packet Forwarding Engine. Die einheitliche ISSU der Packet Forwarding Engine sollte einen unterbrechungsfreien Datenverkehrsfluss gewährleisten.
VRRP wird nicht von einem Änderungsereignis während einer vereinheitlichten ISSU beeinflusst, z. B. von der Umschaltung der primären Routing-Engine auf das Backup oder der Backup-Routing-Engine auf die primäre.
VRRP kann jeden laufenden Timer stoppen und verwerfen, bevor es in eine einheitliche ISSU eintritt. Dies bedeutet, dass die erwartete Aktion nach Ablauf des Timers nie stattfindet. Sie können jedoch die einheitliche ISSU bis zum Ablauf aller laufenden Timer zurückstellen.
Eine einheitliche ISSU an lokalen und Remote-Routern kann nicht gleichzeitig durchgeführt werden.
VRRP-Failover-Verzögerung – Übersicht
Failover ist ein Backup-Betriebsmodus, bei dem die Funktionen eines Netzwerkgeräts von einem sekundären Gerät übernommen werden, wenn das primäre Gerät aufgrund eines Fehlers oder einer geplanten Ausfallzeit nicht mehr verfügbar ist. Failover ist in der Regel ein integraler Bestandteil unternehmenskritischer Systeme, die im Netzwerk ständig verfügbar sein müssen.
VRRP unterstützt keine Sitzungssynchronisierung zwischen Mitgliedern. Wenn das primäre Gerät ausfällt, übernimmt das Sicherungsgerät mit der höchsten Priorität die Rolle des primären Geräts und beginnt mit der Weiterleitung von Paketen. Alle vorhandenen Sitzungen werden auf dem Sicherungsgerät als außerhalb des Status gelöscht.
Ein schnelles Failover erfordert eine kurze Verzögerung. Daher konfiguriert die Failover-Verzögerung die Failover-Verzögerungszeit in Millisekunden für VRRP und VRRP für IPv6-Vorgänge. Junos OS unterstützt einen Bereich von 50 bis 100000 Millisekunden für Verzögerungen bei der Failover-Zeit.
Der VRRP-Prozess (vrrpd), der auf der Routing-Engine ausgeführt wird, übermittelt für jede VRRP-Sitzung eine Änderung der primären VRRP-Rolle an die Packet Forwarding Engine. Jede VRRP-Gruppe kann eine solche Kommunikation auslösen, um die Packet Forwarding Engine mit ihrem eigenen Status oder dem von einer aktiven VRRP-Gruppe geerbten Zustand zu aktualisieren. Um eine Überlastung der Packet Forwarding Engine mit solchen Nachrichten zu vermeiden, können Sie eine Failover-Verzögerung konfigurieren, um die Verzögerung zwischen nachfolgenden Kommunikationen zwischen der Routing-Engine und der Packet Forwarding Engine anzugeben.
Die Routing-Engine übermittelt eine Änderung der primären VRRP-Rolle an die Packet Forwarding Engine, um die erforderliche Zustandsänderung auf der Packet Forwarding Engine zu erleichtern, z. B. die Neuprogrammierung von Hardwarefiltern der Packet Forwarding Engine, VRRP-Sitzungen usw. In den folgenden Abschnitten wird die Kommunikation zwischen Routing-Engine und Packet Forwarding Engine in zwei Szenarien erläutert:
Wenn die Failover-Verzögerung nicht konfiguriert ist
Ohne konfigurierte Failover-Verzögerung lautet die Ereignisabfolge für VRRP-Sitzungen, die von der Routing-Engine aus betrieben werden, wie folgt:
Wenn sich der Status der ersten von der Routing-Engine erkannten VRRP-Gruppe ändert und der neue Status primär ist, generiert die Routing-Engine entsprechende 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 sendet dann eine kostenlose ARP-Nachricht an die VRRP-Gruppen.
Die Verzögerung des Failover-Timers beginnt. Standardmäßig ist der Failover-Verzögerungs-Timer:
500 Millisekunden: Wenn das konfigurierte VRRP-Ankündigungsintervall weniger als 1 Sekunde beträgt.
2 Sekunden: Wenn das konfigurierte VRRP-Ankündigungsintervall 1 Sekunde oder mehr beträgt und die Gesamtzahl der VRRP-Gruppen auf dem Router 255 beträgt.
10 Sekunden: Wenn das konfigurierte VRRP-Ankündigungsintervall 1 Sekunde oder mehr beträgt und die Anzahl der VRRP-Gruppen auf dem Router mehr als 255 beträgt.
Die Routing-Engine führt eine Zustandsänderung nacheinander für nachfolgende VRRP-Gruppen durch. Jedes Mal, wenn sich der Status ändert und der neue Status für eine bestimmte VRRP-Gruppe primär ist, generiert die Routing-Engine entsprechende VRRP-Ankündigungsmeldungen. Die Kommunikation mit der Packet Forwarding Engine wird jedoch unterdrückt, bis der Failover-Verzögerungs-Timer abläuft.
Nach Ablauf des Failover-Delay-Timers sendet die Routing-Engine eine Nachricht an die Packet Forwarding Engine über alle VRRP-Gruppen, die es geschafft haben, den Status zu ändern. Infolgedessen 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 wiederholt, bis der Zustandsübergang für alle VRRP-Gruppen abgeschlossen ist.
So 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 ausgefü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-Ankündigungstimern und der Anzahl der VRRP-Gruppen. Während dieses Zwischenzustands kann der empfangende 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 verworfen werden.
Wenn die Failover-Verzögerung konfiguriert ist
Wenn die Failover-Verzögerung konfiguriert ist, wird die Ereignisabfolge für VRRP-Sitzungen, die von der Routing-Engine ausgeführt werden, wie folgt geändert:
Die Routing-Engine erkennt, dass einige VRRP-Gruppen eine Zustandsänderung erfordern.
Die Failover-Verzögerung beginnt für den konfigurierten Zeitraum. Der zulässige Timerbereich für die Failover-Verzögerung liegt zwischen 50 und 100000 Millisekunden.
Die Routing-Engine führt eine Zustandsänderung für die VRRP-Gruppen einzeln durch. Jedes Mal, wenn sich der Status ändert und der neue Status für eine bestimmte VRRP-Gruppe primär ist, generiert die Routing-Engine entsprechende VRRP-Ankündigungsmeldungen. Die Kommunikation mit der Packet Forwarding Engine wird jedoch unterdrückt, bis der Failover-Verzögerungs-Timer abläuft.
Nach Ablauf des Failover-Delay-Timers sendet die Routing-Engine eine Nachricht an die Packet Forwarding Engine über alle VRRP-Gruppen, die es geschafft haben, den Status zu ändern. Infolgedessen 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 wiederholt, bis der Zustandsübergang für alle VRRP-Gruppen abgeschlossen ist.
Wenn also eine Failover-Verzögerung konfiguriert ist, wird sogar der Status der Packet Forwarding Engine für die erste VRRP-Gruppe zurückgestellt. Der Netzwerkbetreiber hat jedoch den Vorteil, dass er einen Failover-Verzögerungswert konfiguriert, der den Anforderungen des Netzwerk-Bereitstellung am besten entspricht, um minimale Ausfallzeiten während der VRRP-Zustandsänderung zu gewährleisten.
Die Failover-Verzögerung beeinflusst nur VRRP-Sitzungen, die vom VRRP-Prozess (vrrpd) betrieben werden, der auf der Routing-Engine ausgeführt wird. Bei VRRP-Sitzungen, die an die Packet Forwarding Engine verteilt werden, hat die Konfiguration der Failover-Verzögerung keine Auswirkungen.
Tabellarischer Änderungsverlauf
Die Unterstützung der Funktion hängt von der Plattform und der Version ab, die Sie benutzen. Verwenden Sie den Feature-Explorer , um festzustellen, ob eine Funktion auf Ihrer Plattform unterstützt wird.