Die größten Unterschiede zwischen Junos OS Evolved und Junos OS

Systemunterschiede

Das Konzept des Systems in Junos OS Evolved unterscheidet sich von dem von Junos OS. Junos OS verwendet ein Routing-Engine-zentriertes Modell, wobei sich System normalerweise auf eine Routing-Engine bezieht. Junos OS Evolved verwendet jedoch ein knotenbasiertes Modell, bei dem sich das System auf alle Knoten bezieht, einschließlich Routing-Engines, flexible PIC-Konzentratoren (FPCs) und mehr. In Junos OS Evolved ist ein Knoten jede Komponente, die den Linux-Kernel und Junos OS Evolved-Anwendungen ausführen kann, und alle Knoten werden als Rechenknoten betrachtet.

Auswirkungen auf den Betrieb

In Junos OS Evolved können Sie viele Aktionen auf Knotenbasis ausführen. Sie können CLI-Befehle verwenden, um Informationen anzuzeigen und Vorgänge auf einzelnen Knoten anzufordern.

Relevante CLI-Befehle

• show system nodes – Zeigt eine Liste aller Knoten im System an.

• show node ( reboot | statistics ) node-name – Zeigen Sie Informationen zu einem bestimmten Knoten an.

• show system applications <node node-name> – Zeigt Anwendungsübersichtsinformationen für alle Knoten oder einen bestimmten Knoten an.

• show system core-dumps <node node-name> – Zeigt Systemkerndateien für alle Knoten oder einen bestimmten Knoten an.

• show system errors active– Verwenden Sie diesen Befehl anstelle des show chassis errors active Befehls, um Systemfehlerinformationen anzuzeigen.

• show system processes <node node-name> <detail> – Zeigt Prozessinformationen für alle Knoten oder einen bestimmten Knoten an.

• show system storage node ( re0 | re1 | fpc0 | fpc1 | ...) – Zeigen Sie den freien Speicherplatz für einen bestimmten Knoten an.

• show version node ( all | node-name ) – Zeigt Software-Versionsinformationen für alle Knoten oder einen bestimmten Knoten an.

• request node ( halt | offline | online | power-off/on | reboot ) node-name — Fordern Sie eine Operation für einen bestimmten Knoten an.

• request system reboot — In Junos OS Evolved werden mit diesem Befehl alle Knoten neu gestartet.

Softwarestruktur und Anwendungen

Junos OS Evolved fungiert als verteiltes Linux-Betriebssystem, wobei Prozesse als eigenständige Anwendungen ausgeführt werden. Jeder Junos OS Evolved-Prozess wird als Anwendung ausgeführt. Alle Junos OS Evolved-Anwendungen werden vom systemd Prozess mithilfe von Serviceeinheiten verwaltet. Anwendungen werden als separate Dienste ausgeführt, wodurch eine Fehlerisolierung gewährleistet ist, da Sie eine Anwendung separat neu starten können, ohne dass dies Auswirkungen auf andere Anwendungen hat. Die meisten Anwendungen veröffentlichen und verarbeiten einen Status, der in einer zentralen Datenbank gespeichert wird.

Auswirkungen auf den Betrieb

In Junos OS Evolved werden viele Hochverfügbarkeitsfunktionen pro Anwendung und nicht pro Knoten bereitgestellt. Einige Anwendungen führen ein Vollzeit-Backup für ein schnelles Failover aus, während andere Anwendungen im Falle eines Ausfalls auf einem neuen Knoten neu gestartet werden.

Relevante CLI-Befehle

• show system applications <node node-name> – Zeigt Anwendungsübersichtsinformationen für alle Knoten oder einen bestimmten Knoten an.

• restart process — In Junos OS startet dieser Befehl einen bestimmten Prozess neu. In Junos OS Evolved wird mit demselben Befehl eine bestimmte Anwendung (ein bestimmter Prozess) auf demselben Knoten neu gestartet, von dem der Befehl ausgegeben wird.

• request system application restart app application node node – Dieser Befehl ist spezifisch für Junos OS Evolved und startet eine bestimmte Anwendung auf einem bestimmten Knoten neu.

Zustandsmodell

