Junos Automation (Scripting)
Reply
Recognized Expert
Mattia
Posts: 198
Registered: ‎03-17-2010
0

Re: JUNOSCRIPT: Evaluate only proposed changes in candidate config

Hi Josh,

 

I will provide you both the slax and Perl example;

Slax:

 

var $get-configuration = <get-configuration compare="rollback" rollback="0">;
var $configuration = jcs:invoke( $get-configuration );

 Perl:

 

$query = "get_configuration";
my %query_args = (compare => 'rollback', rollback => '0');
my $res = $jnx->$query(%query_args); # $jnx is your junos device instance

 

 

The $configuration and $res variable will contain only the changed configuration elements (i.e. the output of "show | compare rollback 0" CLI command).

 

 

If you invoke the get-configuration API element with the attributes

database="candidate" changed="changed"

the output will contain all the candidate configuration, with the changed elements marked with the "changed" tag.

 

Please note that in order to let the perl script work properly you will have to manually edit the "Methods.pm" file of the Perl module, as described in the post http://forums.juniper.net/t5/Junos/Perl-API-Determining-if-there-is-any-pending-candidate/td-p/36811...

 

I hope this will help you,

 

Mattia

 

 

 

.................................................................................
JNCIP-ENT, JNCIP-SEC, JNCIS-SP
(If this post helped you, please mark it as an "Accepted Solution"; kudos are also appreciated!)


Contributor
JoshTX
Posts: 64
Registered: ‎09-14-2009
0

Re: JUNOSCRIPT: Evaluate only proposed changes in candidate config

Since I have only dealt with slax, I'd really appreciate your example.  Thank you for the links.

 

 

Recognized Expert
Mattia
Posts: 198
Registered: ‎03-17-2010
0

Re: JUNOSCRIPT: Evaluate only proposed changes in candidate config

[ Edited ]

Hi Josh,

 

you can take a look at this post: http://forums.juniper.net/t5/Junos/Perl-API-Determining-if-there-is-any-pending-candidate/td-p/36811

The method  <get-configuration compare="rollback" rollback="0"/>, will return you the candidate configuration.

 

