Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
ON THIS PAGE
 

<commit-configuration>

Usage

Description

Request that the NETCONF or Junos XML protocol server perform one of the variants of the commit operation. You can perform the commit operation on the candidate configuration, a private copy of the candidate configuration, or an open instance of the ephemeral configuration database.

On devices with dual Routing Engines, you can commit the candidate configuration, private copy, or ephemeral database instance stored on the local Routing Engine on both Routing Engines. The ephemeral database supports only the <synchronize/> option.

Some restrictions apply to the commit operation for a private copy of the candidate configuration and for the ephemeral configuration database. For example:

  • The commit operation fails for a private copy if the regular candidate configuration is locked by another user or application or if it includes uncommitted changes made since the private copy was created.

  • A commit operation on an instance of the ephemeral configuration database supports only the <synchronize/> option.

  • The confirmed commit operation is not available when committing a private copy of the configuration or an open instance of the ephemeral configuration database.

To execute a commit or commit synchronize operation, enclose the appropriate tags in the <commit-configuration> tag element to specify the type of commit operation. Table 1 and Table 2 describe common commit and commit synchronize operations.

Table 1: Commit Operations
<commit-configuration> Operation     Description 
<commit-configuration/>

Commit the configuration immediately, making it the active configuration on the device. 

<commit-configuration>
    <check/>
</commit-configuration>

Verify the syntactic correctness of the candidate configuration or a private copy without actually committing it. 

<commit-configuration>
    <confirmed/>
</commit-configuration>
    
<commit-configuration>
    <confirmed/>
    <confirm-timeout>rollback-delay</confirm-timeout>
</commit-configuration>

Commit the candidate configuration but require an explicit confirmation for the commit to become permanent. If the commit is not confirmed, the configuration rolls back to the previous configuration after the specified time.

Optionally include the <confirm-timeout> element to specify the rollback delay in the range from 1 through 65,535 minutes. By default, the rollback occurs after 10 minutes.

To delay the rollback again (past the original rollback deadline), emit the <commit-configuration><confirmed/></commit-configuration> tags before the deadline passes, and optionally Include the <confirm-timeout> element. The rollback can be delayed repeatedly in this way.

To confirm the commit, emit the empty <commit-configuration/> tag or the <commit-configuration><check/><commit-configuration> tags before the rollback deadline passes. The device commits the candidate configuration and cancels the rollback.

Table 2: Commit Synchronize Operations
<commit-configuration> Operation     Description 
<commit-configuration>
    <synchronize/>
</commit-configuration>

Copy the candidate configuration or the open ephemeral instance data from the local Routing Engine to the other Routing Engine, verify the configuration’s syntactic correctness, and commit it immediately on both Routing Engines.

 
<commit-configuration>
    <synchronize/>
    <at-time>time-specification</at-time>
</commit-configuration>

Copy the candidate configuration stored on the local Routing Engine to the other Routing Engine, verify the candidate’s syntactic correctness, and commit it on both Routing Engines at a defined future time.

You can also specify <force-synchronize/>.

 
<commit-configuration>
    <synchronize/>
    <check/>
</commit-configuration>

Copy the candidate configuration stored on the local Routing Engine to the other Routing Engine and verify the candidate’s syntactic correctness on each Routing Engine.

You can also specify <force-synchronize/>.

 
<commit-configuration>
    <synchronize/>
    <confirmed/>
    <confirm-timeout>rollback-delay</confirm-timeout>
</commit-configuration>

Copy the candidate configuration stored on the local Routing Engine to the other Routing Engine, verify the candidate’s syntactic correctness, and commit it on both Routing Engines but require confirmation.

 
<commit-configuration>
    <synchronize/>
    <force-synchronize/>
</commit-configuration>

Force the same synchronized commit operation as invoked by the <synchronize/> tag to succeed, even if there are open configuration sessions or uncommitted configuration changes on the remote machine.

To schedule the candidate configuration for commit at a future time, enclose the <at-time> element in the <commit-configuration> element. When you execute the operation, the configuration is checked immediately for syntactic correctness. If the check succeeds, the configuration is scheduled for commit at the specified time. If the check fails, the commit operation is not scheduled. Table 3 outlines the valid types of time specifiers.

Table 3: <at-time> Time Specifiers
Time Specifier Description Example

reboot

Commit the configuration the next time the device reboots.

  • <at-time>reboot</at-time>

hh:mm[:ss]

Commit the configuration at the specified time (hours, minutes, and, optionally, seconds). The time must be in the future but before 11:59:59 PM on the current day. Use 24-hour time for the hh value. The device interprets the time with respect to its clock and time zone settings.

  • Execute the operation at  4:30:00 AM:
    <at-time>04:30:00</at-time>

  • Execute the operation at 8:00 PM:
    <at-time>20:00</at-time>

yyyy-mm-dd hh:mm[:ss]

Commit the configuration at the specified date and time (year, month, date, hours, minutes, and, optionally, seconds). The specified time must be after you execute the <commit-configuration> operation. Use 24-hour time for the hh value. The device interprets the time with respect to its clock and time zone settings.

  • Execute the operation at 3:30 PM on August 21, 2005:

    <at-time>2005-08-21 15:30:00</at-time>

Contents

<at-time>

Schedule the commit operation for a specified future time. Valid time specifiers include:

  • reboot

  • hh:mm[:ss]

  • yyyy-mm-dd hh:mm[:ss]
<check>

Request verification that the configuration is syntactically correct, but do not actually commit it.
<confirmed>

Request a commit of the candidate configuration and require an explicit confirmation for the commit to become permanent. If the commit is not confirmed, roll back to the previous configuration after a short time, 10 minutes by default. Use the <confirm-timeout> tag element to specify a different amount of time.
<confirm-timeout>

Specify the number of minutes for which the configuration remains active when the <confirmed/> tag is enclosed in the <commit-configuration> tag element.

  • Range: 1 through 65,535 minutes

  • Default: 10 minutes
<log>

Record a message in the commit history log when the commit operation succeeds.
<synchronize>

On dual control plane systems, request that the configuration on one control plane be copied to the other control plane, checked for correct syntax, and committed on both Routing Engines.
<force-synchronize>

On dual control plane systems, force the candidate configuration on one control plane to be copied to the other control plane.

Release Information

This operation is a Junos XML management protocol operation. It is supported in Junos XML protocol sessions, and it is supported as a Juniper Networks proprietary extension in NETCONF sessions on Junos devices that identify the URI http://xml.juniper.net/netconf/junos/1.0 in the capabilities exchange.

Related Documentation