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
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
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
replace attribute are merged into the
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
You can represent a persistent change in commit scripts by using
SLAX and XSLT commit scripts can also represent a persistent
change by using the
You can represent a transient change in commit scripts with
SLAX and XSLT commit scripts can also represent a transient
change by using the
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
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
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:
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.
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 method implicitly include
<transient-change> XML elements. SLAX and XSLT scripts can also generate changes by
<transient-change> elements directly in the commit
script. Using the
in SLAX and XSLT scripts allows you to set the hierarchical context
of the change once rather than multiple times. In Python scripts,
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.
<transient-change> elements are similar to the
<load-configuration> operation defined by the Junos
XML management protocol. The possible contents of the
<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
<load-configuration> element, see
the Junos XML Management Protocol Developer Guide .