To retrieve the changed configuration elements marked with a "changed" tag, you can use the same command, this time invoking it with the  changed = "changed" and database = "candidate" attributes (cfr http://www.juniper.net/techpubs/software/junos/junos102/junoscript-guide/id-10623523.html for further information)

 

Let me know if you need further help, I can post the code I used in order to retrieve the candidate config in a Perl script, the slax syntax is not very different!

 

Mattia

 

 

 

.................................................................................
JNCIP-ENT, JNCIP-SEC, JNCIS-SP
(If this post helped you, please mark it as an "Accepted Solution"; kudos are also appreciated!)


Contributor
JoshTX
Posts: 64
Registered: ‎09-14-2009
0

JUNOSCRIPT: Evaluate only proposed changes in candidate config

[ Edited ]

In a commit script, is it possible to see just the proposed changes since rollback 0, or maybe some flag that tells me an element in the hierarchy is different than the active config?

 

If so, can you provide a simple example of how to test.  For example, if ge-0/0/0 description "OLD", and ge-0/0/1 description "PROPOSED", I'd like to print to the user all descriptions of interfaces that are different than the active config at time of commit.

 

Thanks much,

Josh

Contributor
JoshTX
Posts: 64
Registered: ‎09-14-2009
0

Re: JUNOSCRIPT: Evaluate only proposed changes in candidate config

I've experienced a great deal of trouble applying this to an existing script that we've been using that enforces a interface description standard.  Since I'm introducing the script into a network that may have several hundred interfaces that currently may or may not abide by our standard, I'd like to start by evaluating only proposed changes, and allow all the existing config to be 'grandfathered in'

 

Would you mind looking at this script as an example and suggest how I'd modify it to accomplish this goal?

 

Since I'm posting the entire script, as is, I'd appreciate additional comments on how I could make it more efficient or 'cleaner' as well.

 

We're running this on MX series routers.

 

Thanks much,

Josh

Recognized Expert
ccall
Posts: 230
Registered: ‎06-18-2008

Re: JUNOSCRIPT: Evaluate only proposed changes in candidate config

Josh, the method described returns an ascii representative of the changes, which might be difficult to parse from within a script. Perhaps a better method in your case would be to look for the presence of the junos:changed attribute, which is always present for nodes that have been changed since the last commit. (It could also be present for nodes that have not changed since the last commit, but have changed since the last warning free commit, so it's presence isn't a perfect indication that the node has changed; however, its absence is a perfect indication that the node has not changed).

 

So, you could do something like this:

 

for-each (interfaces/interface[starts-with(name, $int-search)][ @junos:changed ]   ) {

 

Also, you mentioned you were interested in other feedback. This line:

 

if (not($fields[5]) || $fields[6]) {

 

Could probably be replaced with this line to make it more clearer:

 

if( count( $fields ) != 5 )

 

And are you sure you only want this to be done when run on re0? What if a different RE is the master, or if re0 is not present? Is there some harm that would come by removing the RE check and having all the REs make the same consistent check?

Contributor
JoshTX
Posts: 64
Registered: ‎09-14-2009
0

Re: JUNOSCRIPT: Evaluate only proposed changes in candidate config

[ Edited ]

 


ccall wrote:

Could probably be replaced with this line to make it more clearer:

 

if( count( $fields ) != 5 )


 

Much clearer.

 

 


ccall wrote:

And are you sure you only want this to be done when run on re0? What if a different RE is the master, or if re0 is not present? Is there some harm that would come by removing the RE check and having all the REs make the same consistent check?


 

I believe I did this originally to try and cut down the commit script run time.  On a box with a large config, it takes some time.  There is no harm in removing it.  My greater concern is if there is harm in having the RE check in place the way I do now.

 

 


ccall wrote:

So, you could do something like this:

 

for-each (interfaces/interface[starts-with(name, $int-search)][ @junos:changed ]   ) {


This did not work as anticipated.  First I applied the new script, and did a commit check, which passed (presumably because there were no changes in the config.)  Next I made a minor change to one interface (ge-0/0/0) which I expected to NOT error on that interface, and it errored on several other interfaces which I did not change the configuration for.

 

 

error: ge-0/0/1 description not standard: Incorrect number of fields
error: ge-0/1/0 description not standard: Incorrect number of fields
error: ge-0/1/1 description not standard: Incorrect number of fields
error: ge-0/1/2 description not standard: First field is invalid
error: ge-0/0/0.99 description not standard: Incorrect number of fields
error: ge-0/0/0.100 description not standard: Incorrect number of fields
error: ge-0/0/1.99 description not standard: Incorrect number of fields
error: ge-0/0/1.105 description not standard: Incorrect number of fields
error: ge-0/1/0.99 description not standard: Incorrect number of fields
error: ge-0/1/1.99 description not standard: Incorrect number of fields
error: ge-0/1/1.1985 description not standard: Incorrect number of fields
error: ge-0/1/2.99 description not standard: Incorrect number of fields
error: 12 errors reported by commit scripts
error: commit script failure

 

 

I removed the RE check, and also added the recommend field count change above.  Here are the for-each statements I have for the physical and the logical (best I could figure to parse each separately, since I have different requirements for each)

 

 

        for-each (interfaces/interface[starts-with(name, $int-search)][ @junos:changed] ) {

 

        for-each (interfaces/interface[starts-with(name, $int-search)][ @junos:changed ]/unit[ not( @junos:group )]) {

 

The latest revision is attached.

 

I appreciate your insight,

Josh

 

 

Recognized Expert
ccall
Posts: 230
Registered: ‎06-18-2008
0

Re: JUNOSCRIPT: Evaluate only proposed changes in candidate config

The script looks fine so the behavior you mentioned is interesting. What do you see after you make a similar change and execute the following in configuration mode?

 

show | display xml | display changed

 

Only the interface you modified should show the change. (And it's ancestors) Is that not the case?

Contributor
JoshTX
Posts: 64
Registered: ‎09-14-2009
0

Re: JUNOSCRIPT: Evaluate only proposed changes in candidate config

It appears that the entire config shows with the 'changed' attribute.

 

 

{master}[edit]
user@re1.rtr1# rollback                                    
load complete

{master}[edit]
user@re1.rtr1# show | display xml | display changed | count 
Count: 11640 lines

 

 

 

I'm running JUNOS 9.2R3.5 on this MX.

Recognized Expert
ccall
Posts: 230
Registered: ‎06-18-2008
0

Re: JUNOSCRIPT: Evaluate only proposed changes in candidate config

Ah, just a word of explanation: the "| display changed" option does not only show the changed elements. What it does is add the junos:changed attribute to the appropriate ones:

 

[edit interfaces fe-0/0/2]
jnpr@srx210# show | display xml | display changed
<rpc-reply xmlns:junos="http://xml.juniper.net/junos/10.3R1/junos">
    <configuration junos:changed-seconds="1285175081" junos:changed-localtime="2010-09-22 17:04:41 UTC" junos:changed="changed">
            <interfaces junos:changed="changed">
                <interface junos:changed="changed">
                    <name>fe-0/0/2</name>
                    <mtu junos:changed="changed">1500</mtu>
                    <unit>
                        <name>0</name>
                        <family>
                            <inet>
                                <address>
                                    <name>192.168.1.1/24</name>
                                </address>
                            </inet>
                        </family>
                    </unit>
                </interface>
            </interfaces>
    </configuration>
    <cli>
        <banner>[edit interfaces fe-0/0/2]</banner>
    </cli>
</rpc-reply>

Copyright© 1999-2013 Juniper Networks, Inc. All rights reserved.