Committing the Candidate Configuration Only After Confirmation

<rpc>
    <commit-configuration>
        <confirmed/> 
    </commit-configuration>
</rpc>

<rpc>
    <commit-configuration>
        <confirmed/> 
        <confirm-timeout>minutes</confirm-timeout> 
    </commit-configuration>
</rpc>

Note: You cannot perform this commit operation on a private copy of the configuration.

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.

In response to a confirmed commit operation, the Junos XML protocol server returns <rpc-reply>, <commit-results>, and <routing-engine> tag elements. If the commit operation succeeds, the <routing-engine> tag element encloses the <commit-success/> tag and the <name> tag element, which reports the name of the Routing Engine on which the commit operation succeeded (re0 on devices that use a single Routing Engine, and either re0 or re1 on devices that can have two Routing Engines):

<rpc-reply xmlns:junos="URL">
    <commit-results>
        <routing-engine>
            <name>(re0 | re1)</name>
            <commit-success/>
        </routing-engine>
    </commit-results>
</rpc-reply>

If the commit operation fails, an <xnm:error> tag element encloses tag elements that describe the error. The most common causes of failure are semantic or syntactic errors in the candidate configuration.

To delay the rollback to a time later than the current rollback deadline, the application encloses the <confirmed/> tag in a <commit-configuration> tag element again before the deadline passes. It can include the <confirm-timeout> tag element to specify how long to delay the next rollback, or omit that tag element to delay the rollback by the default of 10 minutes. The 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 application emits one of the following tag sequences before the rollback deadline passes:

• The empty <commit-configuration/> tag enclosed in an <rpc> tag element. The rollback is canceled and the candidate configuration is committed immediately, as described in Committing the Candidate Configuration. If the candidate configuration is still the same as the temporarily committed configuration, this effectively recommits the temporarily committed configuration:
  <rpc><commit-configuration/></rpc>
• The <synchronize/> tag enclosed in <commit-configuration> and <rpc> tag elements:

  <rpc>
      <commit-configuration>
          <synchronize/> 
      </commit-configuration>
  </rpc>
  

  The rollback is canceled and the candidate configuration is checked and committed immediately on both Routing Engines, as described in Committing and Synchronizing a Configuration on Redundant Control Planes. If a confirmed commit operation has been performed on both Routing Engines, then emitting the <synchronize/> tag cancels the rollback on both.

• The <at-time> tag element enclosed in <commit-configuration> and <rpc> tag elements:
  <rpc><commit-configuration><at-time>time</at-time> </commit-configuration></rpc>

  The rollback is canceled and the configuration is checked immediately for syntactic correctness, then committed at the scheduled time, as described in Committing a Configuration at a Specified Time.

The <confirmed/> and <confirm-timeout> tag elements can be combined with the <synchronize/> tag, the <log/> tag element, or both. For more information, see Committing and Synchronizing a Configuration on Redundant Control Planes and Logging a Message About a Commit Operation.

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