Replace the Candidate Configuration Using NETCONF

NETCONF clients can use the <copy-config> operation to replace the entire candidate configuration or all data in the open configuration database. The <target> tag encloses the <candidate/> tag. The <candidate/> tag indicates that the new configuration data replaces the data in the open configuration database (if the client application issued the Junos XML protocol <open-configuration> operation prior to executing the <copy-config> operation), or if there is no open database, the data in the candidate configuration.

The <source> element specifies the source configuration datastore. The client application can specify the following sources:

• <running/>—Copy the active configuration to the target datastore.

• <url>—Copy the configuration data in the specified file to the target datastore.

  Include the format attribute to specify the format of the configuration data as xml (default) or text.

A NETCONF client can also use the <edit-config> operation to replace the entire candidate configuration or all data in the open configuration database. The application includes the <default-operation> tag element and sets the edit configuration mode to replace as a global variable, as described in Set the Edit Configuration Mode in a NETCONF Session.

The <target> tag encloses the <candidate/> tag to indicate that the new configuration data replaces either the data in the open configuration database (if the client application issued the Junos XML protocol <open-configuration> operation prior to executing the <edit-config> operation), or if there is no open database, the data in the candidate configuration.

To specify the new configuration data, the application includes a <config> or <config-text> tag element that contains the data, or it includes a <url> tag element that specifies the file containing the data as discussed in Upload and Format Configuration Data in a NETCONF Session.

Junos devices store a copy of the most recently committed configuration and up to 49 previous configurations, depending on the platform. You can roll back to any of the stored configurations. This is useful when configuration changes cause undesirable results, and you want to revert back to a known working configuration. Rolling back the configuration is similar to the process for making configuration changes on the device, but instead of loading configuration data, you perform a rollback, which replaces the entire candidate configuration with a previously committed configuration.

Starting in Junos OS Release 18.1R1, a NETCONF application can execute the <rollback-config> RPC to replace either the candidate configuration or all data in the open configuration database with a previously committed configuration. To roll back the configuration, the application emits the <rollback-config> element with the <index> child element, which specifies the numerical index of the previous configuration to load. Valid values are 0 (zero, for the most recently committed configuration) through one less than the number of stored previous configurations (maximum is 49).

Note:

NETCONF applications can also use the Junos XML protocol <load-configuration> operation with the rollback attribute to roll back the configuration.

For example, to load the configuration with a rollback index of 1, the client application emits the following RPC:

The NETCONF server indicates that the load operation was successful by returning the <rollback-config-results> and <ok/> elements in its RPC reply.

If the load operation is successful, the client application must commit the configuration to make it the active configuration on the device. If the server encounters an error while loading the rollback configuration, it returns an <rpc-error> element with information about the error.

A rescue configuration allows you to define a known working configuration or a configuration with a known state that you can restore at any time. You use the rescue configuration when you need to revert to a known configuration or as a last resort if the device configuration and the backup configuration files become damaged beyond repair. When you create a rescue configuration, the device saves the most recently committed configuration as the rescue configuration.

Starting in Junos OS Release 18.1R1, a NETCONF application can execute the <rollback-config> RPC to replace either the candidate configuration or all data in the open configuration database with the device’s rescue configuration. To load the rescue configuration, the application emits the <rollback-config> element and <rescue/> child tag. The rescue configuration must exist on the device before you can load it.

Note:

NETCONF applications can also use the Junos XML protocol <load-configuration> operation with the rescue attribute to load the rescue configuration.

For example, to load the rescue configuration, the client application emits the following RPC:

The NETCONF server indicates that the load operation was successful by returning the <rollback-config-results> and <ok/> elements in its RPC reply.

If the load operation is successful, the client application must commit the configuration to make it the active configuration on the device. If the rescue configuration does not exist or the server encounters another error while loading the configuration data, it returns an <rpc-error> element with information about the error.