Committing a Configuration

The following sections describe how to commit the candidate configuration so that 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 commit operations, see the Junos CLI User Guide.

Committing the Candidate Configuration

To commit the candidate configuration, a client application encloses the <commit/> tag in an <rpc> tag element:

The NETCONF server confirms that it committed the candidate configuration by returning the <ok/> tag in the <rpc-reply> tag element:

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

If the NETCONF server cannot commit the candidate configuration, the <rpc-reply> tag element instead encloses an <rpc-error> tag element explaining the reason for the failure. The most common causes are semantic or syntactic errors in the candidate configuration.

To avoid inadvertently committing changes made by other users or applications, a client application locks the candidate configuration before changing it and emits the <commit/> tag while the configuration is still locked. (For instructions on locking and changing the candidate configuration, see Locking the Candidate Configuration and Changing Configuration Information.) After committing the configuration, the client application unlocks the candidate as described in Unlocking the Candidate Configuration.

Committing the Candidate Configuration Only After Confirmation

To commit the candidate configuration but require an explicit confirmation for the commit to become permanent, a client application includes the <confirmed/> tag in <commit> and <rpc> tag elements:

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

If the commit is not confirmed within a certain amount of time (600 seconds [10 minutes] by default), the NETCONF server automatically retrieves and commits (rolls back to) the previously committed configuration. To specify a different number of seconds for the rollback deadline, the application encloses a positive integer value in the <confirm-timeout> tag element:

<rpc>
    <commit>
        <confirmed/> 
        <confirm-timeout>seconds</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> tag element:

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

If the NETCONF server cannot commit the candidate, the <rpc-reply> tag element instead encloses an <rpc-error> tag element explaining the reason for the failure. The most common causes are semantic or syntactic errors in the candidate configuration.

The <confirmed/> tag is useful for verifying that a configuration change works correctly and does not prevent management access to the routing platform. If the change prevents access or causes other errors, the automatic rollback to the previous configuration restores access after the rollback deadline passes.

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> tag element to specify how long to delay the next rollback; omit that tag element to delay the rollback by the default 600 seconds. The client application can delay the rollback indefinitely by emitting the <confirmed/> tag repeatedly in this way.

To cancel the rollback completely (and commit a configuration permanently), the client application emits the <commit/> tag and <rpc> tag element before the rollback deadline passes. The rollback is canceled and the candidate configuration is committed immediately, as described in Committing a Configuration. 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. For more information about session termination, see Terminating Another NETCONF Session.

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