Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?


Example: Changing the Configuration Using SLAX and XSLT Op Scripts

This example explains how to make structured changes to the Junos OS configuration using a SLAX op script.

Device Configuration

Step-by-Step Procedure

To download, enable, and test the script:

  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, configure the script’s filename at the [edit system scripts op file] hierarchy level.

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

  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.


This example uses a device running Junos OS.

Overview and Op Script

SLAX and XSLT op scripts can use the jcs:load-configuration template, which is located in the junos.xsl import file, to make structured changes to the Junos OS configuration. This example creates a SLAX op script that uses 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.

In this example, the usage variable is initialized with a general description of the function of the script. When you run the script, it calls the jcs:output() function to output the usage description to the CLI. This enables you to verify that you are using the script for the correct purpose.

The script calls the jcs:get-input() function, which prompts for the name of the interface to disable, and stores the interface name in the interface variable. The config-changes variable stores the Junos XML configuration data to load on the device and references the interface variable. The jcs:load-configuration template call sets the value of the configuration parameter to the data stored in the config-changes variable.

The load-action variable is set to merge, which merges the new configuration data with the candidate configuration. This is the equivalent of the CLI configuration mode command load merge.

The options variable defines the options for the commit operation. It 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 for future reference.

The call to the jcs:open() function opens a connection with the Junos OS management process (mgd) on the local device and returns a connection handle that is stored in the conn variable. The script then calls the jcs:load-configuration template.

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 to the device. By default, the jcs:load-configuration template does not output messages to the CLI. This example searches for and prints xmn:warning and xnm:error messages in the response to quickly identify any issues with the commit.

SLAX Syntax


Verifying the Commit


Verify that the commit succeeded.


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.

  • 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.

Verifying the Configuration Changes


Verify that the correct changes are integrated into the configuration.


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

  • 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.

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