Systems of Record in Junos Space Overview
Although by default the Junos Space network you are administering is the system of record (SOR)—each device defines its own official state—you may prefer to have the Junos Space Network Management Platform database contain the official state of the network, enabling you to restore that official state if unwanted out-of-band changes are made to a device. This feature enables you to designate Junos Space Network Management Platform as the SOR if you prefer.
Systems of Record
A network managed by Junos Space Network Management Platform contains two repositories of information about the devices in the network: the devices themselves (each device defines and reports its official state) and the Junos Space Network Management Platform database (which contains information that is reported by the device during device discovery). One of these repositories must have precedence over the other as the accepted desirable state. By default, the network itself is the system of record (NSOR).
In NSOR, when a local user commits a change in the configuration of a network device, the commit operation triggers a report via system log to Junos Space Network Management Platform. The values in the Junos Space Network Management Platform database are automatically changed to match the new device values, and the timestamps are synchronized. Thus the devices control the contents of the database.
As of version 12.2, you can designate the Junos Space Network Management Platform database values as having precedence over any values configured locally at a device. In this scenario, Junos Space Network Management Platform (database) is the system of record (SSOR). It contains the configurations that the Junos Space administrator considers best for the network devices. If an out-of-band commit operation is executed on a network device, Junos Space Network Management Platform receives a system log message, but the values in the Junos Space Network Management Platform database are not automatically changed or synchronized. Instead, the administrator can choose whether or not to overwrite the device's local changes by pushing the accepted configuration to the device from the Junos Space Network Management Platform database.
The choice of pushing the Junos Space Network Management Platform configuration is left to the administrator because the local device changes may, for example, be part of a temporary test that the administrator would not want to interrupt. However, if the tester forgets to reset the configuration at the end of the test, the administrator might then push the SSOR configuration to the device.
Implications on device management
The basic difference between NSOR and SSOR lies in whether or not the Junos Space Network Management Platform database is automatically synchronized when changes are made to a network device, and which set of values has precedence.
Setting the Junos Space Network Management Platform database as the system of record does not protect your network from local changes. The device notifies Junos Space Network Management Platform via system log when the changes occur, and it does not resynchronize, so you still have the previous configuration and you can reset the remote device quickly if you need to do so. In an NSOR scenario, Junos Space Network Management Platform is also notified via system log. You can still push a more desirable configuration to the device, but this process is less efficient.
In the NSOR scenario, you can disable automatic resynchronization. When autoresynchronozation is turned off, the server continues to receive notifications and goes into the out-of-sync state; however, autoresynchronozation does not run on the device. You can manually resynchronize a device in such a case.
NSOR with automatic resynchronization disabled is not equivalent to SSOR: manually resynchronizing under NSOR updates the values in the Junos Space Network Management Platform database to reflect those on the device. This never happens under SSOR, where the Junos Space Network Management Platform database values have precedence over the device values, and synchronizing them involves pushing the database values to the device, effectively resetting the device’s out-of-band changes.