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.
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.
<rpc> <copy-config> <target> <candidate/> </target> <source> <url format="(xml | text)"> <!-- location specifier for file containing the new configuration --> </url> </source> </copy-config> </rpc> ]]>]]>
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.
<rpc>
<edit-config>
<target>
<candidate/>
</target>
<default-operation>replace</default-operation>
<!-- EITHER -->
<config>
<configuration>
<!-- Junos XML configuration data -->
</configuration>
</config>
<!-- OR -->
<config-text>
<configuration-text>
<!-- configuration data in text format -->
</configuration-text>
</config-text>
<!-- OR -->
<url>
<!-- location specifier for file containing changes -->
</url>
</edit-config>
</rpc>
]]>]]>
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).
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:
<rpc>
<rollback-config>
<index>1</index>
</rollback-config>
</rpc>
]]>]]>
The NETCONF server indicates that the load operation
was successful by returning the <rollback-config-results> and <ok/> elements in its RPC reply.
<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns:junos="http://xml.juniper.net/junos/18.1R1/junos">
<rollback-config-results>
<ok/>
</rollback-config-results>
</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.
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:
<rpc>
<rollback-config>
<rescue/>
</rollback-config>
</rpc>
]]>]]>The NETCONF server indicates that the load operation
was successful by returning the <rollback-config-results> and <ok/> elements in its RPC reply.
<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns:junos="http://xml.juniper.net/junos/18.1R1/junos">
<rollback-config-results>
<ok/>
</rollback-config-results>
</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.