Command introduced before Junos OS Release 7.4.
Command introduced in Junos OS Release 11.1 for the QFX Series.
Option synchronize scripts introduced in Junos OS Release 13.2.
Command introduced in Junos OS Release 14.1X53-D20 for the OCX Series.
Option no-synchronize introduced in Junos OS Release 17.2R1
Commit the set of configuration changes to the database and cause the changes to take operational effect.
string is reboot or the future time to activate the configuration changes. Enclose the string value (including reboot) in quotation marks (“ ”). You can specify time in two formats:
A time value in the form hh:mm[:ss] (hours, minutes, and optionally seconds)— Commit the configuration at the specified time, which must be in the future by at least one minute but before 11:59:59 PM on the day the commit at configuration command is issued. Use 24-hour time for the hh value; for example, 04:30:00 is 4:30:00 AM, and 20:00 is 8:00 PM. The time is interpreted with respect to the clock and time zone settings on the device.
A date and time value in the form yyyy-mm-dd hh:mm[:ss] (year, month, date, hours, minutes, and, optionally, seconds)—Commit the configuration at the specified day and time, which must be after the commit at command is issued. Use 24-hour time for the hh value. For example, 2003-08-21 12:30:00 is 12:30 PM on August 21, 2003. The time is interpreted with respect to the clock and time zone settings on the router.
For example, commit at "18:00:00". For date and time, include both values in the same set of quotation marks. For example, commit at "2018-03-10 14:00:00".
A commit check is performed when you issue the commit at configuration mode command. If the result of the check is successful, then the current user is logged out of configuration mode, and the configuration data is left in a read-only state. No other commit can be performed until the scheduled commit is completed.
If Junos OS fails before the configuration changes become active, all configuration changes are lost.
You cannot enter the commit at configuration mode command when there is a pending reboot.
You cannot enter the request system reboot command once you schedule a commit operation for a specific time in the future.
You cannot commit a configuration when a scheduled commit is pending. For information about how to use the clear system commit command to cancel a scheduled commit configuration, see clear system commit.
To confirm a commit, enter either a commit or commit check command.
If the commit is not confirmed within the time limit, the configuration rolls back automatically to the precommit configuration and a broadcast message is sent to all logged-in users. To show when a rollback is scheduled, enter the show system commit command. The allowed range is 1 through 65,535 minutes, and the default is 10 minutes.
The timeout for the commit confirmed command is calculated based on the system time, when the commit confirmed command is issued. In case the system time is modified while a commit confirmed is pending, the remaining time until commit execution might get shortened (in case the old system time is behind) or prolonged (in case the old system time is ahead) from the intended interval.
In Junos OS Release 11.4 and later, you can also use the commit confirmed command in the [edit private] configuration mode.
This option allows you to commit only on the current Routing Engine even if set system commit synchronize is configured.
This option overrides the commit peer-synchronize configuration as well. If you have configured the commit synchronize using set system commit synchronize and then use the command commit no-synchronize, the commit will happen only on the device issuing the command.
When using commit synchronize, the commit is first done in the other Routing Engine and then in the current one. If the other Routine Engine is corrupted, the commit will fail. In such cases, you can use commit no-synchronize. This command cannot be configured using set. It can only be run.
The synchronize option has the following two additional options:
<force>—(Optional) Enforce commit synchronization on the Routing Engines by using the force option.
The commit synchronize command does not work if the responding Routing Engine has uncommitted configuration changes. You can enforce commit synchronization on the Routing Engines by using the force option. When you issue the commit synchronize command with the force option from one Routing Engine, the configuration sessions on the other Routing Engine are terminated and the configuration is synchronized with that on the Routing Engine from which you issued the command.
<scripts>—(Optional) Synchronize all commit, event, lib, op, and SNMP scripts from the requesting Routing Engine to the responding Routing Engine and commit and synchronize the configuration.
If the commit check operation fails for the requesting Routing Engine, the process stops, and the scripts are not copied to the responding Routing Engine. If the commit check or commit operation fails for the responding Routing Engine, the scripts are still synchronized, since the synchronization occurs prior to the commit check operation on the responding Routing Engine.
If the load-scripts-from-flash statement is configured at the [edit system scripts] hierarchy level for the requesting Routing Engine, the device synchronizes the scripts from flash memory on the requesting Routing Engine to flash memory on the responding Routing Engine. Otherwise, the device synchronizes the scripts from the hard disk on the requesting Routing Engine to the hard disk on the responding Routing Engine. The device synchronizes all scripts regardless of whether they are enabled in the configuration or have been updated since the last synchronization.
It can happen that the commit synchronize command is initiated at the same time from both Routing Engines, which causes the process to hang. As of Junos OS Release 15.1, this is a temporary (20 seconds) anomaly, after which the user can try the commit sychronize command again.
When you issue the commit synchronize command, you must use the apply-groups re0 and re1 commands. For information about how to use groups, see Disabling Inheritance of a Junos OS Configuration Group.
The responding Routing Engine must use Junos OS Release 5.0 or later.
Beginning in Junos OS 12.3, it is possible that FPCs brought offline using the request chassis fpc slot fpc-slot offline operational-mode CLI command can come online during a configuration commit or power-supply replacement procedure. As an alternative, use the set fpc fpc-slot power off configuration-mode command at the [edit chassis] hierarchy level to ensure that the FPCs remain offline.
| display detail—(Optional) Monitors the commit process.
In Junos OS Release 10.4 and later, if the number of commit details or messages exceeds a page when used with the | display detail pipe option, the more pagination option on the screen is no longer available. Instead, the messages roll up on the screen by default, just like using the commit command with the | no more pipe option.
Required Privilege Level
configure—To enter configuration mode.
If you are using Junos OS in a Common Criteria environment, system log messages are created whenever a secret attribute is changed (for example, password changes or changes to the RADIUS shared secret). These changes are logged during the following configuration load operations:
load merge load replace load override load update
For more information, see the Secure Configuration Guide for Common Criteria and Junos-FIPS