Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

Replacing the Candidate Configuration Using NETCONF

 

In a NETCONF session with a device running Junos OS, a client application can replace the entire candidate configuration or all data in the open configuration database, either with new data or by rolling back to a previous configuration or a rescue configuration.

Note

If a client application issues the Junos XML protocol <open-configuration> operation to open a specific configuration database before loading the configuration data, Junos OS performs the requested operation on the open configuration database. Otherwise, the operation is performed on the candidate configuration.

The following sections discuss how to replace configuration data in the candidate configuration or open configuration database. The client application must commit the configuration after replacing the data to make it the active configuration on the device.

Using <copy-config> to Replace the Configuration

One method for replacing the entire candidate configuration or all data in the open configuration database is to use the <copy-config> operation. 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 <copy-config> operation), or if there is no open database, the data in the candidate configuration.

The <source> element encloses the <url> element, which specifies the filename that contains the new configuration data. When the configuration data is formatted as Junos XML tag elements, set the <url> format attribute to xml or omit the attribute. When the configuration data is formatted as CLI configuration statements, set the <url> format attribute to text.

Using <edit-config> to Replace the Configuration

Another method for replacing the entire candidate configuration or all data in the open configuration database is to use the <edit-config> operation and set the edit configuration mode to replace as a global variable. The application includes the <default-operation> tag element with the value replace in the <edit-config> tag element, as described in Setting 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 names the file containing the data as discussed in Uploading and Formatting Configuration Data in a NETCONF Session.

Rolling Back to a Previously Committed Configuration

Devices running Junos OS 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.

Replacing the Candidate Configuration with the Rescue Configuration

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.