Junos Automation (Scripting)
Showing results for 
Search instead for 
Do you mean 
Reply
Recognized Expert
Posts: 198
Registered: ‎03-17-2010
0 Kudos

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
Posts: 69
Registered: ‎09-14-2009
0 Kudos

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
Posts: 198
Registered: ‎03-17-2010
0 Kudos

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
Posts: 69
Registered: ‎09-14-2009
0 Kudos

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
Posts: 69
Registered: ‎09-14-2009
0 Kudos

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

Trusted Expert
Posts: 243
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
Posts: 69
Registered: ‎09-14-2009
0 Kudos

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

 

 

Trusted Expert
Posts: 243
Registered: ‎06-18-2008
0 Kudos

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
Posts: 69
Registered: ‎09-14-2009
0 Kudos

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.

Trusted Expert
Posts: 243
Registered: ‎06-18-2008
0 Kudos

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>

Contributor
Posts: 69
Registered: ‎09-14-2009
0 Kudos

Re: JUNOSCRIPT: Evaluate only proposed changes in candidate config

[ Edited ]

 

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

{master}[edit]
user@re1.rtr1# set interfaces ge-0/0/0 description "foo" 

{master}[edit]
user@re1.rtr1# show | display xml | display changed | match "\"changed\""            
    <configuration junos:changed-seconds="1285182422" junos:changed-localtime="2010-09-22 14:07:02 CDT" junos:changed="changed">
            <groups junos:changed="changed">
                <interfaces junos:changed="changed">
                    <interface junos:changed="changed">
            <groups junos:changed="changed">
                <interfaces junos:changed="changed">
                    <interface junos:changed="changed">
            <interfaces junos:changed="changed">
                <interface junos:changed="changed">
                    <description junos:changed="changed">foo</description>

 

 

OK, so that looks right to me.  However, the root level is marked 'changed', so does the foreach logic do everything under that?  I'd expect it to do just the nodes that are 'changed'.

 

Trusted Expert
Posts: 243
Registered: ‎06-18-2008
0 Kudos

Re: JUNOSCRIPT: Evaluate only proposed changes in candidate config

If all you did was modify a description of one of your interfaces that is defined in the main <interfaces> stanza then I don't know why your groups stanza's are also reporting that a change occurred. What are those groups stanza's doing that are reporting a change? Are they inheriting into the interface that you changed?

Contributor
Posts: 69
Registered: ‎09-14-2009
0 Kudos

Re: JUNOSCRIPT: Evaluate only proposed changes in candidate config

I'm not sure I understand the question. 

 

 

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

{master}[edit]
user@re1.rtr1# edit interfaces ge-0/0/0 

{master}[edit interfaces ge-0/0/0]
user@re1.rtr1# set description foo 

{master}[edit interfaces ge-0/0/0]
user@re1.rtr1# show | display xml | display changed 
<rpc-reply xmlns:junos="http://xml.juniper.net/junos/9.2R3/junos">
    <configuration junos:changed-seconds="1285186404" junos:changed-localtime="2010-09-22 15:13:24 CDT" junos:changed="changed">
            <interfaces junos:changed="changed">
                <interface junos:changed="changed">
                    <name>ge-0/0/0</name>
                    <description junos:changed="changed">foo</description>
                    <flexible-vlan-tagging/>
                    <native-vlan-id>99</native-vlan-id>
                    <encapsulation>flexible-ethernet-services</encapsulation>
                    <unit>
                        <name>99</name>
                        <description>MGMT:::10.75.252.2:</description>
                        <encapsulation>vlan-bridge</encapsulation>
                        <vlan-id>99</vlan-id>
                    </unit>
                    <unit>
                        <name>100</name>
                        <bandwidth>30m</bandwidth>
                        <vlan-id>100</vlan-id>
                    </unit>
                </interface>
            </interfaces>
    </configuration>
    <cli>
        <banner>{master}[edit interfaces ge-0/0/0]</banner>
    </cli>
</rpc-reply>        

 Above is the full output.  It appears that the interfaces heirarchy reports 'changed' because one of its nodes has changed.  Take note that looking at OTHER interfaces, they do not have 'changed'.

 

Changed attribute is found in interfaces, ge-0/0/0, and description

 

 

-Josh

 

Trusted Expert
Posts: 243
Registered: ‎06-18-2008
0 Kudos

Re: JUNOSCRIPT: Evaluate only proposed changes in candidate config

This is what I was referring to, from your earlier output:

 

<groups junos:changed="changed">
                <interfaces junos:changed="changed">
                    <interface junos:changed="changed">
            <groups junos:changed="changed">
                <interfaces junos:changed="changed">
                    <interface junos:changed="changed">

Those groups shouldn't be reporting changes if you only modified something in the interfaces hierarchy. So I'm curious how those groups are being inherited, and if that explains why they are claiming to have been modified.

Contributor
Posts: 69
Registered: ‎09-14-2009
0 Kudos

Re: JUNOSCRIPT: Evaluate only proposed changes in candidate config

Oh, I see.  There is an apply-group on the interface, however it does not include "description", and the group itself was not changed.  I only changed the physical description.

 

Notice that my logical interface for-each includes not(@junos:group), because I did not want to evaluate inherited attributes.

Trusted Expert
Posts: 243
Registered: ‎06-18-2008
0 Kudos

Re: JUNOSCRIPT: Evaluate only proposed changes in candidate config

Out of curiosity, if you do a "show | display xml | display changed | display inheritance" do the rest of the interfaces show up as changed as well?

 

I have a feeling that the reason why your groups think they have been changed is the same reason why your script is not ignorning the unchanged interfaces. What statements are being inherited by the groups? I haven't been able to replicate it on my setup, but I'm using 10.3 so it might be a version difference.

Contributor
Posts: 69
Registered: ‎09-14-2009
0 Kudos

Re: JUNOSCRIPT: Evaluate only proposed changes in candidate config

 


ccall wrote:

Out of curiosity, if you do a "show | display xml | display changed | display inheritance" do the rest of the interfaces show up as changed as well?

 

I have a feeling that the reason why your groups think they have been changed is the same reason why your script is not ignorning the unchanged interfaces. What statements are being inherited by the groups? I haven't been able to replicate it on my setup, but I'm using 10.3 so it might be a version difference.


 

It appears you are correct. It does show 'changed' on interfaces that are inheriting this group (it sets flexible-vlan-tagging, native-vlan-id, mtu, and encapsulation)

 

I suspect this isn't intended behavior, but I think I can live with it for now.  If I can nail down EXACTLY what is going on, I may try to submit it as a bug.