Junos OS

Hello, 
We planning to do JunOS upgrade from 14.1X53 to 18.1R3-S6.
- I am aware of recommended Juniper way of splitting the VC to two parts and rerouting traffic via one while upgrading the other and vice versa,
- I am also aware that we need to upgrade to (17.1R1-S7_for example) first and then to 18.1R3-S6 as you can not skip 3 main versions.
- I am also aware that NSSU is neither supported for such upgrade neither recommended.

My question:
I put both images in /var/tmp on the master, and planning to copy them to members then upgrade to 17.1x first then to 18.1x.
Will that work, I mean having both images in /var/tmp or after the first upgrade to 17.1x, /var/tmp will be erased?

I am doing that because I have only remote console access, no local FTP server or any other network connections, I asked local IT guy to run FTP server on his laptop and connect to mgmt port which I configured in advance and copied the images, but I want to avoid asking his support every time I want to upgrade/downgrade to one of these 3 images (14, 17, 18).
As we want to do few tests regarding upgrade and downgrade procedures before connecting these switches to production.

Can I use /var/tmp for storing them for a while? if not, is there other directory can work for that?

below some folders with enough space:
fpc0:
--------------------------------------------------------------------------
Filesystem Size Used Avail Capacity Mounted on

/dev/md10 1.1G 12K 999M 0% /tmp
/dev/ad1s1d 1.9G 98K 1.8G 0% /var/tmp
/dev/ad3s1 1006M 4.0K 926M 0% /user

Hi Alex_Sk,

First, let me tell you taht Juniper best recommendation now in order to do the upgrade is testing the configuration before the upgrade instead of avoiding more than 2 jumps, for example,

Instead of going to 17 first, it will be better if you test the configuraiton on the lab using version 18, once you have confirmed that the configuraiton is working you can then proceed with the upgrade with no middle jumps.

The reason of this is that QFX platforms have no validate feature for the upgrade,

https://kb.juniper.net/InfoCenter/index?page=content&id=TSB17508&actp=METADATA

For this reason doing the upgrade without testing the config might give you commit errors that will lead to the platform hanging on the new code, most common errors are,

*ssh root-login allow (is a must on 16 code and above)

*interfaces under RSTP need to be family ethernet-switching or you get a commit error.

So, as mentioned test the configuraiton first and you should not face any issues even going directly to 18.

Please mark as "Solved" if this worked for you so we can help others too.

Regards,

Jeff

Thanks Jeff, will note that, what about the part related to the storage: 

--

My question:
I put both images in /var/tmp on the master, and planning to copy them to members then upgrade to 17.1x first then to 18.1x.
Will that work, I mean having both images in /var/tmp or after the first upgrade to 17.1x, /var/tmp will be erased?

I am doing that because I have only remote console access, no local FTP server or any other network connections, I asked local IT guy to run FTP server on his laptop and connect to mgmt port which I configured in advance and copied the images, but I want to avoid asking his support every time I want to upgrade/downgrade to one of these 3 images (14, 17, 18).
As we want to do few tests regarding upgrade and downgrade procedures before connecting these switches to production.

Can I use /var/tmp for storing them for a while? if not, is there other directory can work for that?

below some folders with enough space:
fpc0:
--------------------------------------------------------------------------
Filesystem Size Used Avail Capacity Mounted on

/dev/md10 1.1G 12K 999M 0% /tmp
/dev/ad1s1d 1.9G 98K 1.8G 0% /var/tmp
/dev/ad3s1 1006M 4.0K 926M 0% /user

Hello Alex,

Greetings,

Your question:- put both images in /var/tmp on the master, and planning to copy them to members then upgrade to 17.1x first then to 18.1x.
Will, that work, I mean having both images in /var/tmp or after the first upgrade to 17.1x, /var/tmp will be erased?

Explanation:- Yes, you can store both the images on /var/tmp on the master. Once, you push the 17.1X image to respective nodes, add, validate, and upgrade the virtual chassis. Then only 17.1X images will be deleted from the /var/tmp directory. 18.1x image and other files are not affected by the 17.1x upgrade. You will find the 18.x image on the /var/tmp directory after the 17.1x upgrade.

Also, I see in /var/tmp you have 1.8 G available space. I would recommend you to go with /var/tmp to keep the images for the upgrade. Once the upgrade is done, only the specified image used for upgrade/downgrade is deleted from the /var/tmp directory.

I hope this helps. Please mark "Accept as solution" if this answers your query. 

Kudos are appreciated too! 

Best Regards,

Lingabasappa S H

Thanks a lot for the explination, that's very interesting to know. 

What about if later I wanted to downgrade to one of the previous images, they will be deleted from /var/tmp after every upgrade so can I in this case save them in these folders: 

/dev/md10 1.1G 12K 999M 0% /tmp
/dev/ad3s1 1006M 4.0K 926M 0% /user

will they affect anything on the switch? will they stay there after any upgrade?

Hey Alex,

The command to add the image to upgrade is:-

'request system software  add <file_path> 

After a successful upgrade, the image from the above-specified path is deleted automatically.

In case you want to downgrade/upgrade to the previous image, you must store the image in other directories other than the before above-used file_path.

In your case, you need to keep at least 2 copies of the image in the device saved in different directories. 

Use the directory /tmp for storing the other copy of the specified image. when you want to downgrade/upgrade to that version. Use the command:- request system software  add /tmp 

To answer your query, there will not be any impact on the switch if you perform the above action to upgrade. Yes, they will stay after the upgrade when you use a different file path for the upgrade.

