Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
ON THIS PAGE
 

Overview of Generating Persistent or Transient Configuration Changes Using Commit Scripts

Junos OS commit scripts enforce custom configuration rules. When a candidate configuration includes statements that you have decided must not be included in your configuration, or when the candidate configuration omits statements that you have decided are required, commit scripts can automatically change the configuration and thereby correct the problem.

Differences Between Persistent and Transient Changes

Configuration changes made by commit scripts can be persistent or transient.

A persistent change remains in the candidate configuration and affects routing operations until you explicitly delete it, even if you subsequently remove or disable the commit script that generated the change and reissue the commit command. In other words, removing the commit script does not cause a persistent change to be removed from the configuration.

A transient change, in contrast, is made in the checkout configuration but not in the candidate configuration. The checkout configuration is the configuration database that is inspected for standard Junos OS syntax just before it is copied to become the active configuration on the device. If you subsequently remove or disable the commit script that made the change and reissue the commit command, the change is no longer made to the checkout configuration and so does not affect the active configuration. In other words, removing the commit script effectively removes a transient change from the configuration.

A common use for transient changes is to eliminate the need to repeatedly configure and display well-known policies, thus allowing these policies to be enforced implicitly. For example, if MPLS must be enabled on every interface with an International Organization for Standardization (ISO) protocol enabled, the change can be transient, so that the repetitive or redundant configuration data need not be carried or displayed in the candidate configuration. Furthermore, transient changes allow you to write script instructions that apply the change only if a set of conditions is met.

Persistent and transient changes are loaded into the configuration in the same manner that the load replace configuration mode command loads an incoming configuration. When generating a persistent or transient change, adding the replace="replace" attribute to a configuration element produces the same behavior as a replace: tag in a load replace operation.

By default, Junos OS merges the incoming configuration and the candidate configuration. New statements and hierarchies are added, and conflicting statements are overridden. When generating a persistent or transient change, if you add the replace="replace" attribute to a configuration element, Junos OS replaces the existing configuration element with the incoming configuration element. If the replace="replace" attribute is added to a configuration element, but there is no existing element of the same name in the current configuration, the incoming configuration element is added into the configuration. Elements that do not have the replace attribute are merged into the configuration.

Persistent and transient changes are loaded before the standard Junos OS validation checks are performed. This means any configuration changes introduced by a commit script are validated for correct syntax. If the syntax is correct, the new configuration becomes the active, operational device configuration.

Protected elements in the configuration hierarchy cannot be modified or deleted by either a persistent or a transient change. If a commit script attempts to modify or delete a protected statement or hierarchy, Junos OS issues a warning that the change cannot be made, and proceeds with the commit.

Persistent and transient changes have several important differences, as described in Table 1.

Table 1: Differences Between Persistent and Transient Changes

Persistent Changes

Transient Changes

You can represent a persistent change in commit scripts by using the content parameter in conjunction with a tag parameter that is set to 'change' inside a call to the jcs:emit-change template in SLAX and XSLT scripts or a call to the jcs.emit_change method in Python scripts.

SLAX and XSLT commit scripts can also represent a persistent change by using the <change> tag.

You can represent a transient change in commit scripts with the content parameter in conjunction with the a tag parameter that is set to 'transient-change' inside a call to the jcs:emit-change template in SLAX and XSLT scripts or a call to the jcs.emit_change method in Python scripts.

SLAX and XSLT commit scripts can also represent a transient change by using the <transient-change> tag.

You can use persistent changes to perform any Junos XML protocol operation, such as activate, deactivate, delete, insert (reorder), comment (annotate), and replace sections of the configuration.

Like persistent changes, you can use transient changes to perform any Junos XML protocol operation. However, some Junos XML protocol operations do not make sense to use with transient changes, such as generating comments and inactive settings.

Persistent changes are always loaded during the commit process if no errors are generated by any commit scripts or by the standard Junos OS validity check.

For transient changes to be loaded, you must include the allow-transients statement at the [edit system scripts commit] hierarchy level. If you enable a commit script that generates transient changes and you do not include the allow-transients statement in the configuration, the CLI generates an error message and the commit operation fails. You cannot use a commit script to generate the allow-transients statement.

Like persistent changes, transient changes must pass the standard Junos OS validity check.

Persistent changes work like the load replace configuration mode command, and the change is added to the candidate configuration.

When generating a persistent change, if you add the replace="replace" attribute to a configuration element, Junos OS replaces the existing element in the candidate configuration with the incoming configuration element. If there is no existing element of the same name in the candidate configuration, the incoming configuration element is added into the configuration. Elements that do not have the replace attribute are merged into the configuration.

Transient changes work like the load replace configuration mode command, and the change is added to the checkout configuration.

