CLI live-status command on NETCONF devices

[yfherzog]

Hi,

We're using Junos devices with the Junos NED.

For some tests  we run in NSO towards the devices, we require live data that should be fetched from the device.

For some of the information, there's no adequate RPC on the device, so we would like to fetch this data using CLI show commands

Is there a way to have NSO execute show commands on such device using CLI (SSH)?

If so, how can it be done.

Thanks,

Yftach

[michal.plesko@gmail.com]

Hi Yftach,

from some junos release all show cli commands should have rpc equivalent, have you tried to look this way?

show interfaces descriptions | display xml rpc

  rpc-reply xmlns:junos=__"http://xml.juniper.net/junos/15.1R5/junos">

     <rpc>

         <get-interface-information>

                 <descriptions/>

         </get-interface-information>

     </rpc>

     <cli>

         <banner>{master:1}</banner>

     </cli>

  /rpc-reply>

[yfherzog]

Thank you Michal!

The question I'm facing is, basically, how to address retrieval of outputs which are not available through an RPC?

I don't have the details for the exact command required in this case, but I wanted to know if there's a generic way to address this kind of situation, where a required output cannot be retrieved using any RPC on the device.

But anyway, I will suggest the command you provided here to the network engineers, as I believe the generic issue I described above can indeed be avoided in many cases.

Thanks,

Yftach

[mmalysz]

Hi Yftach,

We should try to use this settings for live-status-protocol so that we use NETCONF NED for the configuration and CLI for operdata...

list live-status-protocol {

        tailf:info "Additional protocols for the live-tree (read-only)";

        key name;

        description

          "It is possible to have additional NEDs speaking

           southbound to the managed device for the device's

           'live-status' tree.

           All configuration data must be handled by one NED, but

           multiple NEDs can be used for the 'live-status' tree.

           For example a CLI NED can be used for 'show routes'

           and the SNMP NED for some additional MIBs";

[yfherzog]

Hi Maciej,

Yes. I saw this before writing this post.

But trying to play around with it, it indeed appeared to me as it will require another NED in order to have live-status running from CLI.

I wonder if there are any easy ways to make use of this option, or any other easy alternatives.

[rogaglia · Accepted solution]

Hi,

Today the option is to run NETCONF live-status, RPCs (particularly for Juniper) or SNMP.

Theoretically, we would like all NETCONF implementations to add all status information in a "config false" structure but we know it will take time to get feature parity.

In the meantime, we could implement a live-status NED to implement "show" commands in NETCONF devices via SSH. However, I have not been able to convince engineering to create such a NED...maybe you could give more info to better build my case.

Regards,

Roque

[yfherzog]

Thank you Roque for confirming!

I believe this is the way we will go forward at the moment for whatever we cannot achieve with RPCs.

Yftach

[Hiro Takahashi]

Hello,

I always use following action for Juniper devices to obtain CLI outputs via SSH.

[YANG]

    tailf:action check-cli {

      tailf:exec "/home/cisco/cli.sh";

      input {

        leaf command {

          type string;

        }

      }

      output {

        leaf output {

          type string;

        }

      }

    }

[cli.sh]

#!/bin/bash

echo output '"'

sshpass -p password ssh cisco@192.168.1.1 $2

echo  '"'

Hope this helps.

Best regards,

Hiro

[yfherzog]

Thank you for the suggestion.

I guess that device address and also credentials will have to be obtained from somewhere - either provided as input or fetched from CDB somehow.

Is that right?

Thanks,

Yftach

[Hiro Takahashi]

That is correct. Without Python or Java, you should be able to generalize the codes as follows.

[YANG]

    tailf:action check-cli {

      tailf:exec "/home/cisco/cli.sh";

      input {

        leaf host {

          type string;

        }

        leaf username {

          type string;

        }

        leaf password {

          type string;

        }

        leaf command {

          type string;

        }

      }

      output {

        leaf output {

          type string;

        }

      }

    }

[cli.sh]

#!/bin/bash

echo output '"'

sshpass -p $4 ssh $3@$2 $5

echo  '"'

If you use Python or Java, then you can retrieve values directly from CDB.

Best regards,

Hiro

[gusmb]

How would you obtain the credentials from the CDB using Python? 

I could read the authgroup information, but the password is not stored in clear text...

Thanks for the help

[gusmb]

Nevermind, I found the solution using _ncs.decrypt() method.

[kristian.larsson1]

Your question is based on incorrect assumptions. Given the way JUNOS is built *ALL* CLI show commands are available over the NETCONF interface. As has been suggested already in this thread you can run any command in the JUNOS CLI and append "| display xml rpc" to get the RPC name. Again, all commands are modelled as RPCs so there can literally be no commands on the device that you cannot retrieve information from via NETCONF.

In JUNOS versions prior to v17 all operational state is available only through RPCs, i.e. to get interface counters or BGP neighbors you have to issue an RPC.

In JUNOS v17 some information is now available as "config false", i.e. it is correctly modeled as operational state. More will come.

Anyway, assuming you have an older version and you want to get the RPC working, after finding out what the RPC is called you need to add it to the YANG model in the JUNOS NED you are using. You can of course open a support ticket to have Cisco add it for you or you can do it yourself. Unfortunately you kind of have to model it blind, or take a guess at the data. Get the data from the device (using netconf-console for example) look at the data and try to reverse that into a YANG model. Once you've done that, you can load up the model in NCS and run `request devices device X rpc ....` to get your data!

[yfherzog]

Thank you Kristian for the detailed explanation!

In reality, we seem to have a slightly different problem.

What we're trying to do is to run a script on the device, and this is indeed supported through an RPC on the device, which is also implemented in the NED (rpc op-script).

The problem is that we're interested in the output of that script, and this is where the problem appears:

Looking at the NED implementation, the output of the RPC is not modeled, and the reason for that seems to be that the nature of the output of this RPC cannot be standardized as every script might have its own format of output.

If we look at the junos-rpc.yang file under the NED, we see that the output node does not exist.

And so, when we use this RPC, the NED does not expect any output and so no return value is captured.

I did a very simple test, and added an output statement on the RPC on the NED:

output {

     leaf output {

          type string;

     }

}

I recompiled and reloaded the NED and this seems to have done the trick.

However, we're not certain that we want to work with a customized NED.

Yftach