Junos OS Evolved nutzt eine verteilte Zustandsinfrastruktur. Anwendungen veröffentlichen oder abonnieren Zustandsobjekte, die in einer Zustandsdatenbank namens Distributed Data Store (DDS) gespeichert werden, die auf Knoten verteilt ist. Im Vergleich dazu speichern Junos OS-Prozesse den Status intern und tauschen Zustandsinformationen und Statusänderungen mit anderen Prozessen über den Kernel aus. Das Junos OS Evolved-Zustandsmodell ist asynchron und schließlich konsistent auf der Transportschicht mit kausaler Konsistenz auf der Anwendungsebene beim Zugriff auf den Status. Das bedeutet, dass beim Neustart eines Prozesses in Junos OS Evolved keine Informationen verloren gehen, da er Statusinformationen aus dem DDS abrufen kann.

Auswirkungen auf den Betrieb

Das Junos OS Evolved-Zustandsmodell sorgt für eine schnellere Leistung, da Sie nicht warten müssen, bis die langsamste Komponente aktualisiert wird. Anwendungen lesen aus dem Systemstatus und schreiben in den Systemstatus, ohne auf jeden anderen Prozess zu warten, um zuerst die Aktualisierungen abzuschließen. Wenn eine Anwendung neu gestartet wird, wird der Zustand beibehalten und von der neuen Instanz aus dem DDS abgerufen, auch wenn die Anwendung auf einem anderen Knoten erzeugt wird.

Softwaremanagement

Jedes Mal, wenn Sie ein Software-Image auf Junos OS Evolved installieren, werden das vorherige Software-Image und die vorherige Konfiguration automatisch beibehalten. Junos OS Evolved speichert Software-Images im Verzeichnis /soft . Jede Version der Software wird in einem eigenen Bereich gespeichert, wodurch sichergestellt wird, dass die Installation eines Softwarepakets keine Auswirkungen auf die anderen auf dem System installierten Softwareversionen hat. Während Junos OS die Installation von zwei Softwareversionen auf dem Gerät unterstützt, unterstützt Junos OS Evolved das Speichern so vieler Software-Images, wie der Speicherplatz zulässt. Es wird jedoch empfohlen, nicht mehr als fünf Softwareversionen auf dem System zu behalten.

Bei einer erfolgreichen Installation installiert das Installationspaket die vorhandene Software vollständig neu. Konfigurationsdateien und ähnliche Informationen, z. B. Secure Shell und Hostschlüssel, aus der vorherigen Version werden beibehalten. Wenn Sie das System nach der Installation eines Softwarepakets neu starten, führen alle Routing-Engines und FPCs im System die neue Version der Software aus.

Auswirkungen auf den Betrieb

Junos OS Evolved stellt sicher, dass auf allen Routing-Engines und FPCs im System dieselbe Softwareversion ausgeführt wird. Wenn Sie ein Softwareabbild auf der primären Routing-Engine installieren, installiert das System die neue Softwareversion auf beiden Routing-Modulen, wenn die Routing-Module online und Teil des Systems sind. Wenn Sie eine Routing-Engine mit einer anderen Softwareversion in das System einfügen und die system auto-sw-sync enable Anweisung nicht konfiguriert haben, wird die Routing-Engine außerhalb des Systems gehalten, und das System generiert einen Alarm für Softwarekonflikte.

Wenn Sie ein neues Softwareabbild installieren, wird das vorherige Softwarepaket in einem separaten Bereich beibehalten, und Sie können bei Bedarf manuell zu diesem Paket zurückkehren. Mit Junos OS Evolved können Sie zu einem alternativen Image zurückkehren, das entweder die aktuelle Konfigurationsdatei oder den Konfigurations-Snapshot von dem Zeitpunkt enthält, als das alternative Image zuletzt ausgeführt wurde.

Relevante CLI-Befehle

• show system software list – Zeigen Sie unter Junos OS Evolved die aktuell installierten Images auf jedem Knoten an.

• show system storage — Zeigen Sie den verfügbaren Speicherplatz an. Unter Junos OS Evolved müssen die Verzeichnisse /soft, /var und /data eine Kapazität von weniger als 90 % aufweisen, um zusätzliche Images zu installieren.

