How the JUNOS Software Commit Model Works with Commit Scripts

The JUNOS software uses a commit model for configuration, which allows you to make a series of changes to a candidate configuration without affecting the operation of the routing platform. When you decide that changes are complete, you can commit the configuration. The commit operation causes the candidate configuration to become active. When you are not using commit scripts, the software performs the following steps:

1. The software copies the candidate configuration to the checkout configuration database.
2. The software inspects the checkout configuration. The software might generate error, warning, and system log messages based on standard JUNOS validity rules.
3. If the software detects no errors, the checkout configuration becomes the active configuration.

When commit scripts are added to the standard commit model, the process becomes more complex. When you commit the candidate configuration, the software performs the following steps:

1. The software generates an XML-formatted version of the candidate configuration.
2. One or more commit scripts are applied to the candidate configuration.
3. As each script finishes, the software might generate error, warning, and system log messages based on each script.
4. The software copies any persistent changes generated by the scripts to the candidate configuration.
5. The software copies any persistent and transient changes to the checkout configuration database.
6. The software inspects the checkout configuration. The software might generate error, warning, and system log messages based on standard JUNOS validity rules.
7. If the software detects no errors, the checkout configuration becomes the active configuration.

Figure 4 shows the flow of operations when commit scripts are added to the standard JUNOS commit model.

Figure 4: Flow of Commit Operation with Commit Scripts

Steps 2 and 3 ensure the candidate configuration conforms to your custom rules. Persistent changes are added to the candidate configuration afterwards, in Step 4. Step 6 is a standard JUNOS validity check, not a verification that the configuration conforms to your commit script rules.

Changes generated by commit scripts are not evaluated by your custom rules the first time they are committed. However, persistent changes are carried in the candidate configuration. During a subsequent commit operation, Steps 2 and 3 ensure that the candidate configuration, including past persistent changes, conforms to your custom rules.

Transient changes are never tested by and do not need to conform to commit script rules. Commit scripts evaluate the candidate configuration, and transient changes are not copied to the candidate configuration. To remove a transient change from the configuration, all you need to do is remove or disable the commit script, or comment out the code that causes the transient change. These concepts are summarized in Table 9.