A client application can completely replace the current candidate configuration, either with new data or by rolling back to a previous configuration.
 |
Note: To comply with the NETCONF specification, the NETCONF server accepts the <delete-config> tag element, which deletes the entire candidate configuration. However, a commit operation fails if the candidate configuration does not exist or is completely empty, so the application must use the <edit-config> or <copy-config> tag element to add data to the candidate configuration before committing it. See <delete-config>. |
For information about completely replacing the candidate configuration, see the following sections:
To replace the entire candidate configuration with new configuration data, a client application can use either of two methods, as described in the following sections.
With either method, the NETCONF server confirms that it replaced the candidate configuration by returning the <ok/> tag in the <rpc-reply> tag element:
If the NETCONF server cannot replace the candidate configuration data, the <rpc-reply> tag element instead encloses an<rpc-error> tag element explaining the reason for the failure.
One method for replacing the entire candidate configuration is to include the <copy-config> tag element in the <rpc> tag element. The <source> tag element encloses the <url> tag element to specify the filename that contains the new configuration data. The <target> tag element encloses the <candidate/> tag to indicate that the new configuration data replaces the candidate configuration:
<rpc>
<copy-config>
<target>
<candidate/>
</target>
<source>
<url>
<!- - location specifier for file containing the new configuration - ->
</url>
</source>
</copy-config>
</rpc>
]]>]]>
The other method for replacing the entire candidate configuration is to set replace mode as the default incorporation mode. The candidate configuration includes the <default-operation>tag element with the value replace in the <edit-config> tag element, as described in Setting the Default Mode for Incorporating New Configuration Data. To specify the new configuration data, the application includes either a <config> tag element that contains the data or a <url> tag element that names the file containing the data, as discussed in Defining the New Configuration Data.
<rpc>
<edit-config>
<default-operation>replace</default-operation>
<source>
<!- - EITHER - ->
<config>
<!- - tag elements representing the new configuration - ->
</config>
<!- - OR - ->
<url>
<!- - location specifier for file containing the new configuration - ->
</url>
</source>
</edit-config>
</rpc>
]]>]]>
To discard changes made to the candidate configuration and make its contents match the contents of the current running (active) configuration, a client application includes the <discard-changes/> tag in an<rpc> tag element:
This operation is equivalent to the CLI configuration mode rollback command.
The NETCONF server indicates that it discarded the changes by enclosing the <ok/> tag in the <rpc-reply> tag element:
 |
Copyright © 2009, Juniper Networks, Inc. All rights reserved. Trademark Notice. | |