Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?


Example: Specifying the Session Protocol for a Connection within Scripts

The following example demonstrates how to specify the session protocol within a Junos automation script when creating a connection with a remote device. Specifically, the example op script establishes a NETCONF session with a remote device running Junos OS, retrieves and prints the NETCONF server capabilities, and then updates and commits the configuration on that device.


  • Routing, switching, or security device running Junos OS Release 11.4 or later.

  • Client application can log in to the device where the NETCONF server resides.

  • NETCONF service over SSH is enabled on the device where the NETCONF server resides.

Overview and Script

The jcs:open() extension function includes the option to create a session either with the Junos XML protocol server on devices running Junos OS or with the NETCONF server on devices where NETCONF service over SSH is enabled. In the following example, the script creates a connection and establishes a NETCONF session with a remote device running Junos OS. If the connection and session are successfully established, the script updates the configuration on the remote device to add the ftp statement to the [edit system services] hierarchy level. The script also retrieves and prints the session protocol and the capabilities of the NETCONF server.

The script takes one argument, remote-host, which is the IP address or hostname of the remote device. The arguments variable is declared at the global level of the script so that the argument name and description are visible in the command-line interface (CLI) when a user requires context-sensitive help.

The variable netconf is a node-set that specifies the session protocol and the connection parameters for the remote device. The value of the <method> element is set to “netconf” to establish a session with the NETCONF server over an SSHv2 connection. The <username> element specifies the username for the connection. If you do not specify a username and it is required for the connection, the script uses the local name of the user executing the script. In this example, the passphrase and port are not specified. If a passphrase is required for authentication, the remote device should prompt for one during script execution. The script establishes the session using the default NETCONF port 830.

If the connection and establishment of the NETCONF session are successful, the script executes remote procedure calls (RPCs). The RPCs contain the tag elements <lock>, <edit-config>, <commit>, and <unlock>, which are NETCONF operations to lock, edit, commit, and unlock the candidate configuration. The script stores the RPC for each task in a separate variable. The results for each RPC are also stored separately and parsed for errors. The script only executes each subsequent step if the previous step is successful. For example, if the script cannot lock the configuration, it does not execute the RPCs to edit, commit, or unlock the configuration.

The variable rpc-edit-config contains the tag element <edit-config>, which is a NETCONF operation to modify a configuration. The child element, <config>, includes the modified portion of the configuration that is merged with the candidate configuration on the device. If errors are encountered, the script calls the copy-of statement to copy the result tree fragment variable to the results tree so that the error message prints to the CLI during script execution.

SLAX Syntax

XSLT Syntax



Step-by-Step Procedure

To download, enable, and test the script:

  1. Copy the XSLT or SLAX script into a text file, name the file netconf-session.xsl or netconf-session.slax as appropriate, 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 netconf-session.xsl or netconf-session.slax as appropriate.

  3. Issue the commit and-quit command.

  4. Execute the op script on the local device by issuing the op netconf-session operational mode command and include any necessary arguments.

    In this example, the user, bsmith, is connecting to the remote device, fivestar. The remote device has dual routing engines, so the commit operation returns a warning that the commit synchronize command should be used to commit the new candidate configuration to both routing engines.


Confirm that the device is working properly.

Verifying Op Script Execution


Verify that the script behaves as expected.


Review the script output in the CLI and in the op script log file. Take particular note of any errors that occurred during execution. The default op script log file is /var/log/op-script.log. If the log file is significantly lengthy, limit the display by appending the | last number-of-lines option to the show log command and specify the number of lines to print to the CLI. The output within the <op-script-results> element is relevant to the script execution.

You can also obtain more descriptive script output on a device running Junos OS by including the | display xml option when you execute an op script.


This example creates a NETCONF session on a remote device running Junos OS. The capabilities of the NETCONF server include both standard NETCONF operations and Juniper Networks proprietary extensions, which are defined in and . The RPC results for the commit operation include one warning, but the commit operation is still successful.

Verifying the Configuration Changes


Verify that the commit was successful by viewing the configuration change and the commit log on the remote device.


On the remote device, execute the show configuration system services operational mode command to view the [edit system services] hierarchy level of the configuration. If the script is successful, the configuration includes the ftp statement.

Additionally, you can review the commit log. On the remote device, execute the show system commit operational mode command to view the commit log. In this example, the log confirms that bsmith committed the candidate configuration in a NETCONF session at the given date and time.


Troubleshooting Connection Errors


The script generates the following error message:

Potential causes for the connection error include:

  • The device or interface to which you are connecting is down or unavailable.

  • The script argument for the IP address or DNS name of the remote device is incorrect.

  • The connection timeout value was exceeded before establishing the connection.

  • The user authentication for the remote device is not valid or is entered incorrectly.

  • You are trying to establish a NETCONF session, and NETCONF over SSH is not enabled on the device where the NETCONF server resides, or it is enabled on a different port.


Ensure that the remote device is up and running and that the user has access to the device. Also verify that you supplied the correct argument for the IP address or DNS name of the remote device when executing the script.

For NETCONF sessions, ensure that you have enabled NETCONF over SSH on the device where the NETCONF server resides. Since the example program does not specify a specific port number for the NETCONF session, the session is established on the default NETCONF-over-SSH port, 830. To verify whether NETCONF over SSH is enabled on the default port for a device running Junos OS, enter the following operational mode command on the remote device:

If the netconf configuration hierarchy is absent on the remote device, issue the following statements in configuration mode to enable NETCONF over SSH on the default port:

If the netconf configuration hierarchy specifies a port other than the default port, include the port number in the XML node-set that you pass to the jcs:open() function. For example, the following device is configured for NETCONF over SSH on port 12345:

To create a NETCONF session on the alternate port, include the new port number in the XML node-set.

Troubleshooting Configuration Lock Errors


The script generates one of the following error messages:


Another user currently has a lock on the candidate configuration or has modified the candidate configuration but has not yet committed the configuration. Wait until the lock is released, and then execute the program.

Troubleshooting Configuration Syntax Errors


The following error message prints to the CLI:

Examine the result tree for additional information. In this case, the result tree shows the following error message:


The <bad-element> tag element indicates that the configuration statement is not valid. Correct the configuration hierarchy and run the script. In this example error, the user entered the tag <ftp2> instead of <ftp>. Since that is not an acceptable element in the configuration, the NETCONF server returns an error.