Commit the Candidate Configuration Only After Confirmation Using NETCONF

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 the empty <confirmed/> tag in the <commit> and <rpc> tag elements.

<rpc>
    <commit>
        <confirmed/> 
    </commit>
</rpc>
]]>]]>

To specify a number of seconds for the rollback deadline that is different from the default value of 600 seconds, the application includes the <confirm-timeout> tag element, and specifies the number of seconds for the delay, in the range from 1 through 4,294,967,295 seconds.

<rpc>
    <commit>
        <confirmed/> 
        <confirm-timeout>rollback-delay</confirm-timeout> 
    </commit>
</rpc>
]]>]]>

In either case, the NETCONF server confirms that it committed the candidate configuration temporarily by returning the <ok/> tag in the <rpc-reply>.

<rpc-reply xmlns="URN" xmlns:junos="URL">
    <ok/>
</rpc-reply>
]]>]]>

If the NETCONF server cannot commit the candidate configuration, the <rpc-reply> element instead encloses an <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 emits the <commit/> tag enclosed in an <rpc> tag element before the rollback deadline passes. The rollback is canceled and the candidate configuration is committed immediately, as described in Commit the Candidate Configuration Using NETCONF. If the candidate configuration is still the same as the temporarily committed configuration, this effectively recommits the temporarily committed configuration.

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.

The following example shows how to commit the candidate configuration with a rollback deadline of 300 seconds.

Client Application

<rpc>
  <commit>
    <confirmed/>
    <confirm-timeout>300</confirm-timeout>
  </commit>
</rpc>
]]>]]>

NETCONF Server

<rpc-reply xmlns="URN" xmlns:junos="URL">
  <ok/>
</rpc-reply>
]]>]]>