Anzeigen der Konfigurationsrevisionskennung zum Bestimmen des Synchronisierungsstatus von Geräten mit NMS
Der Configuration Revision Identifier (CRI) ist eine eindeutige Zeichenfolge, die einer festgeschriebenen Konfiguration zugeordnet ist. NMS-Anwendungen (Network Management System), wie z. B. Junos Space, können die CRI verwenden, um zu erkennen, ob andere Systeme Out-of-Band-Konfigurationsänderungen am Netzwerkgerät vorgenommen haben. Out-of-Band-Konfigurationsänderungen sind Konfigurationsänderungen, die an einem Gerät außerhalb des NMS vorgenommen werden. Sie können beispielsweise Konfigurationsänderungen an einem Gerät über die CLI, die J-Web-Schnittstelle oder den Konfigurationseditor der Junos Space Network Management Platform durchführen.
Die NMS-Anwendung kann den CRI für einen bestimmten Commit zwischenspeichern. Zu einem späteren Zeitpunkt kann das NMS den zwischengespeicherten Wert mit dem CRI der aktuellen Konfiguration auf dem Netzwerkgerät vergleichen, um zu erkennen, ob andere Systeme Out-of-Band-Konfigurationsänderungen am Gerät vorgenommen haben. Die Überwachung des CRI ist möglicherweise nicht erforderlich, wenn die NMS-Anwendung das einzige Dienstprogramm ist, das die Gerätekonfiguration ändert. In einer realen Netzwerkbereitstellung können jedoch Out-of-Band-Konfigurationscommits auf einem Gerät auftreten, z. B. während eines Wartungsfensters für Supportvorgänge. In solchen Fällen erkennt die NMS-Anwendung diese Out-of-Band-Commits möglicherweise nicht.
Ab Junos OS Version 16.1 enthält das <commit-results> Tag nach einem erfolgreichen Commit ein <commit-revision-information> Tag. Das <commit-revision-information> Tag enthält die vorherige Revisionsnummer und die aktualisierte Revisionsnummer. Die NMS-Anwendung kann diese Revisionsnummer lokal speichern. Zu einem späteren Zeitpunkt kann die NMS-Anwendung die neueste Revisionsnummer vom Netzwerkgerät abrufen und mit der lokal gespeicherten Revisionsnummer vergleichen, um zu überprüfen, ob sie nicht synchron oder insynchron mit dem Gerät ist.
Die folgende Beispiel-RPC-Antwort enthält das Tag, das <commit-revision-information> die Details zur Commit-Revision enthält:
<rpc-reply xmlns:junos="http://xml.juniper.net/junos/15.1R1/junos">
<commit-results>
<routing-engine>
<name>re0</name>
<commit-success/>
<commit-revision-information>
<old-db-revision>re0-1446493106-63</old-db-revision>
<new-db-revision>re0-1446493220-64</new-db-revision>
</commit-revision-information>
</routing-engine>
</commit-results>
</rpc-reply>
Der Konfigurationsrevisionsbezeichner ist eine Zeichenfolge im folgenden Format:
<routing-engine-name>-<timestamp>-<counter>
Verschiedene Plattformen enthalten unterschiedliche Routing-Engine-Namen, z. B.:
-
Dual-Routing-Engines von Routern der MX-Serie – re0, re1
-
Chassis-Cluster der SRX-Serie – node0, node1, node2 usw.
-
Virtuelles Chassis der MX-Serie: member0-re0, member0-re1, member1-re0 usw.
-
Virtuelles Chassis der EX-Serie – fpc0, fpc1 usw.
Der Name der Routing-Engine unterscheidet sich vom vom Benutzer konfigurierten Hostnamen des Geräts. Der Name der Routing-Engine wird verwendet, um die Quelle der Konfigurationsänderung zu identifizieren. Der Zeitstempel der Revisionsnummer wird im Unix-Epochenformat (auch bekannt als Unix-Zeit oder POSIX-Zeit) angezeigt. Der Zählerindex wird für jeden Commitvorgang um eins erhöht. Die NMS-Anwendung betrachtet die Konfigurationsrevisions-ID als eine ganze Zeichenfolge und analysiert einzelne Teilzeichenfolgen dieser Revisions-ID nicht.
Darüber hinaus kann eine Anwendung ab Junos OS und Junos OS Evolved Version 20.4R1 die CRI verwenden, die einer festgeschriebenen Konfiguration zugeordnet ist, um:
-
Zeigen Sie die Konfiguration an.
-
Vergleichen Sie zwei Konfigurationen.
-
Kehren Sie zur Konfiguration zurück.
-
Rufen Sie den aktuellen Rollback-Index ab, der dieser Konfiguration zugeordnet ist.