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

Using RPCs and Operational Mode Commands in Event Scripts

Using RPCs in Event Scripts

You can invoke remote procedure calls (RPCs) in event scripts. For each event script that invokes RPCs, you must include the remote-execution statement at the [edit event-options event-script file filename] hierarchy level. For each remote device where an RPC is executed, you must configure the SSH host key information for the that device on the local device where the event script is executed.

The remote hostnames and their corresponding username and passphrase, in addition to the event details, are passed as input to the event script when it is triggered by an event policy. For more information about the details that are forwarded to the event script, see Capturing and Using Event Details and Remote Execution Details in Event Scripts. A connection handle to the remote host is generated with the jcs:open() function using remote-hostname, username, and passphrase as arguments; for more information about this function, see open(). The following code obtains a connection handle for each remote host included in the configuration:

<xsl:for-each select="event-script-input/remote-execution-details">
    <xsl:variable name="d" select="remote-execution-detail"/>
    <xsl:variable name="connection"
            select="jcs:open($d/remote-hostname,$d/username,$d/passphrase)"/>
    ...
</xsl:for-each>

for-each (event-script-input/remote-execution-details) {
    var $d = remote-execution-detail;
    var $connection = jcs:open($d/remote-hostname,$d/username,$d/passphrase);
     ...
}

To execute an RPC on a remote device, an SSH session must be established. In order for the script to establish the connection, you must either configure the SSH host key information for the remote device on the local device where the script will be executed, or the SSH host key information for the remote device must exist in the known hosts file of the user executing the script. For each remote device where the RPC is executed, configure the SSH host key information with one of the following methods:

• To configure SSH known hosts on the local device, include the host statement, and specify hostname and host key options for the remote device at the [edit security ssh-known-hosts] hierarchy level of the configuration.
• To manually retrieve SSH host key information, issue the set security ssh-known-hosts fetch-from-server hostname configuration mode command to instruct Junos OS to connect to the remote device and add the key.
  user@host# set security ssh-known-hosts fetch-from-server router2

  The authenticity of host 'router2 (10.10.10.1)' can't be established.
  RSA key fingerprint is 30:18:99:7a:3c:ed:40:04:0f:fd:c1:57:7e:6b:f3:90.
  Are you sure you want to continue connecting (yes/no)? yes
  Warning: Permanently added 'router2,10.10.10.1' (RSA) to the list of known hosts.

• To manually import SSH host key information from a file, use the set security ssh-known- hosts load-key-file filename configuration mode command and specify the known-hosts file.
  user@host# set security ssh-known-hosts load-key-file /var/tmp/known_hosts

  Import SSH host keys from trusted source /var/tmp/known_hosts ? [yes,no] (no) yes

• Alternatively, the user executing the script can log in to the local device, SSH to the remote device, and then manually accept the host key, which is added to that user’s known hosts file. In the following example, root is logged in to router1. In order to execute a remote RPC on router2, root adds the host key of router2 by issuing the ssh router2 operational mode command and manually accepting the key.
  root@router1> ssh router2

  The authenticity of host 'router2 (10.10.10.1)' can't be established.
  RSA key fingerprint is 30:18:99:7a:3c:ed:40:04:0f:fd:c1:57:7e:6b:f3:90.
  Are you sure you want to continue connecting (yes/no)? yes
  Warning: Permanently added 'router2,10.10.10.1' (RSA) to the list of known hosts.

After configuring the required SSH host key and obtaining a connection handle to the remote device, the event script can execute RPCs with the jcs:execute() extension function on that remote device. For more information about this function, see execute(). To use an RPC in the event script, include the RPC in a variable declaration and execute it with the jcs:execute() function; the connection handle and RPC variable declaration are provided as arguments to the jcs:execute() function.

<xsl:variable name="rpc">
    <get-interface-information/> # Junos RPC for the show interfaces command
</xsl:variable>
<xsl:variable name="out" select="jcs:execute($connection, $rpc)"/>

var $rpc = <get-interface-information>;
var $out = jcs:execute($connection, $rpc);

where connection is the connection handle to the remote host. Any number of RPCs can be executed within the context of this connection handle until it is closed with the jcs:close() function.

Displaying the RPC Tags for a Command

To display the remote procedure call (RPC) XML tags for an operational mode command, enter display xml rpc after the pipe symbol ( | ).

The following example displays the RPC tags for the show route command:

<rpc-reply xmlns:junos="http://xml.juniper.net/junos/10.1I0/junos">
    <rpc>
        <get-route-information>
        </get-route-information>
    </rpc>
    <cli>
        <banner></banner>
    </cli>
</rpc-reply>

Using Operational Mode Commands in Event Scripts

Some operational mode commands do not have XML equivalents. If a command is not listed in the Junos XML API Operational Reference, it does not have an XML equivalent.

<rpc-reply xmlns:junos="http://xml.juniper.net/junos/10.0R1/junos">
   <output>
       ...
    </output>
    <cli>
        <banner></banner>
    </cli>
</rpc-reply>

Note: For some commands that have an XML equivalent, the output of the piped | display xml command does not include tag elements other than <output>, <cli>, and <banner> only because the relevant feature is not configured. For example, the show services cos statistics forwarding-class command has an XML equivalent that returns output in the <service-cos-forwarding-class-statistics> response tag, but if the configuration does not include include any statements at the [edit class-of-service] hierarchy level then there is no actual data for the show services cos statistics forwarding-class | display xml command to display. The output is something like this: user@host> show services cos statistics forwarding-class | display xml <rpc-reply xmlns:junos="http://xml.juniper.net/junos/8.3I0/junos">     <cli>         <banner></banner>     </cli> </rpc-reply> For this reason, the information in the Junos XML API Operational Reference is normally more reliable.

<xsl:variable name="query">
    <command> 
        <xsl:value-of select="concat('show host ', $hostname)"/>
    </command>
</xsl:variable>
<xsl:variable name="result" select="jcs:invoke($query)"/>
<xsl:variable name="host" select="$result"/>
<output>
    <xsl:value-of select="concat('Name: ', $host)"/>
</output>
...