Rate and give feedback:  Feedback Received. Thank You!

Rate and give feedback: 

X

This document helped resolve my issue

Yes No

Additional Comments

800 characters remaining

May we contact you if necessary?

Name:  

E-mail: 

Enter a valid Email ID

Need product assistance? Contact Juniper Support

Submit

This site is protected by hCaptcha and its Privacy Policy and Terms of Service apply.

English  

English

Example: Changing the Configuration Using an Op Script

Requirements

This example uses a device running Junos OS.

Overview and Op Script

Op scripts can be used to make structured changes to the Junos OS configuration using the jcs:load-configuration template, which is included in the import file junos.xsl. Experienced users, who are familiar with Junos OS, can write scripts that prompt for the relevant configuration information and modify the configuration accordingly. This allows users who have less experience with Junos OS to safely modify the configuration using the script.

1. Locks the configuration database
2. Loads the configuration changes
3. Commits the configuration
4. Unlocks the configuration database

The jcs:load-configuration template makes changes to the configuration in configure exclusive mode. In this mode, Junos OS locks the candidate global configuration for as long as the script accesses the shared database and makes changes to the configuration without interference from other users.

If another user is currently editing the configuration in configure exclusive mode or if the database is already locked when the template is called, the call fails. In addition, if there are existing, uncommitted changes to the configuration when the template is called, the commit fails. If the template call is successful but the commit fails, Junos OS discards the uncommitted changes and rolls back the configuration.

You provide arguments to the jcs:load-configuration template to specify how to integrate the changes into the existing configuration, how to customize the commit operation, what changes to make to the configuration, and which connection handle to use. Starting with Junos OS Release 12.2, you can include the rollback parameter to return the configuration to a previously committed configuration, or you can supply a null configuration for the configuration parameter. If you supply a null configuration to jcs:load-configuration, the template performs a simple commit of the candidate configuration. The XSLT and SLAX syntax for the template call is:

 <xsl:call-template name="jcs:load-configuration">
    <xsl:with-param name="action" select="(merge | override | replace)"/>
    <xsl:with-param name="commit-options" select="node-set"/>
    <xsl:with-param name="configuration" select="configuration-data"/>
    <xsl:with-param name="connection" select="connection-handle"/>
    <xsl:with-param name="rollback" select="number"/>
</xsl:call-template>

call jcs:load-configuration($action="(merge | override | replace)",
  $commit-options=node-set, $configuration=configuration-data,
  $connection=connection-handle, $rollback=number);

The following sample SLAX script demonstrates how to use the jcs:load-configuration template to disable an interface on a device running Junos OS. All of the values required for the jcs:load-configuration template are defined as variables, which are then passed into the template as arguments.

In this example, the usage variable is initialized with a general description of the function of the script. When the script is run, the usage description is output to the CLI using a call to the jcs:output() function. This allows the user to verify that he is using the script for the correct purpose.

The script calls the jcs:get-input() function and prompts the user to enter the name of the interface that should be disabled. The interface name is stored in the interface variable. The configuration data that includes the changes to the configuration are stored in the variable config-changes. This is the value used for the configuration parameter of the jcs:load-configuration template. This variable includes the Junos XML API tags for the configuration statements that are to be modified. The variable interface, which is supplied by the user, designates the name of the interface to disable.

The load-action variable is initialized to merge, which merges the configuration changes in the disable variable with the candidate configuration. This is the equivalent of the CLI configuration mode command load merge. Other load options include replace and override.

The options variable uses the := operator to create a node-set, which is passed to the template as the value of the commit-options parameter. This example includes the log tag to add the description of the commit to the commit log file for future reference.

The call to the jcs:open() function opens a connection with the Junos OS management process (mgd) and returns a connection handle that is stored in the conn_handle variable. All of the defined variables are passed as arguments to the jcs:load-configuration template at the time that it is called.

version 1.0;

ns junos = "http://xml.juniper.net/junos/*/junos";
ns xnm = "http://xml.juniper.net/xnm/1.1/xnm";
ns jcs = "http://xml.juniper.net/junos/commit-scripts/1.0";
ns ext = "http://xmlsoft.org/XSLT/namespace";

import "../import/junos.xsl";

match / {
<op-script-results> {

    var $usage = "This script disables the interface specified by the user." _  
                         "The script modifies the candidate configuration to disable " _
                         "the interface and commits the configuration to activate it.";
    var $temp = jcs:output($usage);

    var $interface = jcs:get-input("Enter interface to disable: ");

    var $config-changes = {
        <configuration> {
            <interfaces> {
                <interface> {
                    <name> $interface;
                    <disable>;
                }
            }
        }
    }

    var $load-action = "merge";

    var $options := {
       <commit-options> {
           <log> "disabling interface " _ $interface;
        }
    }

    var $conn_handle = jcs:open();

    var $results := { 
      call jcs:load-configuration( $action=$load-action, $commit-options=$options, 
                $configuration=$config-changes, $connection=$conn_handle); 
    }

    $close-results = jcs:close($conn_handle);
}
}

