Committing the Candidate Configuration Only After Confirmation Using NETCONF
When you commit the candidate configuration on a device running Junos OS, it becomes the active configuration on the routing, switching, or security platform. For more detailed information about commit operations, including a discussion of the interaction among different variants of the operation, see the CLI User Guide
When you commit the candidate configuration, you can require an explicit confirmation for the commit to become permanent. The confirmed commit operation is useful for verifying that a configuration change works correctly and does not prevent management access to the device. If the change prevents access or causes other errors, the automatic rollback to the previous configuration restores access after the rollback deadline passes. If the commit is not confirmed within the specified amount of time, which is 600 seconds (10 minutes) by default, the device automatically loads and commits (rolls back to) the previously committed configuration.
In a NETCONF session with a device running Junos OS,
to commit the candidate configuration but require an explicit confirmation
for the commit to become permanent, a client application encloses
<confirmed/> tag in the
<rpc> tag elements.
To specify a number of seconds for the rollback deadline that
is different from the default value of 600 seconds, the application
<confirm-timeout> tag element,
and specifies the number of seconds for the delay, in the range from
1 through 4,294,967,295 seconds.
You cannot perform a confirmed commit operation on an instance of the ephemeral configuration database.
In either case, the NETCONF server confirms that it committed
the candidate configuration temporarily by returning the
<ok/> tag in the
<rpc-reply xmlns="URN" xmlns:junos="URL">
If the NETCONF server cannot commit the candidate configuration,
<rpc-reply> element instead encloses
<rpc-error> element explaining the
reason for the failure. The most common causes are semantic or syntactic
errors in the candidate configuration.
To delay the rollback to a time later than the current rollback
deadline, the client application emits the
<confirmed/> tag in a
<commit> tag element again
before the deadline passes. Optionally, it includes the
<confirm-timeout> element to specify how long to
delay the next rollback; omit that tag element to delay the rollback
by the default of 600 seconds (10 minutes). The client application
can delay the rollback indefinitely by emitting the
<confirmed/> tag repeatedly in this way.
To commit the configuration permanently, the client application
<commit/> tag enclosed in
<rpc> tag element before the rollback
deadline passes. The rollback is canceled and the candidate configuration
is committed immediately, as described in Committing the Candidate Configuration Using NETCONF.
If the candidate configuration is still the same as the temporarily
committed configuration, this effectively recommits the temporarily
If another application uses the
<kill-session/> tag element to terminate this application’s session while
a confirmed commit is pending (this application has committed changes
but not yet confirmed them), the NETCONF server that is servicing
this session restores the configuration to its state before the confirmed
commit instruction was issued. For more information about session
termination, see Terminating a NETCONF Session.
The following example shows how to commit the candidate configuration with a rollback deadline of 300 seconds.
<rpc> <commit> <confirmed/> <confirm-timeout>300</confirm-timeout> </commit> </rpc> ]]>]]>
<rpc-reply xmlns="URN" xmlns:junos="URL"> <ok/> </rpc-reply> ]]>]]>