The returned configuration, however, might not be the actual configuration running on the device if commit scripts are deployed and they have made transient configuration changes.

This divergence is possible because, rather than being reflected in the committed configuration, transient configuration changes only affect the configuration that is provided to daemons. This means that when the <get-configuration> RPC pulls the committed configuration, it does not see the transient changes introduced by commit scripts because they never actually appear in that configuration.

Here is an example that demonstrates the issue. In this scenario, two static routes are present:

1	jnpr@srx210> show route protocol static
2	inet.0: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden)
3	+ = Active Route, - = Last Active, * = Both
4	 
5	0.0.0.0/0          *[Static/5] 00:26:41
6	                      Discard
7	10.0.0.0/8         *[Static/5] 02:01:14
8	                      Discard

Now, assume an op script wants to work with the routing-options configuration, so the script requests it in this manner:

1	var $rpc = {
2	    <get-configuration inherit="inherit" database="committed"> {
3	        <configuration> {
4	            <routing-options>;
5	        }
6	    }
7	}
8	 
9	var $routing-options-config = jcs:invoke( $rpc );

With two static routes present on the system, you might expect to see two static routes in the configuration. However, only one is visible:

01	<configuration> {
02	    <routing-options> {
03	        <static> {
04	            <route> {
05	                <name> "10.0.0.0/8";
06	                <discard>;
07	            }
08	        }
09	    }
10	}

As you might guess, the reason why only one statis route is visible is due to a commit script that is transiently adding the 0.0.0.0/0 route:

01	match configuration {
02	    <transient-change> {
03	        <routing-options> {
04	            <static> {
05	                <route> {
06	                    <name> "0.0.0.0/0";
07	                    <discard>;
08	                }
09	            }
10	        }
11	    }
12	}

So what is the solution? This problem was originally documented in PR 444398, which also mentions a possible workaround.

However, the workaround is no longer necessary as of Junos OS Release 12.1 because two new values have been added for the commit-scripts attribute of the <get-configuration> RPC:

• "apply"
• "apply-no-transients"

Of the two, the "apply" option is useful in this scenario. It processes any configured commit scripts before returning the configuration, allowing the modified configuration to be viewed by scripts, including both transient and permanent changes.

In Junos OS Release 12.1 and beyond, the op script can use the following <get-configuration> RPC call:

1	var $rpc = {
2	    <get-configuration inherit="inherit" database="committed" commit-scripts="apply"> {
3	        <configuration> {
4	            <routing-options>;
5	        }
6	    }
7	}
8	 
9	var $routing-options-config = jcs:invoke( $rpc );

Now the transient changes are visible to the op script:

01	<configuration> {
02	    <routing-options> {
03	        <static> {
04	            <route> {
05	                <name> "10.0.0.0/8";
06	                <discard>;
07	            }
08	            <route> {
09	                <name> "0.0.0.0/0";
10	                <discard>;
11	            }
12	        }
13	    }
14	}