Commit Scripts and the JUNOS Software Commit Model

The JUNOS software uses a commit model to update the router's configuration. This model allows you to make a series of changes to a candidate configuration without affecting the operation of the routing platform. When the changes are complete, you can commit the configuration. The commit operation saves the candidate configuration changes into the current configuration.

When you commit a set of changes in the candidate configuration, two methods are used to forward these changes to the current configuration:

• Standard commit model—Used when no commit scripts are active on the routing platform.
• Commit script model—Incorporates commit scripts into the commit model.

Standard Commit Model

In the standard commit model, the mgd validates the candidate configuration based on the JUNOS validation rule. If this configuration file passes validation, then the file becomes the current configuration. Figure 4 and the accompanying flow discussion show how the standard commit model works:

Figure 4: Standard Commit Model

In the standard commit model, the software performs the following steps:

1. When the candidate configuration is committed, it is copied to become the checkout configuration.
2. The mgd validates the checkout configuration.
3. If no error occurs, the checkout configuration is copied as the current configuration.

Commit Model with Commit Scripts

By adding commit scripts to the commit model, the mgd validates the candidate configuration based on the JUNOS validation rule. If this configuration file passes validation, then the file becomes the current configuration.

When commit scripts are added to the standard commit model, the process becomes more complex. The mgd first passes an XML-formatted checkout configuration to a script driver. This driver handles the verification of the checkout configuration by the commit scripts. When verification is complete, the script driver returns an action XML file to the mgd for processing. The mgd processes this action XML file, updating the candidate and checkout configurations, issuing messages to the CLI, and writing information to the Syslog as required. Once the action XML file is processed, the standard JUNOS validation is handled by the mgd. Figure 5 and the accompanying flow discussion show this process.

Figure 5: ommit Model with Commit Scripts Added

In the commit script model, the software performs the following steps:

1. When the candidate configuration is committed, the mgd sends the XML-formatted candidate configuration to the script driver.
2. Each configured commit script is invoked against the candidate configuration, and each script can issue a set of actions for the mgd to perform.
3. The mgd processes the <error>, <warning>, and <syslog> actions within the action XML file as follows:
   • <error>—If an <error> action is encountered, the mgd fails the commit process, returns an error message to the CLI or JUNOScript client, and takes no further action.
   • <warning>—If a <warning> action is encountered, the mgd forwards the message to the CLI or the JUNOScript client.
   • <syslog>—If a <syslog> action is encountered, a message is forwarded to the syslog.
4. The mgd processes the action file for <change> actions.

   If any <change> actions are emitted by any commit scripts, the requested changes are loaded into the candidate configuration.

5. The candidate configuration is copied to become the checkout configuration.
6. The mgd processes the action file for <transient-change> actions.

   If any <transient-change> actions are emitted by any commit scripts, the requested changes are loaded into the checkout configuration.

7. The mgd validates the checkout configuration.
8. If no error occurs, the checkout configuration is copied as the current configuration.

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, this process will ensure that the candidate configuration, including past persistent changes, conforms to your custom rules. For more information about candidate changes by commit scripts, see Using Multiple Commit Scripts.

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, remove or disable the commit script, or comment out the code that causes the transient change. These concepts are summarized in Table 11.

Copyright © 2008, Juniper Networks, Inc. All rights reserved. Trademark Notice.