How to get support information via Junos PyEZ

If you have a problem with your Juniper device, you have to inspect your device’s data – this means in most cases that you should have a look at your RSI (request support information) and log files within the /var/log folder. Especially, if you need to open a case with JTAC you have to provide RSI and the entire /var/log folder of the particular Juniper-device for getting started with the analysis of the problem. Within this blog post, I will show you how to get this information via Junos PyEZ.

Data Collection

Juniper provides several Knowledge Base articles showing you what data you should provide for different product series in general and specific problems. Please find below the link to the master article listing all the KB-articles for data collection for the different product series:

The most relevant data for starting over with the investigation are RSI and the full /var/log directory. So we will focus on this two aspects and and example with using a single vSRX.

What is the RSI?

RSI is the abbreviation for the command request support information. It includes several commands for showing the running Junos-version (show version) or the installed hardware components (show chassis hardware) etc. Since quite a lot of commands are queried, and the output is pretty long, you should save the output directly to a text file when executed via CLI through: „request support information | save /var/tmp/rsi.txt„.

How to get the RSI?

Due to we are going to use Junos PyEZ, we have to check the XML-RPC for the RSI-command. As we already know we will do this by extending the command via „| displayxml rpc„:

1

2

3

4

5

6

7

8

9

10

sbehrens@vSRX1>request support information|display xml rpc

<rpc-reply xmlns:junos="http://xml.juniper.net/junos/12.1X47/junos">

<rpc>

<get-support-information>

</get-support-information></undocumented>

</rpc>

<cli>

<banner></banner>

</cli>

</rpc-reply>

So we will use the method „dev.rpc.get_support_information()“. The problem is that you would run in a RpcTimeoutError Exception cause requesting the RSI through XML-RPC could take extremely long, and the default timeout is 30 seconds. So if you would like to get the RSI like this you should extend the timeout via „dev.timeout = 600“ to min. 10 minutes. Please find below a basic script for requesting the RSI and writing it down to the console:

But because of the long processing time (vSRX: 7mins), this way of requesting the RSI does not feel good 🙁 So we are going another way: Let’s connect to the device and write down the RSI directly to a file on the disk space of the device itself. Afterward, we will transfer the file to our local computer – transferring files to the local computer via PyEZ is also easy 🙂

Using StartShell

If you have ever checked the time difference between executing the commands „request support information | no-more“ and „request support information | save /var/tmp/rsi.txt“ you know what I mean 😉 Fortunately, Nitin Kumar has already an example of saving and transferring RSI within his PyEZ examples:

The processing time of this script is round about 30 seconds for the vSRX, so way better. We are creating an SSH client channel via „ss.open()“ because this process opens a paramiko.SSHClient instance. So we are using a separated SSH channel via Paramiko for executing the RSI command within the devices shell („start shell“) via the run()-method. The RSI-file is then transferred via SCP to our local computer.

How to get the /var/log folder?

Log messages are written down by Junos to files within the /var/log directory. So if you are investigating any issue, you should have a look at e.g. the messages file. If you want to download and provide the complete directory you have to compress the whole folder first. You can do this by executing the following command:

This command will compress the entire /var/log directory to the archive „pyez_varlog.tgz“. We are not going to use the SSH connection/shell we have opened for the RSI because we will use the Filesystem (FS) utilities:

Since especially the /var/log directory can be a huge file I have omitted the actual date within the filename. So if you execute the script multiple times, there is no risk that you fill your whole disk space with these files 🙂

Additional tweaking

We now want to transfer these files to our local computer. But before starting the file transfer we want to know how big these files are and we are also going to use the FileSystem (FS) utility for that:

1

2

3

# Get file system information

statRsi=fs.stat("/var/tmp/pyez_rsi.txt"))

statLogs=fs.stat("/var/tmp/pyez_varlog.tgz"))

As you can see the stat()-method returns some file details. If we print down „statRsi“ to the console we see that it returns the following dictionary:

We will use the information about the size during our next part. We will change the filename, including the actual date, while transfering these files to our local computer via SCP. But first we ask if we should start the transfer with showing the real file-size 😉

The size of the data will be converted into human readable string through the methode sizeof_fmt() – this is a small useful peace of code I have found on StackOverflow. If we execute the whole script we will get the following output:

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

$python3 pyez_support.py

Connection successfully...

------FILE CREATION

Starting shell forcreating RSI...

RSI done...

/var/log-compressed...

------Transfering files

File:/var/tmp/pyez_rsi.txt-Size:144.0KiB

Doyou want totransfer the RSI?(Yes,No)Yes

vSRX1:2016-12-19_10:00:18_vSRX1_rsi.txt:73728/147456(50%)

vSRX1:2016-12-19_10:00:18_vSRX1_rsi.txt:147456/147456(100%)

File:/var/tmp/pyez_varlog.tgz-Size:781.7KiB

Doyou want totransfer the/var/log?(Yes,No)Yes

vSRX1:2016-12-19_10:00:18_vSRX1_varlog.tgz:81920/800454(10%)

vSRX1:2016-12-19_10:00:18_vSRX1_varlog.tgz:163840/800454(20%)

vSRX1:2016-12-19_10:00:18_vSRX1_varlog.tgz:245760/800454(30%)

vSRX1:2016-12-19_10:00:18_vSRX1_varlog.tgz:327680/800454(40%)

vSRX1:2016-12-19_10:00:18_vSRX1_varlog.tgz:720896/800454(90%)

vSRX1:2016-12-19_10:00:18_vSRX1_varlog.tgz:800454/800454(100%)

Connection closed...

Both files are successfully transfered to the computer. Please keep in mind that this script does not handle devices with dual routing-engines. I have also uploaded the complete script to GitHub, and hopefully, this blog post is useful for you. High five, thanks for reading this blog post.

thanks 🙂 I do not know exactly what you mean. Do you mean some scripts for statistics collection? E.g. to query devices data every hour? Or do you mean you are searching for an SNMP engine for collecting SNMP traps?