The := operator copies the results of the jcs:load-configuration template call to a temporary variable and runs the node-set function on that variable. The resulting node-set is then stored in the results variable. The := operator ensures that the results variable is a node-set rather than a result tree fragment so that the script can access the contents. The jcs:close() function closes the connection.

if ($results//xnm:error) {
    for-each ($results//xnm:error) {
        <output> message;
    }
}
if ($results//xnm:warning) {
    for-each ($results//xnm:warning) {
        <output> message;
    }
}

Device Configuration

Step-by-Step Procedure

1. Copy the script into a text file, name the file config-change.slax, and copy it to the /var/db/scripts/op/ directory on the device.

2. In configuration mode, include the file statement at the [edit system scripts op] hierarchy level and config-change.slax.

   [edit system scripts op]user@host# set file config-change.slax

3. Issue the commit and-quit command to commit the configuration and to return to operational mode.

   [edit]user@host# commit and-quit
4. Before running the script, issue the show interfaces interface-name operational mode command and record the current state of the interface that will be disabled by the script.
5. Execute the op script by issuing the op config-change operational mode command.
   user@host> op config-change

   This script disables the interface specified by the user. The script modifies the candidate configuration to disable the interface and commits the configuration to activate it.
   Enter interface to disable: so-0/0/0
   

Verification

• Verifying the Commit
• Verifying the Configuration Changes

Verifying the Commit

Purpose

Verify that the commit succeeded.

Action

You should include code in your script that parses the node-set returned by the jcs:load-configuration template for any errors or warnings. This allows you to more easily determine whether the commit succeeded. If there are no warning or error messages, you can verify the success of the commit in several ways.

• Check the commit log to verify that the commit was successful. If you included the log option in the commit-options parameter, the message should be visible in the commit log along with the commit information.

  user@host> show system commit

  0   2010-09-22 17:08:17 PDT by user via junoscript
      disabling interface so-0/0/0

• Check the syslog message file to verify that the commit operation was logged. In this case, you also see an SNMP_TRAP_LINK_DOWN message for the disabled interface so-0/0/0. Depending on your configuration settings for traceoptions, this message might or might not appear in your log file.

  user@host> show log messages | last

  Sep 22 17:08:13  host file[7319]: UI_COMMIT: User 'user' requested 'commit' operation (comment: disabling interface so-0/0/0)
  Sep 22 17:08:16  host xntpd[1386]: ntpd exiting on signal 1
  Sep 22 17:08:16  host xntpd[1386]: ntpd 4.2.0-a Fri Jun 25 13:48:13 UTC 2010 (1)
  Sep 22 17:08:16  host mib2d[1434]: SNMP_TRAP_LINK_DOWN: ifIndex 526, ifAdminStatus down(2), ifOperStatus down(2), ifName so-0/0/0
  

Verifying the Configuration Changes

Purpose

Verify that the correct changes are integrated into the configuration.

Action

• Display the configuration and verify that the changes are visible for the specified interface:

  user@host> show configuration interfaces so-0/0/0

  disable;

• For this example, you also can issue the show interfaces interface-name operational mode command to check that the interface was disabled. In this case, the output captured before the interface was disabled shows that the interface is Enabled:

  user@host> show interfaces so-0/0/0

  Physical interface: so-0/0/0, Enabled, Physical link is Up
    Interface index: 128, SNMP ifIndex: 526
    Link-level type: PPP, MTU: 4474, Clocking: Internal, SONET mode, Speed: OC3, Loopback: None, FCS: 16,
    Payload scrambler: Enabled
    Device flags   : Present Running
    Interface flags: Point-To-Point SNMP-Traps Internal: 0x4000
    Link flags     : Keepalives
    CoS queues     : 4 supported, 4 maximum usable queues
    Last flapped   : 2010-09-14 10:33:25 PDT (1w1d 06:27 ago)
    Input rate     : 0 bps (0 pps)
    Output rate    : 0 bps (0 pps)
    SONET alarms   : None
    SONET defects  : None
  

  The output captured after running the script to disable the interface shows that the interface is now Administratively down:

  user@host> show interfaces so-0/0/0

  Physical interface: so-0/0/0, Administratively down, Physical link is Up
    Interface index: 128, SNMP ifIndex: 526
    Link-level type: PPP, MTU: 4474, Clocking: Internal, SONET mode, Speed: OC3, Loopback: None, FCS: 16,
    Payload scrambler: Enabled
    Device flags   : Present Running
    Interface flags: Down Point-To-Point SNMP-Traps Internal: 0x4000
    Link flags     : Keepalives
    CoS queues     : 4 supported, 4 maximum usable queues
    Last flapped   : 2010-09-14 10:33:25 PDT (1w1d 06:40 ago)
    Input rate     : 0 bps (0 pps)
    Output rate    : 0 bps (0 pps)
    SONET alarms   : None
    SONET defects  : None