Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?


Viewing the Configuration Revision Identifier for Determining Synchronization Status of Devices with NMS

Out-of-band configuration changes are configuration changes made to a device outside of the network management server (NMS) application, such as Junos Space. For example, configuration changes can be performed on a device using the device CLI, using the device Web-based management interface (the J-Web interface or Web View), or using the Junos Space Network Management Platform configuration editor. As a result, there is a requirement for a configuration revision identifier to determine whether the configuration settings on devices being managed by an NMS application are in sync with the CLI of devices running Junos OS.

A configuration revision identifier might not be necessary if the NMS application is the only utility that is used to modify the configuration of a device. 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. To solve this problem, starting in Junos OS Release 16.1, a configuration revision identifier tag, <commit-revision-information>, is supported within the <commit-results> tag. The configuration revision identifier is a string (for example, re0-1365168149-1), which has the following format:

Different platforms contain different Routing Engine names as follows:

  • 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 device that has performed the configuration change on a device. When the revision number is computed, the time is displayed in the Unix epoch format (also known as Unix time or POSIX time). The counter increments by one for every commit operation performed. The NMS application considers the configuration revision identifier as an entire string and does not parse individual substrings of this revision identifier.

On every successful commit, in addition to the commit-success message, Junos OS also returns the old revision number and updated revision number. The NMS application can store this revision locally. The NMS application can query Junos OS to retrieve the latest revision number and compare it against the revision number stored locally to validate whether it is out-of-sync or in-sync with the device. The NETCONF remote procedure calls (RPCs) and the CLI (show system commit revision detail) are used to query Junos OS for the revision string.

The following is an example of the RPC reply that contains the commit revision details with the new <commit-revision-information> tag included: