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 one of the following types:
-
persistent—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. -
transient—A transient change 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 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.
Persistent Changes |
Transient Changes |
---|---|
You can represent a persistent change in commit scripts by using
the SLAX and XSLT commit scripts can also represent a persistent
change by using the |
You can represent a transient change in commit scripts with
the 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. |
In order to load transient changes, you must configure the
If you enable a commit script that generates transient changes and you do not
include the Like persistent changes, transient changes must pass the standard Junos OS validity check. |
Persistent changes work like the When generating a persistent change, if you add the |
Transient changes work like the 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 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 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 |
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 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
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 .