<commit-configuration>

Usage

Description

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

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. Also, a commit operation on an instance of the ephemeral configuration database only supports the <synchronize/> option.

Enclose the appropriate tag in the <commit-configuration> tag element to specify the type of commit operation:

• To commit the configuration immediately, making it the active configuration on the device, emit the empty <commit-configuration/> tag.

• To verify the syntactic correctness of the candidate configuration or a private copy without actually committing it, enclose the <check/> tag in the <commit-configuration> tag element.

• To record a message in the commit history log when the associated commit operation succeeds, define the log message string in the <log> tag element and enclose the tag element in the <commit-configuration> tag element. The <log> tag element can be combined with any other tag element. When the <log> tag element is emitted alone, the associated commit operation begins immediately.

• To commit the candidate configuration but require an explicit confirmation for the commit to become permanent, enclose the <confirmed/> tag in the <commit-configuration> tag element.

  If the commit is not confirmed, the configuration rolls back to the previous configuration after a short time. By default, the rollback occurs after 10 minutes. To set a different rollback delay, include the <confirm-timeout> tag element, and specify a value in the range from 1 through 65,535 minutes. To delay the rollback again (past the original rollback deadline), emit the <confirmed/> tag (enclosed in the <commit-configuration> tag element) before the deadline passes, and optionally Include the <confirm-timeout> element to specify a delay that is different from the default. The rollback can be delayed repeatedly in this way.

  To commit the configuration immediately and permanently after emitting the <confirmed/> tag, emit either 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. If the candidate configuration is still the same as the current committed configuration, the effect is the same as recommitting the current committed configuration.

  Note:

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

• On a device with two Routing Engines, commit the candidate configuration, private copy, or ephemeral database instance stored on the local Routing Engine on both Routing Engines. Combine tag elements as indicated in the following (the ephemeral database only supports the <synchronize/> option):

  • To copy the candidate configuration or the configuration data in the open ephemeral instance that is stored on the local Routing Engine to the other Routing Engine, verify the configuration’s syntactic correctness, and commit it immediately on both Routing Engines, enclose the <synchronize/> tag in the <commit-configuration> tag element.

  • To 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, enclose the <synchronize/> or <force-synchronize/> tag and <at-time> tag element in the <commit-configuration> tag element. Set the value in the <at-time> tag element as previously described for use of the <at-time> tag element alone.

  • To 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, enclose the <synchronize/> or <force-synchronize/> and <check/> tag elements in the <commit-configuration> tag element.

  • To 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, enclose the <synchronize/> tag and <confirmed/> tag elements, and optionally the <confirm-timeout> tag element, in the <commit-configuration> tag element. Set the value in the <confirm-timeout> tag element as previously described for use of the <confirmed/> tag and <confirm-timeout> tag element alone.

  • To 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, enclose the <force-synchronize/> tag in the <commit-configuration> tag element.

• To schedule the candidate configuration for commit at a future time, enclose the <at-time> tag element in the <commit-configuration> tag element. There are three valid types of time specifiers:

  • The string reboot, to commit the configuration the next time the device reboots.

  • A time value of the form hh:mm[:ss] (hours, minutes, and, optionally, seconds), to commit the configuration at the specified time, which must be in the future but before 11:59:59 PM on the day the <commit-configuration> tag element is emitted. Use 24-hour time for the hh value; for example, 04:30:00 means 4:30:00 AM and 20:00 means 8:00 PM. The time is interpreted with respect to the clock and time zone settings on the device.

  • A date and time value of the form yyyy-mm-dd hh:mm[:ss] (year, month, date, hours, minutes, and, optionally, seconds), to commit the configuration at the specified date and time, which must be after the <commit-configuration> tag element is emitted. Use 24-hour time for the hh value. For example, 2005-08-21 15:30:00 means 3:30 PM on August 21, 2005. The time is interpreted with respect to the clock and time zone settings on the device.

    Note:

    The time you specify must be more than 1 minute later than the current time on the device.

    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.

Contents

Release Information

This 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 devices running Junos OS that identify the URI http://xml.juniper.net/netconf/junos/1.0 in the capabilities exchange.