Note:- The specified directory should at least have 400-500 MB extra space to unzip the image package file and perform a smooth upgrade.

Alternatively, we can use the "request system snapshot" to save the image and file system. But in QFX5100 we mandatorily need to have USB inserted in the switch.

Use the” request system snapshot ” command to create a snapshot of the partition, this can be done only when a media/usb is inserted to the switch itself.

I hope this helps. Please mark "Accept as solution" if this answers your query. 

Kudos are appreciated too! 

Best Regards,

Lingabasappa S H

Thanks Lingabasappa, 

I tried it but unfortunately it is not correct 😞 

Before the upgrade from 14 > 17, I put images like this : 

---------------------------------------------------

> file list /var/tmp detail

-rw-r--r-- 1 root field 572653145 May 6 19:19 jinstall-host-qfx-5-17.1R1-S7.1-signed.tgz
-rw-r--r-- 1 root field 608516263 May 6 19:29 jinstall-host-qfx-5-18.1R3-S6.1-signed.tgz

> file list /tmp detail

-rw-r--r-- 1 root wheel 462725966 May 6 21:38 jinstall-qfx-5-14.1X53-D46.7-domestic-signed.tgz

> file list /user detail

-rw-r--r-- 1 root wheel 572653145 May 6 23:19 jinstall-host-qfx-5-17.1R1-S7.1-signed.tgz

After the upgrade completed: 

---------------------------------------------------

Filesystem Size Used Avail Capacity Mounted on

/dev/md13 63M 8.0K 58M 0% /tmp

/dev/ad1s1d 1.9G 16K 1.8G 0% /var/tmp

Both images 18.1x & 14.1x which I put in \var\tmp and \tmp were deleted :((

the only image left is 17.1x in \user which I put for test. 

Now I can't upgrade to 18 nor downdrade to 14 without local help to connect with PC with FTP so I can copy the images there. 

Hi Alex_Sk, 

Greetings, 

As per my understanding, if you did not use the no-copy while adding the image with "request system soft.." then the image should be in the location : /var/sw/pkg . Just give it a try to check the contents of this. 

Also, you can try going back to the older version with a snapshot using the command: request system software rollback

Link: https://www.juniper.net/documentation/en_US/junos/topics/reference/command-summary/request-system-software-rollback.html

Please mark "Accept as solution" if this answers your query. 

Kudos are appreciated too! 

Regards, 

Sharat Ainapur

Hello Alex,

Apologies for the inconvenience caused.

I have come across many instances, where we have to do a step upgrade[14.1 X-17.1X-18.1X]. The customer chooses to push both the images before starting the upgrade into the /var/tmp directory. After the first upgrade i.e., 14.1X to 17.1 X, we were able to see the 18.1 X image present in /var/tmp.

But, this behavior I have seen in Routing products and a stand-alone switch. Hence, I thought that this will even work in Virtual chassis. Unfortunately, it didn't work. Virtual chassis involves pushing the image to each node and then upgrading, which is slightly different from normal procedure.

Now, try to perform the steps suggested by Sharat in the comment section and see if you can go back to the previous version.

 If you did not use the no-copy while adding the image with "request system soft.." then the image should be in the location : /var/sw/pkg . Just give it a try to check the contents of this. 

Also, you can try going back to the older version with a snapshot using the command: request system software rollback

Link: https://www.juniper.net/documentation/en_US/junos/topics/reference/command-summary/request-system-software-rollback.html

Best Regards,

Lingabasappa H

Thanks a lot guys that helped. 

Actully  before this test I isolated one switch (S2) from the VCF to try on it first the on the VCF, and I  put the images in /var/tmp and /tmp and /user as I mentioned before and after upgrade to 17.1x tmp folder were empty and S2 became a linecard.

(why S2 bacme a linecard? because he was isolated and has nothing connecting to it? before the isolation it was configured as backup RE so I thought, it shoud become a standalone master after isolation but that did't happen)

I used this command for the upgrade: 

request system software add validate reboot /var/tmp/jinstall-host-qfx-5-17.1R1-S7.1-signed.tgz

and after your last advice I checked  /var/sw/pkg

> file list /var/sw/pkg detail

/var/sw/pkg:
total blocks: 8
total files: 0

{linecard:1}

seems to be empy as well then I tried the command you suggested and it worked: 

> request system software rollback 
fpc1:
--------------------------------------------------------------------------
JUNOS version "14.1X53-D46.7-domestic-201907112157" will become active at next reboot

{linecard:1}

> request system reboot

and it rebooted with the old one, I enabled VCP ports and joined it again to the old VCF 🙂

so after this test seems I can store addtional images only in /user and they will stay there afer the upgrade. 

so I can distrbute the 3 images on members and put them in  /users  so I will always have them when needed during my tests. 

---- 

My next tests will be to 

- isolate one switch (S2) and upgrade directly to 18.x , in case of failure I can rollback to 14 and join him again

- if succeeded, I will do that to whole old VCF, upgrade to 18 and then join S2. 

-Putting the image on the master only and upgrading/downgrading the whole VCF

Hi Alex_sk, 

Greetings, 

Request you to mark the solution for the queries you post as accepted if it answered your query/queries.

This would enable others to find the right solution for the same/similar queries on the forum.

Mark "Accept as solution" if my post answered your query. 

Regards, 

Sharat Ainapur

Hello Alex,

Thanks for explaining the whole situation to us and resolving the issue. I am glad that I and Sharat were able to help you. Please perform the next actions and verify if everything goes well.

Please mark "Accept as solution" to help others to go through the forum for a similar issue.

Best Regards,

Lingabasappa H