• request system software delete — Bereinigen Sie alte Bilder. Verwenden Sie ab Junos OS Evolved Version 20.1R1 diesen Befehl anstelle des Befehls, um request system storage cleanup ISO-Images aus dem System zu entfernen.

• request system snapshot — Erstellen Sie einen Snapshot der Dateien, die derzeit zum Ausführen des Geräts verwendet werden, und kopieren Sie die Dateien auf das alternative Solid-State-Drive (SSD). Der Snapshot enthält den vollständigen Inhalt der Verzeichnisse /soft, /config und /root , Kopien der Benutzerdaten und Inhalte aus dem Verzeichnis /var (mit Ausnahme der Verzeichnisse /var/core, /var/external, /var/log und /var/tmp ).

• request system software rollback reboot <package-name> <with-old-snapshot-config> – Setzen Sie alle Routing-Engines und FPCs auf eine andere Softwareversion zurück und starten Sie sie neu. Schließen Sie die with-old-snapshot-config Option ein, die gespeicherte Konfiguration zu verwenden, die dem Rollback-Software-Image entspricht.

• request system software sync ( all-versions | current | rollback ) — Synchronisieren Sie Software und Konfigurationen von der primären Routing-Engine mit den anderen Knoten und starten Sie die anderen Knoten neu.

• set system auto-sw-sync enable – Synchronisieren Sie die Software und die Konfiguration automatisch von der primären Routing-Engine mit einer neu hinzugefügten Routing-Engine und starten Sie sie neu, wenn die neu hinzugefügte Routing-Engine eine andere Softwareversion als der Rest des Systems hat.

Verwaltungsschnittstellen

Unter Junos OS Evolved werden Verwaltungsschnittstellen umbenannt, um mehr als einen Management-Port pro Routing-Engine-Knoten unterzubringen.

Auswirkungen auf den Betrieb

Verwaltungsschnittstellen in Junos OS Evolved haben nicht die gleichen Namen wie Junos OS (fxp0, em0me0, ). Stattdessen lautet device-namedas Namensformat der Junos OS Evolved-Verwaltungsschnittstelle :type-port. Zum Beispiel: re0:mgmt-0, re0:mgmt-1, re1:mgmt-0, re1:mgmt-1, .

Die show interfaces Ausgabe zeigt den Status aller Schnittstellen an, einschließlich Management-Ethernet-Schnittstellen von beiden Routing-Engines eines dualen Routing-Engine-Systems.

System-Hostnamen

In Junos OS Evolved wird an Systemhostnamen eine entsprechende Routing-Engine-Nummer angehängt, z. B -re0 . oder -re1.

Auswirkungen auf den Betrieb

Wenn Sie in Junos OS Evolved die host-name Anweisung angeben, wird der aktuelle Name der Routing-Engine an den hostname von Ihnen angegebenen angehängt. Legt z. B. auf Routing-Engine 0 set system host-name my-host den Hostnamen auf my-host-re0. Sie können das %s Zeichen auch verwenden, um anzugeben, wo der Name der Routing-Engine ersetzt werden soll. Legen Sie z. B. in Routing-Engine 1 set system host-name %s_my_host den Hostnamen auf re1_my-host .

Relevante CLI-Befehle

• set system host-name hostname

Routing-Engine Firewall-Filter

Um in Junos OS den Fluss lokaler Pakete zwischen den physischen Schnittstellen und der Routing-Engine zu steuern, können Sie zustandslose Firewall-Filter auf den Eingang oder Ausgang der Loopback-Schnittstelle anwenden. Die Loopback-Schnittstelle (lo0) ist die Schnittstelle zur Routing-Engine und überträgt keine Datenpakete. In Junos OS gelten die auf die Loopback-Schnittstelle angewendeten Filter sowohl für den Netzwerksteuerungsdatenverkehr als auch für den Verwaltungsdatenverkehr.

