View the Configuration Revision Identifier for Determining Synchronization Status of Devices with NMS
The configuration revision identifier (CRI) is a unique string that is associated with a committed configuration. Network management system (NMS) applications, such as Junos Space, can use the CRI to detect if other systems made out-of-band configuration changes to the network device. Out-of-band configuration changes are configuration changes made to a device outside of the NMS. For example, you can perform configuration changes on a device using the CLI, the J-Web interface, or the Junos Space Network Management Platform configuration editor.
The NMS application can cache the CRI for a given commit. At a later date, the NMS can compare the cached value to the CRI of the current configuration on the network device to detect if other systems made out-of-band configuration changes to the device. Monitoring the CRI might not be necessary if the NMS application is the only utility that modifies the device configuration. However, in a real-world network deployment, out-of-band configuration commits might occur on a device, such as during a maintenance window for support operations. In such cases, the NMS application might not detect these out-of-band commits.
Starting in Junos OS Release 16.1, after a successful commit, the
<commit-results>
tag includes a
<commit-revision-information>
tag. The
<commit-revision-information>
tag includes the previous
revision number and updated revision number. The NMS application can store this
revision number locally. At a later time, the NMS application can retrieve the
latest revision number from the network device and compare it against the revision
number stored locally to validate whether it is out-of-sync or in-sync with the
device.
The following example RPC reply includes the
<commit-revision-information>
tag containing the commit
revision details:
<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>
The configuration revision identifier is a string, which has the following format:
<routing-engine-name>-<timestamp>-<counter>
Different platforms contain different Routing Engine names, for example:
-
Dual Routing Engines of MX Series routers—re0, re1
-
SRX Series Chassis Cluster—node0, node1, node2, and so on
-
MX Series Virtual Chassis—member0-re0, member0-re1, member1-re0, and so on
-
EX Series Virtual Chassis—fpc0, fpc1, and so on
The Routing Engine name is different from the user-configured hostname of the device. The Routing Engine name is used to identify the source of the configuration change. The revision number's timestamp is displayed in the Unix epoch format (also known as Unix time or POSIX time). The counter index increments by one for every commit operation. The NMS application considers the configuration revision identifier as an entire string and does not parse individual substrings of this revision identifier.
Additionally, starting in Junos OS and Junos OS Evolved Release 20.4R1, an application can use the CRI associated with a committed configuration to:
-
View the configuration.
-
Compare two configurations.
-
Revert to the configuration.
-
Retrieve the current rollback index associated with that configuration.