Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Aktualisieren von Software mit Nonstop-Software-Upgrade auf EX-Serie Virtual Chassis und Mixed Virtual Chassis (CLI-Verfahren)

Sie können Nonstop Software Upgrade (NSSU) verwenden, um die Software zu aktualisieren, die auf allen Mitglieds-Switches in den meisten Virtual Chassis der EX-Serie ausgeführt wird, mit minimaler Datenverkehrsunterbrechung während des Upgrades.

Nonstop Software Upgrade (NSSU) listet die Switches der EX-Serie und das Virtual Chassis auf, die NSSU unterstützen, sowie die Version von Junos OS, ab der sie es unterstützen.

Dieses Thema behandelt:

Vorbereiten des Switches für die Software-Installation

Bevor Sie mit der Softwareinstallation mit NSSU beginnen:

  • Stellen Sie sicher, dass das Virtual Chassis korrekt für die Unterstützung von NSSU konfiguriert ist. Stellen Sie Folgendes sicher:

    • Die Virtual Chassis-Elemente sind in einer Ringtopologie verbunden. Eine Ringtopologie verhindert, dass sich das Virtual Chassis während einer NSSU aufteilt.

    • Das primäre und das Backup des Virtual Chassis liegen in der Ringtopologie nebeneinander. Dank der Nachbarschaft können Primärserver und Backup immer synchron sein, auch wenn die Switches in Linecard-Rollen neu gestartet werden.

    • Das Virtual Chassis ist vorab bereitgestellt, sodass die Linecard-Rolle explizit den Mitglieds-Switches zugewiesen wurde, die in der Linecard-Rolle agieren. Während einer NSSU müssen die Virtual Chassis-Mitglieder ihre Rollen beibehalten – der primäre und der Backup-Switch müssen ihre primären und Backup-Rollen beibehalten (obwohl sich die primäre Rolle ändert), und die anderen Member-Switches müssen ihre Linecard-Rollen beibehalten.

    • Ein Virtual Chassis mit zwei Mitgliedern wurde no-split-detection so konfiguriert, dass das Virtual Chassis nicht geteilt wird, wenn eine NSSU ein Mitglied aktualisiert.

  • Stellen Sie sicher, dass auf den Mitgliedern dieselbe Version der Software ausgeführt wird:

    Wenn auf den Virtual Chassis-Mitgliedern nicht dieselbe Version der Software ausgeführt wird, verwenden Sie den request system software add Befehl, um die Software auf den inkonsistenten Mitgliedern zu aktualisieren.

  • Stellen Sie sicher, dass Nonstop Active Routing (NSR) und Graceful Routing-Engine Switchover (GRES) aktiviert sind. Um zu überprüfen, ob sie aktiviert sind, müssen Sie nur den Status des aktiven Nonstop-Routings überprüfen – wenn das aktive Nonstop-Routing aktiviert ist, ist der Graceful-Routing-Engine-Switchover aktiviert.

    So überprüfen Sie, ob Nonstop Active Routing aktiviert ist:

    Wenn Nonstop Active Routing nicht aktiviert ist (Stateful Replication ist Disabled), finden Sie Informationen zur Aktivierung unter Konfigurieren von Nonstop Active Routing on Switches .

  • Für das EX4300 Virtual Chassis sollten Sie die vcp-no-hold-time Anweisung auf der Hierarchieebene [edit virtual-chassis] aktivieren, bevor Sie ein Software-Upgrade mit NSSU durchführen. Wenn Sie die vcp-no-hold-time Anweisung nicht aktivieren, kann das Virtual Chassis während des Upgrades geteilt werden. Ein geteiltes Virtual Chassis kann zu Unterbrechungen in Ihrem Netzwerk führen, und Sie müssen Ihr Virtual Chassis nach der NSSU möglicherweise manuell neu konfigurieren, wenn die Funktion zum Teilen und Zusammenführen deaktiviert wurde. Weitere Informationen zu einem geteilten Virtual Chassis finden Sie unter Grundlegendes zum Teilen und Zusammenführen in einem Virtual Chassis.

  • (Optional) Aktivieren Sie Nonstop Bridging (NSB). Durch die Aktivierung von NSB wird sichergestellt, dass alle von NSB unterstützten Layer-2-Protokolle während des Routing-Engine-Switchovers, der Teil der NSSU ist, nahtlos funktionieren.

  • (Optional) Sichern Sie die Systemsoftware – Junos OS, die aktive Konfiguration und Protokolldateien – auf jedem Mitglied mit dem request system snapshot folgenden Befehl auf einem externen Speichergerät.

Aktualisieren der Software mit NSSU

In diesem Verfahren wird beschrieben, wie Sie die Software aktualisieren, die auf allen Virtual Chassis-Mitgliedern mithilfe von NSSU ausgeführt wird. Wenn das Upgrade abgeschlossen ist, führen alle Mitglieder die neue Version der Software aus. Da während des Upgrades ein ordnungsgemäßer Routing-Engine-Switchover erfolgt, ist das ursprüngliche Virtual Chassis-Backup das neue primäre Backup.

So aktualisieren Sie alle Mitglieder mit NSSU:

  1. Laden Sie das Softwarepaket herunter. Wenn Sie die Software aktualisieren, die auf einem gemischten Virtual Chassis ausgeführt wird, laden Sie die Softwarepakete für beide Switch-Typen herunter.

  2. Kopieren Sie das Softwarepaket oder die Softwarepakete in das Virtual Chassis. Es wird empfohlen, die Datei in das /var/tmp Verzeichnis auf dem primären Server zu kopieren.

  3. Melden Sie sich beim Virtual Chassis über die Konsolenverbindung oder die Virtual Management Ethernet (VME)-Schnittstelle an. Über eine Konsolenverbindung können Sie den Fortschritt des Neustarts des primären Switches überwachen.

  4. Starten Sie die NSSU:

    • Geben Sie in einem EX3400 Virtual Chassis Folgendes ein:

      wobei package-name.tgz z. B jinstall-ex4200-12.1R2.5-domestic-signed.tgz. . .

    • Geben Sie in einem gemischten Virtual Chassis Folgendes ein:

      Dabei [/var/tmp/package-name.tgz /var/tmp/package-name.tgz] werden die Softwarepakete EX4200 und EX4500 angegeben.

    Der Switch zeigt Statusmeldungen ähnlich den folgenden Meldungen an, während das Upgrade ausgeführt wird:

  5. Melden Sie sich an, nachdem der Neustart des ursprünglichen primären Switches abgeschlossen ist. Geben Sie den folgenden Befehl ein, um zu überprüfen, ob die Software auf allen Routing-Engines in den Virtual Chassis-Mitgliedern aktualisiert wurde:

  6. Um sicherzustellen, dass die Funktion für ausfallsichere Dual-Root-Partitionen ordnungsgemäß funktioniert, kopieren Sie das neue Junos OS-Image in die alternativen Stammpartitionen aller Mitglieder:

    Resiliente Dual-Root-Partitionen ermöglichen es dem Switch, transparent von der alternativen Root-Partition zu booten, wenn das System nicht von der primären Root-Partition booten kann.