Einheitliche ISSU in einem Virtual Chassis

Vorteile einer einheitlichen ISSU in einem Virtual Chassis

Die Ausführung einer einheitlichen ISSU in einem Virtual Chassis der MX-Serie bietet die folgenden Vorteile:

• Aktualisiert das Junos OS-Softwarepaket bei gleichzeitiger Aufrechterhaltung von Abonnentensitzungen.

• Reduziert das Risiko, das mit einem Software-Upgrade verbunden ist. Nach einer einheitlichen ISSU ist das resultierende System genau so, als ob Sie es mit einem Systemneustart aktualisiert hätten.

• Verhindert, dass Software-Upgrades die Fähigkeit des ServiceAnbieters beeinträchtigen, strenge SlAs (Service Level Agreements) zu erfüllen.

• Eliminiert Netzwerkausfallzeiten bei Software-Image-Upgrades.

• Ermöglicht eine schnellere Implementierung neuer Junos OS-Funktionen.

• Bietet Funktionsgleichheit mit einheitlicher ISSU-Unterstützung auf eigenständigen Routern der MX-Serie.

Voraussetzungen für die Ausführung einer einheitlichen ISSU in einem Virtual Chassis

Bevor Sie eine einheitliche ISSU in einem zweiköpfigen Virtual Chassis der MX-Serie starten, stellen Sie sicher, dass Sie alle folgenden Schritte ausführen:

• Stellen Sie sicher, dass auf allen vier Routing-Engines im Virtual Chassis (sowohl Routing-Engines im primären Router als auch beide Routing-Engines im Backup-Router) dieselbe Junos OS-Softwareversion ausgeführt wird.

• Sichern Sie die vorhandene Routerkonfiguration, sodass Sie sie bei Bedarf zurücksetzen (zurücksetzen) können.

• Stellen Sie sicher, dass sowohl GRES (Graceful Routing Engine Switchover) als auch Nonstop Active Routing (NSR) aktiviert sind.

Funktionsweise von Unified ISSU in einem Virtual Chassis

Um eine einheitliche ISSU in einem Virtual Chassis der MX-Serie durchzuführen, erteilen Sie den request system software in-service-upgrade package-name Befehl aus dem Konsolenfenster für die primäre Routing-Engine im virtual Chassis Primary Router (VC-Pp). Die Ausgabe dieses Befehls vom VC-Pp kopiert das Softwarepaket auf alle anderen Routing-Engines im Virtual Chassis.

Der request system software in-service-upgrade package-name Befehl funktioniert für Upgrades von Mitgliedsroutern in einer Virtual Chassis-Konfiguration genauso wie für ein Upgrade eines eigenständigen Routers der MX-Serie mit zwei Routing-Engines, wobei die folgenden Ausnahmen gelten:

• Die no-copyOptionen no-old-master-upgradefür unlink den Befehl sind für Virtual Chassis der request system software in-service-upgrade MX-Serie nicht verfügbar.

• Die reboot Option für den request system software in-service-upgrade Befehl wird akzeptiert, aber für ein Virtual Chassis der MX-Serie ignoriert. Ein einheitliches ISSU startet immer alle Routing-Engines in den Virtual Chassis-Routern neu.

Auf hoher Ebene führt die Software die folgenden Aktionen aus, nachdem Sie den request system software in-service-upgrade package-name Befehl zum Upgrade auf eine neue Junos OS-Softwareversion in einer zweiköpfigen Virtual Chassis-Konfiguration erhalten haben:

1. Unterstützt die neue Junos OS-Softwareversion auf allen Routing-Engines im Virtual Chassis.

   Auf den Routing-Engines wird noch die alte Softwareversion junos OS ausgeführt.

2. Aktualisiert sowohl Standby-Routing-Engines (Backup) (VC-Ps und VC-Bs) im Virtual Chassis.

   Das Virtual Chassis leitet den Datenverkehr immer noch aktiv weiter.

3. Führt einen lokalen Switchover der Routing-Engines im Virtual Chassis Backup-Router (VC-B) durch.

   Der lokale Switchover bewirkt, dass die VC-Bs in Schritt 2 zu VC-Bp aktualisiert wurden, und der VC-Bp, auf dem noch die alte Junos OS-Software ausgeführt wurde, wurde zu VC-Bs. Auf VC-Bp wird jetzt die neue Junos OS-Softwareversion ausgeführt, und auf dem VC-Bs wird immer noch die alte Junos OS-Softwareversion ausgeführt. Das Virtual Chassis leitet den Datenverkehr immer noch aktiv weiter.

4. Aktualisiert die Packet Forwarding Engines auf die neue Junos OS-Softwareversion.

   Die Packet Forwarding Engines verwenden jetzt den aktualisierten VC-Bp als primäres Virtual Chassis-Protokoll.

5. Führt einen lokalen Switchover der Routing-Engines im primären Virtual Chassis-Router (VC-P) durch.

   Der lokale Switchover des VC-P bewirkt auch einen globalen Switchover im Virtual Chassis, wodurch der VC-P zum VC-B wird. Infolgedessen wird der VC-Pp zum VC-Bs und aus dem VC-Ps zum VC-Bp. Die globale Umstellung auf den VC-B bewirkt, dass VC-Bp zum VC-Pp und aus VC-Bs zum VC-Ps wird.

   VC-Pp und VC-Bp führen jetzt die neue Junos OS-Softwareversion aus. Auf VC-Ps (ursprünglich VC-Bp) und VC-Bs (ursprünglich VC-Pp) wird noch die alte Junos OS-Softwareversion ausgeführt.

6. Aktualisiert die Standby-Routing-Engines im Virtual Chassis (VC-Ps und VC-Bs).

   Virtual Chassis ist jetzt vollständig auf die neue Junos OS-Softwareversion aktualisiert.

Virtual Chassis-Rollenübergänge nach einer einheitlichen ISSU

Ein einheitliches ISSU in einem Virtual Chassis der MX-Serie aktualisiert alle Routing-Engines im Virtual Chassis auf die neue Junos OS-Softwareversion. In einem zweiköpfigen Virtual Chassis umfasst dies vier Routing-Engines: die primären und Standby-Routing-Engines (Backup) im primären Virtual Chassis-Router und die primären und Standby-Routing-Engines im Virtual Chassis-Backup-Router. Infolgedessen werden die Mitgliedsrouter und die zugehörigen Routing-Engines nach Abschluss der einheitlichen ISSU sowohl globalen als auch lokalen Rollenwechseln unterzogen.

Ein globaler Rollenübergang ändert die primäre Rolle im Virtual Chassis, indem die globalen Rollen des primären Virtual Chassis-Routers (VC-P) und des Virtual Chassis Backup-Routers (VC-B) gewechselt werden. Dies gilt weltweit für das gesamte Virtual Chassis. Bei einem Übergang zur lokalen Rolle werden die lokalen Primär- und Backup-Rollen (master und standby, oder und m s) jeder der beiden Routing-Engines in einem Mitgliedsrouter umgestellt und gilt lokal nur für diesen Mitgliedsrouter.

Ein einheitliches ISSU in einem Virtual Chassis der MX-Serie verursacht die in Tabelle 1 aufgeführten globalen und lokalen Rollenübergänge.