When generating a transient change, if you add the replace="replace" attribute to a configuration element, Junos OS replaces the existing element in the checkout configuration with the incoming configuration element. If there is no existing element of the same name in the checkout configuration, the incoming configuration element is added into the configuration. Elements that do not have the replace attribute are merged into the configuration.

Transient changes are not copied to the candidate configuration. For this reason, transient changes are not saved in the configuration if the associated commit script is deleted or deactivated.

After a persistent change is committed, the software treats it like a change you make by directly editing and committing the candidate configuration.

After the persistent changes are copied to the candidate configuration, they are copied to the checkout configuration. If  the changes pass the standard Junos OS validity checks, the changes are propagated to the switch, router, or security device components.

Each time a transient change is committed, the software updates the checkout configuration database. After the transient changes pass the standard Junos OS validity checks, the changes are propagated to the device components.

After committing a script that causes a persistent change to be generated, you can view the persistent change by issuing the show configuration mode command:

user@host# show

This command displays persistent changes only, not transient changes.

After committing a script that causes a transient change to be generated, you can view the transient change by issuing the show | display commit-scripts configuration mode command:

user@host# show | display commit-scripts

This command displays both persistent and transient changes.

Persistent changes must conform to your custom configuration design rules as dictated by commit scripts.

This does not become apparent until after a second commit operation because persistent changes are not evaluated by commit script rules on the current commit operation. The subsequent commit operation fails if the persistent changes do not conform to the rules imposed by the commit scripts configured during the first commit operation.

Transient changes are never tested by and do not need to conform to your custom rules. This is caused by the order of operations in the Junos OS commit model, which is explained in detail in Commit Scripts and the Junos OS Commit Model.

A persistent change remains in the configuration even if you delete, disable, or deactivate the commit script instructions that generated the change.

If you delete, disable, or deactivate the commit script instructions that generate a transient change, the change is removed from the configuration after the next commit operation. In short, if the associated instructions or the entire commit script is removed, the transient change is also removed.

As with direct CLI configuration, you can remove a persistent change by rolling back to a previous configuration that did not include the change and issuing the commit command. However, if you do not disable or deactivate the associated commit script, and the problem that originally caused the change to be generated still exists, the change is automatically regenerated when you issue another commit command.

You cannot remove a transient change by rolling back to a previous configuration.

You can alter persistent changes directly by editing the configuration using the CLI.

You cannot directly alter or delete a transient change by using the Junos OS CLI, because the change is not in the candidate configuration.

To alter the contents of a transient change, you must alter the  statements in the commit script that generates the transient change.

Interaction of Configuration Changes and Configuration Groups

Any configuration change you can make by directly editing the configuration using the Junos OS command-line interface (CLI) can also be generated by a commit script as a persistent or transient change. This includes values specified at a specific hierarchy level or in configuration groups. As with direct CLI configuration, values specified in the target override values inherited from a configuration group. The target is the statement to which you apply a configuration group by including the apply-groups statement.

If you define persistent or transient changes as belonging to a configuration group, the configuration groups are applied in the order you specify in the apply-groups statements, which you can include at any hierarchy level except the top level. You can also disable inheritance of a configuration group by including the apply-groups-except statement at any hierarchy level except the top level.

CAUTION:

Each commit script inspects the postinheritance view of the configuration. If a candidate configuration contains a configuration group, be careful when using a commit script to change the related target configuration, because doing so might alter the intended inheritance from the configuration group.

Also be careful when using a commit script to change a configuration group, because the configuration group might be generated by an application that performs a load replace operation on the group during each commit operation.

For more information about configuration groups, see the CLI User Guide .

Tag Elements and Templates for Generating Changes

To generate persistent or transient changes in commit scripts, SLAX and XSLT scripts can use the jcs:emit-change template, and Python scripts can use the jcs.emit_change method. The jcs:emit-change template and jcs.emit_change method implicitly include <change> and <transient-change> XML elements. SLAX and XSLT scripts can also generate changes by including the <change> and <transient-change> elements directly in the commit script. Using the jcs:emit-change template in SLAX and XSLT scripts allows you to set the hierarchical context of the change once rather than multiple times. In Python scripts, the jcs.emit_change method requires that the configuration data for the requested change include the full configuration path representing all levels of the configuration hierarchy formatted as an XML string.

The <change> and <transient-change> elements are similar to the <load-configuration> operation defined by the Junos XML management protocol. The possible contents of the <change> and <transient-change> elements are the same as the contents of the <configuration> tag element used in the Junos XML protocol operation <load-configuration>. For complete details about the <load-configuration> element, see the Junos XML Management Protocol Developer Guide .

Related Documentation