Aktualisieren von Software mit Nonstop-Softwareupgrade für Virtual Chassis und gemischte Virtual Chassis der EX-Serie (CLI-Verfahren)
Sie können Nonstop Software Upgrade (NSSU) verwenden, um die Software, die auf allen Mitglieds-Switches in den meisten Virtual Chassis der EX-Serie ausgeführt wird, mit minimaler Unterbrechung des Datenverkehrs während des Upgrades zu aktualisieren.
NSSU wird auf den folgenden Virtual Chassis-Plattformen der EX-Serie unterstützt:
EX3300 Virtual Chassis
EX3400 Virtual Chassis
EX4200 Virtual Chassis
EX4300: Virtual Chassis
EX4500 Virtual Chassis
EX4550 Virtual Chassis
Alle gemischten Virtual Chassis bestehend aus EX4200-, EX4500- und EX4550-Switches
EX8200 Virtual Chassis
In diesem Thema werden folgende Themen behandelt:
Vorbereiten des Switches für die Softwareinstallation
Bevor Sie mit der Softwareinstallation mithilfe von NSSU beginnen:
Stellen Sie sicher, dass das Virtual Chassis ordnungsgemäß für die Unterstützung von NSSU konfiguriert ist. Vergewissern Sie sich, dass:
Die Virtual Chassis-Komponenten sind in einer Ringtopologie verbunden. Eine Ringtopologie verhindert, dass sich das Virtual Chassis während einer NSSU aufteilt.
Das primäre und das Backup-Element des Virtual Chassis liegen in der Ringtopologie nebeneinander. Die Nachbarschaft ermöglicht es, dass die Primär- und die Sicherung immer synchronisiert sind, selbst wenn die Switches in Linecardrollen neu gestartet werden.
Das Virtual Chassis ist vorab bereitgestellt, sodass die Linecard-Rolle explizit 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är- und der Backup-Switch müssen ihre Primär- und Backup-Rollen beibehalten (obwohl sich die Primärrolle ändert), und die anderen Mitglieds-Switches müssen ihre Linecard-Rollen beibehalten.
Informationen zur Konfiguration eines vorab bereitgestellten Virtual Chassis finden Sie unter Konfigurieren eines EX3300 Virtual Chassis (CLI-Verfahren), Konfigurieren eines EX4200-, EX4500- oder EX4550-Virtual Chassis (CLI-Verfahren), Konfigurieren eines EX2300-, EX3400- oder EX4300-Virtual Chassis und Konfigurieren eines EX8200 Virtual Chassis (CLI-Verfahren).
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 die Mitglieder dieselbe Version der Software ausführen:
user@switch>
show version
Wenn auf den Virtual Chassis-Mitgliedern nicht die gleiche 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 unterbrechungsfreien, aktiven Routings überprüfen – wenn das unterbrechungsfreie aktive Routing aktiviert ist, ist das ordnungsgemäße Umschalten der Routing-Engine aktiviert.
So überprüfen Sie, ob das unterbrechungsfreie aktive Routing aktiviert ist:
user@switch> show task replication Stateful Replication: Enabled RE mode: Master Protocol Synchronization Status OSPF Complete BGP Complete PIM Complete
Wenn Nonstop Active Routing nicht aktiviert ist (
Stateful Replication
isDisabled
), finden Sie weitere Informationen zur Aktivierung unter Konfigurieren von Nonstop Active Routing auf Switches .Für das EX4300 Virtual Chassis sollten Sie die Anweisung
vcp-no-hold-time
auf der Hierarchieebene [edit virtual-chassis
] aktivieren, bevor Sie ein Softwareupgrade mithilfe von NSSU durchführen. Wenn Sie dievcp-no-hold-time
Anweisung nicht aktivieren, kann sich das Virtual Chassis während des Upgrades teilen. Ein geteiltes Virtual Chassis kann zu Unterbrechungen Ihres Netzwerks führen, und Sie müssen Ihr Virtual Chassis möglicherweise nach der NSSU 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 die Protokolldateien – auf jedem Mitglied mit dem
request system snapshot
Befehl auf einem externen Speichergerät.
Aktualisieren der Software mithilfe von 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 eine ordnungsgemäße Umschaltung der Routing-Engine erfolgt, ist die ursprüngliche Virtual Chassis-Sicherung die neue primäre Sicherung.
So führen Sie ein Upgrade für alle Mitglieder durch, die NSSU verwenden:
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 Switchtypen herunter.
Kopieren Sie das/die Softwarepaket(e) in das Virtual Chassis. Es wird empfohlen, die Datei in das
/var/tmp
Verzeichnis auf dem primären Verzeichnis zu kopieren.Melden Sie sich über die Konsolenverbindung oder die Virtual Management Ethernet (VME)-Schnittstelle beim Virtual Chassis an. Wenn Sie eine Konsolenverbindung verwenden, können Sie den Fortschritt des Neustarts des primären Switches überwachen.
Starten Sie die NSSU:
Geben Sie auf einem EX3300 Virtual Chassis, EX3400 Virtual Chassis, EX4200 Virtual Chassis, EX4300 Virtual Chassis, EX4500 Virtual Chassis oder EX4550 Virtual Chassis Folgendes ein:
user@switch> request system software nonstop-upgrade /var/tmp/package-name.tgz
wobei
package-name.tgz
z. Bjinstall-ex4200-12.1R2.5-domestic-signed.tgz
. ist.Geben Sie auf einem gemischten Virtual Chassis Folgendes ein:
user@switch> request system software nonstop-upgrade set [/var/tmp/package-name.tgz /var/tmp/package-name.tgz]
wobei
[/var/tmp/package-name.tgz /var/tmp/package-name.tgz]
die Softwarepakete EX4200 und EX4500 angegeben sind.
Der Switch zeigt Statusmeldungen an, die den folgenden Meldungen ähneln, während das Upgrade ausgeführt wird:
Chassis ISSU Check Done ISSU: Validating Image ISSU: Preparing Backup RE Installing image on other FPC's along with the backup Checking pending install on fpc1 Pushing bundle to fpc1 WARNING: A reboot is required to install the software WARNING: Use the 'request system reboot' command immediately Completed install on fpc1 Checking pending install on fpc2 Pushing bundle to fpc2 WARNING: A reboot is required to install the software WARNING: Use the 'request system reboot' command immediately Completed install on fpc2 Rebooting fpc1 ISSU: Backup RE Prepare Done Waiting for Backup RE reboot GRES operational Initiating Chassis In-Service-Upgrade Chassis ISSU Started ISSU: Preparing Daemons ISSU: Daemons Ready for ISSU ISSU: Starting Upgrade for FRUs ISSU: Preparing for Switchover ISSU: Ready for Switchover Checking In-Service-Upgrade status Item Status Reason FPC 0 Online FPC 1 Online FPC 2 Online (ISSU) Going to install image on master WARNING: A reboot is required to install the software WARNING: Use the 'request system reboot' command immediately relinquish mastership ISSU: IDLE *** FINAL System shutdown message from user@switch *** System going down IMMEDIATELY Shutdown NOW! [pid 9336]
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-Modulen in den Virtual Chassis-Mitgliedern aktualisiert wurde:
user@switch>
show version
Um sicherzustellen, dass die Funktion "Ausfallsichere Dual-Root-Partitionen" ordnungsgemäß funktioniert, kopieren Sie das neue Junos OS-Image in die alternativen Root-Partitionen aller Mitglieder:
user@switch>
request system snapshot slice alternate all-members
Ausfallsichere 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.