The commit configuration mode command enables you to save the device configuration changes to the configuration database and to activate the configuration on the device.
The device configuration is saved using a commit model—a candidate configuration is modified as desired and then committed to the system. When a configuration is committed, the device checks the configuration for syntax errors, and if no errors are found, the configuration is saved as juniper.conf.gz and activated. The formerly active configuration file is saved as the first rollback configuration file (juniper.conf.1.gz), and any other rollback configuration files are incremented by 1. For example, juniper.conf.1.gz is incremented to juniper.conf.2.gz, making it the second rollback configuration file. The device can have a maximum of 49 rollback configurations (numbered 1 through 49) saved on the system.
On the device, the current configuration file and the first three rollback files (juniper.conf.gz.1, juniper.conf.gz.2, juniper.conf.gz.3) are located in the /config directory. (The remaining rollback files, 4 through 49, are located in /var/db/config.)
If the recovery configuration file rescue.conf.gz exists, this file is also located in the /config directory. The factory default files are located in the /etc/config directory.
There are two mechanisms used to propagate the configurations between Routing Engines within a device:
To save device configuration changes to the configuration database and to activate the configuration on the device, use the commit configuration mode command. You can issue the commit command from any hierarchy level: user@host# commit commit complete  user@host#
When you enter the commit command, the configuration is first checked for syntax errors (commit check). Then, if the syntax is correct, the configuration is activated and becomes the current, operational device configuration.
We do not recommend performing a commit operation on the backup Routing Engine when graceful Routing Engine switchover is enabled on the router.
A configuration commit can fail for any of the following reasons:
If the configuration contains syntax errors, a message indicates the location of the error, and the configuration is not activated. The error message has the following format:[edit edit-path] ‘offending-statement;’ error-message
For example:[edit firewall filter login-allowed term allowed from] ‘icmp-type [ echo-request echo-reply ];’ keyword ‘echo-reply’ unrecognized
You must correct the error before recommitting the configuration. To return quickly to the hierarchy level where the error is located, copy the path from the first line of the error and paste it at the configuration mode prompt at the  hierarchy level.
The uncommitted, candidate configuration file is /var/rundb/juniper.db. It is limited to 700 MB. If the commit fails with a message configuration database size limit exceeded, view the file size from configuration mode by entering the command run file list /var/rundb detail. You can simplify the configuration and reduce the file size by creating configuration groups with wildcards or defining less specific match policies in your firewall filters.
CLI commit-time warnings displayed for configuration changes at the [edit interfaces] hierarchy level are removed and are logged as system log messages.
This is also applicable to VRRP configuration at the following hierarchy levels:
When you commit a configuration, you commit the entire configuration in its current form.
Up to 32 users can be in configuration mode simultaneously making changes to the configuration. All changes made by all users are visible to everyone editing the configuration—the changes become visible as soon as the user presses the Enter key at the end of a command that changes the configuration, such as set, edit, or delete.
When any of the users editing the configuration issues a commit command, the CLI checks and activates all changes by all users.
If you enter configuration mode with the configure private command, each user has a private candidate configuration to edit somewhat independently of other users. When you commit the configuration, the CLI commits only your own changes. To synchronize your copy of the configuration after other users have committed changes, you can run the update command in configuration mode. A commit operation also updates all the private candidate configurations. For example, suppose user X and user Y are both in configure private mode, and user X commits a configuration change. When user Y performs a subsequent commit operation and then views the new configuration, the new configuration seen by user Y includes the changes made by user X.
If you enter configuration mode with the configure exclusive command, you lock the candidate configuration for as long as you remain in configuration mode. This allows you to make changes without interference from other users. Other users can enter and exit configuration mode, but they cannot commit the configuration. This is true even if the other users entered configuration mode before you enter the configure exclusive command. For example, suppose user X is already in the configure private or configure mode. Then suppose user Y enters the configure exclusive mode. User X cannot commit any changes to the configuration, even if user X entered those changes before user Y logged in. If user Y exits configure exclusive mode, user X can then commit the changes made in configure private or configure mode.
You can complete the commit process in two steps. The two-step commit feature enables you to configure several devices and simultaneously activate the configurations. Two-step commit provides a definitive time window for the commit to be effective on the system. You can enter commit mode after the commit is prepared, but you will receive a message that the commit is pending activation.
In the first step, the preparation stage, the commit is validated and a new database with the necessary files is generated. If the configuration contains any syntax errors, an appropriate error message is displayed, and the configuration is not prepared. In the event of failure during the preparation stage, the error message commit check-out faileddisplays.
In the second step, the activation stage, the previously prepared configuration is activated. Next, if you need to clear the prepared configuration, you can do so by using clear system commit prepared command. A log message is generated upon successful clearing of the pending commit.
You cannot perform commit operations in between preparation and activation stages.
The two-step commit process is superior to the single-step process for time-critical commits. In the single-step process, the preparation time can vary depending on the existing configuration on the device. In the two-step process, the complex preparation work is more efficiently handled.
Configuration commands are provided that allow you to prepare the configuration cache and activate the configuration. You can prepare the devices with new configurations and activate them at the exact times you want.
The commit prepare command validates the configurations, and the commit activate command activates the configurations. The commands have the following configuration options:
The commit prepare and commit activate commands are available for private, exclusive and shared commits only. The commands are not applicable for dynamic and ephemeral modes. This feature is applicable for multichassis devices, but it is not applicable for batch commits.
To support this functionality using Network Configuration Protocol (NETCONF), the following new remote procedure calls (RPCs) are provided:
You can complete the commit process in two steps. This enables you to configure several devices, and the configurations can be activated simultaneously. In the first step, known as the preparation stage, the commit is validated and a new database along with necessary files is generated. If the configuration contains any syntax errors, an appropriate error message is displayed, and the configuration is not prepared. In the second step, referred to as the activation stage, the previously prepared configuration is activated and becomes the current, operational device configuration.
To prepare the configuration:
To activate the prepared configuration:
To verify the output of the show system commit and show system commit revision detail commands after commit activate is issued, issue the following commands.user@host> show system commit 0 2018-07-12 22:54:46 PDT by user via cli commit activate user@host> show system commit revision detail Revision: re0-1499925285-2214 User : user Client : cli Time : 2018-07-12 22:54:46 PDT Comment : commit activate
When you commit the current candidate configuration, you can require an explicit confirmation for the commit to become permanent. This is useful if you want to verify that a configuration change works correctly and does not prevent access to the device. If the change prevents access or causes other errors, the device automatically returns to the previous configuration and restores access after the rollback confirmation timeout passes. This feature is called automatic rollback.
To commit the current candidate configuration but require an explicit confirmation for the commit to become permanent, use the commit confirmed configuration mode command: user@host# commit confirmed commit confirmed will be automatically rolled back in 10 minutes unless confirmed commit complete #commit confirmed will be rolled back in 10 minutes  user@host#
Once you have verified that the change works correctly, you can keep the new configuration active by entering a commit or commit check command within 10 minutes of the commit confirmed command. For example: user@host# commit check configuration check succeeds
If the commit is not confirmed within a certain time (10 minutes by default), the operating system automatically rolls back to the previous configuration and a broadcast message is sent to all logged-in users.
To show when a rollback is scheduled after a commit confirmed command, enter the show system commit command. For example:user@host>show system commit 0 2018-01-05 15:00:37 PST by root via cli commit confirmed, rollback in 3mins
Like the commit command, the commit confirmed command verifies the configuration syntax and reports any errors. If there are no errors, the configuration is activated temporarily (10 minutes by default) and begins running on the device.
Figure 1: Confirm a Configuration
To change the amount of time before you must confirm the new configuration, specify the number of minutes when you issue the command: user@host# commit confirmed minutes commit complete  user@host#
You can also use the commit confirmed command in the [edit private] configuration mode.
You can schedule when you want your candidate configuration to become active. To save device configuration changes and activate the configuration on the device at a future time or upon reboot, use the commit at configuration mode command, specifying reboot or a future time at the  hierarchy level: user@host # commit at string
string is reboot or the future time to activate the configuration changes. You can specify time in two formats:
Enclose the string value in quotation marks (" "). 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 immediately 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 the device software fails before the configuration changes become active, all configuration changes are lost.
You cannot enter the commit at configuration command after you issue the request system reboot command.
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 cancel a scheduled configuration by means of the clear command, see the CLI Explorer.
We do not recommend performing a commit operation on the backup Routing Engine when graceful Routing Engine switchover is enabled on the device.
To monitor the device configuration commit process, use the display detail command after the pipe with the commit command:user@host# commit | display detail
For example: user@host# commit | display detail 2018-09-22 15:39:39 PDT: exporting juniper.conf 2018-09-22 15:39:39 PDT: setup foreign files 2018-09-22 15:39:39 PDT: propagating foreign files 2018-09-22 15:39:39 PDT: complete foreign files 2018-09-22 15:39:40 PDT: copying configuration to juniper.data+ 2018-09-22 15:39:40 PDT: dropping unchanged foreign files 2018-09-22 15:39:40 PDT: daemons checking new configuration 2018-09-22 15:39:41 PDT: commit wrapup... 2018-09-22 15:39:42 PDT: activating '/var/etc/ntp.conf' 2018-09-22 15:39:42 PDT: activating '/var/etc/kmd.conf' 2018-09-22 15:39:42 PDT: activating '/var/db/juniper.data' 2018-09-22 15:39:42 PDT: notifying daemons of new configuration 2018-09-22 15:39:42 PDT: signaling 'Firewall daemon', pid 24567, signal 1, status 0 2018-09-22 15:39:42 PDT: signaling 'Interface daemon', pid 24568, signal 1, status 0 2018-09-22 15:39:43 PDT: signaling 'Routing protocol daemon', pid 25679, signal 1, status 0 2018-09-22 15:39:43 PDT: signaling 'MIB2 daemon', pid 24549, signal 1, status 0 2018-09-22 15:39:43 PDT: signaling 'NTP daemon', pid 37863, signal 1, status 0 2018-09-22 15:39:43 PDT: signaling 'Sonet APS daemon', pid 24551, signal 1, status 0 2018-09-22 15:39:43 PDT: signaling 'VRRP daemon', pid 24552, signal 1, status 0 2018-09-22 15:39:43 PDT: signaling 'PFE daemon', pid 2316, signal 1, status 0 2018-09-22 15:39:43 PDT: signaling 'Traffic sampling control daemon', pid 24553 signal 1, status 0 2018-09-22 15:39:43 PDT: signaling 'IPsec Key Management daemon', pid 24556, signal 1, status 0 2018-09-22 15:39:43 PDT: signaling 'Forwarding UDP daemon', pid 2320, signal 1, status 0 commit complete
Batch commit aggregates or merges multiple configuration edits from different CLI sessions or users and adds them to a batch commit queue. A batch commit server running on the device takes one or more jobs from the batch commit queue, applies the configuration changes to the shared configuration database, and then commits the configuration changes in a single commit operation.
Batches are prioritized by the commit server based on priority of the batch specified by the user or the time when the batch job is added. When one batch commit is complete, the next set of configuration changes are aggregated and loaded into the batch queue for the next session of the batch commit operation. Batches are created until there are no commit entries left in the queue directory.
When compared to the regular commit operation where all commits are independently committed sequentially, batch commits save time and system resources by committing multiple small configuration edits in a single commit operation.
Batch commits are performed from the [edit batch] configuration mode. The commit server properties can be configured at the [edit system commit server] hierarchy level.
When there is a load-time error in one of the aggregated jobs, the commit job that encounters the error is discarded and the remaining jobs are aggregated and committed.
For example, if there are five commit jobs (commit-1, commit-2, commit-3, commit-4, and commit-5) being aggregated, and commit-3 encounters an error while loading, commit-3 is discarded and commit-1, commit-2, commit-4, and commit-5 are aggregated and committed.
If there is an error during the commit operation when two or more jobs are aggregated and committed, the aggregation is discarded and each of those jobs is committed individually like a regular commit operation.
For example, if there are five commit jobs (commit-1, commit-2, commit-3, commit-4, and commit-5) that are aggregated and if there is a commit error caused because of commit-3, the aggregation is discarded, commit-1, commit-2, commit-3, commit-4, and commit-5 are committed individually, and the CLI reports a commit error for commit-3.
This example shows how to configure batch commit server properties to manage batch commit operations.
This example uses the following hardware and software components:
You can control how the batch commit queue is handled by the commit server by configuring the server properties at the [edit system commit server] hierarchy level. This enables you to control how many commit jobs are aggregated or merged into a single batch commit, the maximum number of jobs that can be added to the queue, days to keep batch commit error logs, interval between two batch commits, and tracing operations for batch commit operations.
To quickly configure this section of the example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, and then copy and paste the commands into the CLI at the  hierarchy level. You can configure the commit server properties from either the regular  mode or the [edit batch] mode.
Device R0set system commit server maximum-aggregate-pool 4 set system commit server maximum-entries 500 set system commit server commit-interval 5 set system commit server days-to-keep-error-logs 30 set system commit server traceoptions file commitd_nov set system commit server traceoptions flag all
Confirm that the configuration is working properly.
After you commit the configuration and are satisfied that it is running successfully, you should issue the request system snapshot command to back up the new software onto the /altconfig file system. If you do not issue the request system snapshot command, the configuration on the alternate boot drive is out of sync with the configuration on the primary boot drive.
The request system snapshot command backs up the root file system to /altroot, and /config to /altconfig. The root and /config file systems are on the router’s flash drive, and the /altroot and /altconfig file systems are on the router’s hard disk (if available).
After you issue the request system snapshot command, you cannot return to the previous version of the software because the running and backup copies of the software are identical.