Replace the Configuration Using the Junos XML Protocol

A client application can replace all configuration data in the candidate configuration or open configuration database with new configuration data. To replace the configuration, a client application executes the <load-configuration> operation and includes the action="override" attribute. If a client application issues the <open-configuration> operation to open a specific configuration database before executing the <load-configuration> operation, the server loads the configuration data into the open configuration database. Otherwise, the server loads the configuration data into the candidate configuration.

For more information about the url and format attributes and the syntax for the new configuration data, see Upload and Format Configuration Data in a Junos XML Protocol Session.

The following example replaces the entire candidate configuration with the contents of the file /tmp/conf.xml. The file contains Junos XML tag elements (the default), so this request omits the format attribute.

Client Application

Junos XML Protocol Server

Junos OS and Junos OS Evolved 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. Rolling back the configuration is useful when configuration changes cause undesirable results, and you want to revert to a known working configuration. The process is similar to making configuration changes on a device, but instead of loading configuration data, you perform a rollback. The rollback replaces the entire candidate configuration with a previously committed configuration.

When you successfully commit a configuration, Junos OS assigns that configuration a unique configuration revision identifier. The configuration is also associated with a rollback index, where the most recently committed configuration has rollback index 0. Whereas the rollback index for a previously committed configuration increments with each commit, the configuration revision ID remains static for the same configuration. When you roll back to a previously committed configuration, you can reference the configuration by its current rollback index or its configuration revision ID.

To display the rollback index and configuration revision ID for previously committed configurations, issue the show system commit include-configuration-revision operational mode command. For example, the following output displays four commits each with a rollback index and corresponding configuration revision identifier.

Table 1 outlines the methods that a Junos XML protocol client can use to replace the candidate configuration (or a private copy) with a previously committed configuration. Each option references either the rollback index or the configuration revision identifier, as is appropriate for that method.

<rpc>
    <load-configuration rollback="1"/>
</rpc>

<rpc>
    <load-configuration configuration-revision="re0-1757968687-3"/>
</rpc>

<rpc>
  <rollback-config>
    <index>1</index>
  </rollback-config>
</rpc>

To use the <load-configuration> operation to replace the candidate configuration or a private copy of it with a previously committed configuration, a client application executes the <load-configuration/> operation and includes the rollback or configuration-revision attribute. The rollback value is the numerical rollback index of the appropriate previous configuration. Valid values are 0 (zero, for the most recently committed configuration) through one less than the number of stored previous configurations. The configuration-revision value is the configuration revision ID of the configuration to load, for example, re0-1757968687-3.

The Junos XML protocol server indicates that the load operation was successful by returning the <load-configuration-results> and <load-success/> elements in its RPC reply.

To use the <rollback-config> RPC to load a previously committed configuration, a client application executes the <rollback-config> RPC with the <index> element. The <index> element specifies the rollback index for the configuration to load.

The Junos XML protocol server indicates that the load operation was successful by returning the <rollback-config-results> and <load-success/> 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 <xnm: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 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.

The rescue configuration must exist on the device before you can load it. To replace the candidate configuration or a private copy of it with the device’s rescue configuration, a Junos XML protocol application can use one of the following methods:

• Execute the <load-configuration/> operation with the rescue="rescue" attribute.

• Execute the <rollback-config> RPC with the <rescue/> child element. This RPC is useful when an application does not support executing RPCs that include XML attributes.

To use the <load-configuration/> operation to replace the candidate configuration with the rescue configuration, include the rescue="rescue" attribute.

The Junos XML protocol server indicates that the load operation was successful by returning the <load-configuration-results> and <load-success/> elements in its RPC reply.

To use the <rollback-config> RPC to load the rescue configuration, a client application emits the <rollback-config> element and the <rescue/> child tag.

The Junos XML protocol server indicates that the load operation was successful by returning the <rollback-config-results> and <load-success/> 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, the server returns an <xnm:error> element with information about the error.