Understanding How Junos Space Automatically Resynchronizes Managed Devices
When configuration changes are made on a physical device that Junos Space Network Management Platform manages, Junos Space Platform reacts differently depending on whether the network itself is the system of record (NSOR) or Junos Space Platform is the system of record (SSOR).
In the NSOR case, Junos Space Platform receives a system log message from the modified device and automatically resynchronizes the configuration values in its database with those of the device. This ensures that the device inventory information in the Junos Space Platform database matches the current configuration information on the device.
In the SSOR case, the Junos Space Platform receives a system log message from the modified device. The Managed Status of that device changes from In Sync to Device Changed (if the changes are made from the device CLI), Space Changed (if the changes are made from Junos Space Platform), or Space & Device Changed (if the changes are made both from the device CLI and Junos Space Platform), but no resynchronization occurs. The Junos Space Platform administrator can choose whether or not to reset the device’s configuration to match the configuration values in the Junos Space Platform database.
This topic covers:
Network as System of Record
After Junos Space Platform discovers and imports a device, if the network is the system of record, Junos Space Platform enables the auto-resynchronization feature on the device by initiating a commit operation.
After auto-resynchronization is enabled, any configuration changes made on the device, including out-of-band CLI commits and change-request updates, automatically trigger resynchronization on the device. Figure 1 shows how a commit operation resynchronizes the configuration information in the Junos Space Platform database with that on the device.
When a commit operation is performed on a managed device in NSOR mode, Junos Space Platform, by default, schedules a resynchronization job to run 20 seconds after the commit operation is received. However, if Junos Space Platform receives another commit notification within 20 seconds of the previous commit notification, no additional resynchronization jobs are scheduled because Junos Space Platform resynchronizes both commit operations in one job. This damping feature of automatic resynchronization provides a window of time during which multiple commit operations can be executed on the device, but only one or a few resynchronization jobs are required to resynchronize the Junos Space Platform database with the multiple configuration changes executed on the device.
You can change the default value of 20 seconds to any other duration by specifying the value in seconds in the Administration > Applications > Network Management Platform > Modify Application Settings > Device > Max auto resync waiting time secs field. For example, if you set the value of this field to 120 seconds, then Junos Space Platform automatically schedules a resynchronization job to run 120 seconds after the first commit operation is received. If Junos Space Platform receives any other commit notification within these 120 seconds, it resynchronizes both commit operations in one job.
For information about setting the damper interval to change the resynchronization time delay and information about disabling the auto-resynchronization feature, see Modifying Settings of Junos Space Applications.
When Junos Space Platform receives the device commit notification, the Managed Status is Out of Sync. When the resynchronization job begins on the device, the Managed Status of the device changes to Synchronizing and then In Sync after the resynchronization job has completed, unless a pending device commit operation causes the device to display Out of Sync while it was synchronizing.
When a resynchronization job is scheduled to run but another resynchronization job on the same device is in progress, Junos Space Platform delays the scheduled resynchronization job. The time delay is determined by the damper interval that you can set from the Application workspace. By default, the time delay is 20 seconds. The scheduled job is delayed as long as the other resynchronization job to the same device is in progress. When the currently running job finishes, the scheduled resynchronization job starts.
You can disable the auto-resynchronization feature in the Administration
workspace. When auto-resynchronization is turned off, the server continues
to receive notifications and goes into the Out of Sync state; however,
the auto-resynchronization feature does not run on the device. To
resynchronize a device when the auto-resynchronization feature is
disabled, use the Resynchronize with Network workflow. The auto-resynchronization
jobs are not displayed on the Job Management page. These jobs run
in the background and cannot be canceled from the Junos Space user
interface. You can view the status of the auto-resynchronization job
in the Managed Status column on the Device Management page or from
the Device Count by Synchronization State widget on the Devices page.
You can collect more information about these jobs from the
autoresync.log files in the
You can view the auto-resynchronization jobs that were scheduled to execute before upgrading to Junos Space Platform Release 15.1R1, from the Job Management page.
Junos Space as System of Record
If Junos Space Platform is the system of record, automatic resynchronization of the configuration information between the Junos Space Platform database and the managed device does not occur. When Junos Space Platform receives a system log message from the modified device, the Managed Status of the device goes from In Sync to Device Changed (if the changes are made from the device CLI), Space Changed (if the changes are made from Junos Space Platform), or Space & Device Changed (if the changes are made both from the device CLI and Junos Space Platform) and remains so unless you manually push the system of record configuration from the Junos Space Platform database to the device.