Junos OS Evolved hingegen unterstützt zwei verschiedene Filter zur Steuerung des Flusses lokaler Pakete: einen für den Netzwerksteuerungsdatenverkehr (Loopback-Datenverkehr) und einen für den Verwaltungsdatenverkehr. Daher gelten Filter, die auf die Loopbackschnittstelle angewendet werden, nur für den Datenverkehr der Netzwerksteuerung. Sie können Filter auch separat auf die Verwaltungsschnittstelle anwenden, wodurch Sie einen strengeren Filter für den Verwaltungsdatenverkehr konfigurieren können.

Auswirkungen auf den Betrieb

In Junos OS Evolved gelten Firewall-Filter, die auf die Loopback-Schnittstelle angewendet werden, nur für den Datenverkehr der Netzwerksteuerung. Sie müssen Firewallfilter explizit auf die Verwaltungsschnittstelle anwenden, um den Verwaltungsdatenverkehr zu filtern. In Junos OS Evolved verwendet die Verwaltungsfilterung Routing-Engine-Filter, die auf Netfilter basieren, einem Framework, das der Linux-Kernel bereitstellt. Daher werden nur bestimmte Übereinstimmungen und Aktionen unterstützt. Tabelle 1 beschreibt die Junos OS Evolved-Filteranwendung.

Junos OS weiterentwickelter Netzwerk-Stack

Junos OS Evolved läuft auf nativem Linux. Es gibt einige Unterschiede zwischen der Art und Weise, wie Linux angeforderte Netzwerktopologieinformationen, wie Schnittstellen- und Routendaten, anzeigt, und der Art und Weise, wie Junos OS diese Informationen anzeigt. Die Junos OS Evolved CLI wurde entwickelt, um diese Unterschiede zu überwinden. Daher empfehlen wir, für alle Netzwerkvorgänge CLI-Befehle anstelle von Shell-Befehlen zu verwenden, insbesondere für Vorgänge, die die Angabe einer Routing-Instanz erfordern.

Wenn Sie bei der Verwendung von Junos OS Evolved Vorgänge in der Linux-Shell ausführen müssen, müssen Sie die folgenden Routing-Instanzen kennen, die auch als virtuelle Routing- und Weiterleitungsinstanzen (VRFs) bezeichnet werden:

• default– Verarbeitet standardmäßig sowohl WAN- als auch Management-Datenverkehr, es sei denn, Sie konfigurieren die mgmt_junos Routing-Instanz.
• mgmt_junosWenn Sie diese Routing-Instanz konfigurieren, legt sie den Management-Port in einer eigenen Routing-Instanz ab, die den Management-Datenverkehr vom WAN-Datenverkehr für die Routing-Engine trennt.

• iri– Verarbeitet den Datenverkehr der Steuerungsebene (Kommunikation zwischen den Knoten). In der Junos OS Evolved CLI entspricht dies der __juniper_private1__ Routing-Instanz.

Auswirkungen auf den Betrieb

In der Junos OS Evolved-Shell können Sie das chvrf Dienstprogramm (VRF ändern) verwenden, um einen Befehl im Kontext einer bestimmten Routing-Instanz oder VRF auszuführen. Zum Beispiel:

Systemprotokollierung

In Junos OS Evolved verfügt jeder Knoten über das Standardwerkzeug journalctl , d. h. über eine Schnittstelle zum Abrufen und Filtern des Systemjournals. Systemprotokollmeldungen werden aus dem Systemjournal analysiert. Der relay-eventd Prozess läuft auf allen Knoten und ruft Ereignisse (basierend auf der Syslog-Konfiguration) aus dem Systemjournal sowie Fehlermeldungen aus den verschiedenen Anwendungen ab und leitet sie an den master-eventd Prozess weiter. Der master-eventd Prozess wird auf der primären Routing-Engine ausgeführt und schreibt die Protokollmeldungen und Fehler auf die Festplatte.

Verwenden Sie die Anwendung Systemprotokoll-Explorer , um Systemprotokollmeldungen in verschiedenen Versionen anzuzeigen oder zu vergleichen.

Auswirkungen auf den Betrieb

In Junos OS Evolved gibt es keine messages Datei auf der Backup-Routing-Engine. Alle Sicherungsprotokolle der Routing-Engine befinden sich in der messages Datei auf dem primären Knoten der Routing-Engine.

Format der Systemprotokollmeldung

Standardmäßig hängt Junos OS Evolved den Knotennamen an den Hostnamen in Systemprotokollmeldungen an. Bei Junos OS ist dies nicht der Fall. Auf diese Weise werden Junos OS Evolved-Systemprotokollmeldungen mit RFC5424 konform gehalten. Einige Überwachungssysteme identifizieren einen Junos OS Evolved-Hostnamen möglicherweise nicht korrekt, weil die Kombination aus Hostname und Knotenname mit keinem Hostnamen im Bestand der Hostnamen übereinstimmt.

Auswirkungen auf den Betrieb

Wenn Ihr Überwachungssystem die Hostnamen von Junos OS Evolved nicht korrekt identifiziert, sollten Sie den set system syslog alternate-format Befehl configuration mode ausführen. Mit diesem Befehl wird das Format der Systemprotokollmeldungen von Junos OS Evolved geändert. Der Knotenname wird dem Prozessnamen in der Nachricht vorangestellt und nicht an den Hostnamen angehängt, sodass das Überwachungssystem den Hostnamen korrekt identifizieren kann.

Tracing-Architektur

Junos OS Evolved verwendet eine neue Tracing-Architektur. Alle ausgeführten Anwendungen erstellen Ablaufverfolgungsinformationen, wobei mehrere Instanzen derselben Anwendung über ihre eigenen Ablaufverfolgungsinformationen verfügen. Junos OS Evolved trace-relay und trace-writer Anwendungen koordinieren Ablaufverfolgungsinformationen. Die trace-relay Anwendung wird auf lokalen Knoten ausgeführt und teilt sich mit jeder Anwendung einen Speicherpuffer. Wenn eine Junos OS Evolved-Anwendung in den Arbeitsspeicher schreibt, liest die trace-relay Anwendung die Daten direkt aus dem Arbeitsspeicher und sendet sie an die trace-writer Anwendungen. Auf jedem Routing-Engine-Knoten wird eine trace-writer Anwendung ausgeführt. Er empfängt die von den trace-relay Anwendungen gesendeten Ablaufverfolgungsinformationen und schreibt sie im Common Trace Format (CTF) in die entsprechende Datei.

Auswirkungen auf den Betrieb

In Junos OS aktivieren Sie Ablaufverfolgungsvorgänge, indem Sie die traceoptions Anweisung auf der spezifischen Hierarchieebene konfigurieren, die Sie verfolgen möchten. Junos OS Evolved hingegen verwendet ein anwendungsbasiertes Modell, sodass Ablaufverfolgungsmeldungen nach Anwendung protokolliert, angezeigt und konfiguriert werden. Daher unterstützt Junos OS Evolved die traceoptions Anweisung auf vielen der von Junos OS unterstützten Hierarchieebenen nicht. Einige Hierarchieebenen, z. B. die unter [edit protocols]erfordern jedoch weiterhin die Konfiguration der Anweisung, um Ablaufverfolgungsmeldungen traceoptions zu aktivieren.

Obwohl Junos OS globale Ablaufverfolgungsvorgänge für viele Hierarchieebenen standardmäßig deaktiviert, protokollieren einige Prozesse standardmäßig Ablaufverfolgungsmeldungen für wichtige Ereignisse. Im Gegensatz dazu erstellen alle auf Junos OS Evolved ausgeführten Anwendungen standardmäßig Trace-Informationen auf dieser info Ebene.

In Junos OS Evolved werden Ablaufverfolgungsdateien nicht direkt angezeigt, und Sie sollten niemals Ablaufverfolgungsdateien im Verzeichnis /var/log/traces hinzufügen, bearbeiten oder entfernen, da dies die Ablaufverfolgungen beschädigen kann. Stattdessen verwenden Sie den Befehl zum Lesen und Decodieren von show trace application application-name node node-name Ablaufverfolgungsmeldungen, die in den Ablaufverfolgungsdateien gespeichert sind.

Relevante CLI-Befehle

• show trace application application-name node node-name — Lesen und Dekodieren von Trace-Dateien.

• clear trace – Manuelles Bereinigen von Trace-Dateien.

• set system trace application – Ändern Sie die Konfigurationen von Trace-Meldungen auf Anwendungsebene.