How to Avoid Potential Conflicts When Using Multiple Commit Scripts

When you use multiple commit scripts, each script evaluates the original candidate configuration file. Changes made by one script are not evaluated by the other scripts. This means that conflicts between scripts might not be resolved when the scripts are first applied to the configuration. The commit scripts are executed in the order they are listed at the [edit system scripts commit] hierarchy level, as illustrated in Figure 1.

Figure 1: Configuration Evaluation by Multiple Commit Scripts

As an example of a conflict between commit scripts, suppose that commit script A.xsl is created to ensure that the device uses the domain name server with IP address 192.168.0.255. Later, the DNS server’s address is changed to 192.168.255.255 and a second script, B.xsl, is added to check that the device uses the DNS server with that address. However, script A.xsl is not removed or disabled.

Because each commit script evaluates the original candidate configuration, the final result of executing both scripts A.xsl and B.xsl depends on which DNS server address is configured in the original candidate configuration. If the now outdated address of 192.168.0.255 is configured, script B.xsl changes it to 192.168.255.255. However, if the correct address of 192.168.255.255 is configured, script A.xsl changes it to the incorrect value 192.168.0.255.

As another example of a potential conflict between commit scripts, suppose that a commit script protects a hierarchy using the protect attribute. If a second commit script attempts to modify or delete the hierarchy or the statements within the hierarchy, Junos OS issues a warning during the commit process and prevents the configuration change.

Exercise care to ensure that you do not introduce conflicts between scripts like those described in the examples. As a method of checking for conflicts with persistent changes, you can issue two separate commit commands.