Switching

Hi,

I have a 3 member QFX5100 VC in production environment and I would like to update the JunOS image on it. The current version is 14.1X53-D40.8 and the future one will be 18.4R2-S3, which is the recommended version. I would like to know the following:

1. What is the best practise to upgrade a QFX VC with as less impact as possible? I found this Juniper guide to upgrade. Is this a good solution?

2. Can I upgrade directly from 14.1 to 18.4? What is the recommended update path?

3. Do I have to take care about FreeBSD version etc??

Many thanks!

Hi vakas10 .

I hope you´re doing well.

The guide you found for VC upgrade can help you go through, however, if you are thinking about doing NSSU it is not supported for a  single jump from 14 to 18, actually, I kindly suggest you a regular upgrade which requires a single reboot for the whole stack instead of doing NSSU from 14 to 15 then the last jump to 18 and the whole process might take too long.

You can safely jump from 14.1X53-D40 to 18 as long as you test in the lab the current configuration in the latest Junos code as you can see below the configuration validation is no supported on QFX platforms, ones you confirm that it is supported and there are no syntax issues or incompatibilities you can go ahead with a single jump.

https://kb.juniper.net/InfoCenter/index?page=content&id=S:TSB17508&IQ_SESSION_ID=934d238f-7348-418f-aaa9-4bc44a06f5b1

Configuration Image Validation is not supported on QFX platforms during software upgrade or downgrade

If this solves your problem, please mark this post as "Accepted Solution" so we can help others too.

Cheers.

Hi esmorale

I found a Juniper KB34165 according to which I can't span more than 3 JunOS versions, So I think I update path should look like this: 14.1X53 --> 17.1 --> 17.4 --> 18.3 --> 18.4. This is clear to me, however, I am confused how to carry out the JunOS upgrade:-

1. If I do manual upgrade on individual members, I will lose the VC as all the members will not be on the same version during the upgrade and it will create more issues to troubleshoot.

2. Should I still use NSSU and upgrade all the members of the VC following the mentioned upgrade path? I understand that I will have to repeat the upgrade process 4 times.

Kindly let me know and correct me if I am wrong. 

Thanks!

@vakas10 as @esmorale said, NSSU is not supported on all SW version upgrades.  I am actually not 100% sure that NSSU for QFX5100-VC is supported at this time.  I do know for VCF, NSSU is not supported.  ISSU is supported on all upgrades of QFX5100, but only when in non-VC standalone mode. If you try NSSU and you run into an issue, it is very likely that the whole VC will go down anyway.  I very much doubt you will find anyone that would recommended using NSSU with QFX products in a VC, at this time.

I agree 100% with @esmorale's suggest that you perform a standard upgrade and go direct from 14 to 18 as this will work and has been done with success by others.  Yes this will cause downtime for the whole VC during the reboot process.  You could upgrade individual members, but this will not help with the VC down-time.  In fact it will likely increase it.

I did have someone who needed to upgrade a QFX5100-VC (only 2-member) with NO Downtime.  The only solution was to build an equivalent VC running the new code, and then move connections from old VC to new VC, and once all connections were moved, upgrade the old VC, . . .

Final choice is yours.  Good luck.

@rccpgm

Thank you for the reply. I am afraid I didn't completly understand one thing. I found this:-

KB34165 with Title: "QFX/EX upgrade path from 14.1X53 to 17.x":
--
"But customers can upgrade software from Junos OS release 14.1X53 to Junos OS release 17.x directly without any upgrade-related problems because Junos OS release 15.1R and Junos OS release 16.1R are transition versions that will not affect the software upgrade.

Note: Note, however, that any software upgrade after Junos OS release 17.1R1 will need to follow the Upgrade and Downgrade Support Policy for Junos OS Releases."

And according to this, I can't span more than 3 releases. So, I couldn't understand when you say that I can go from 14 to 18 directly without any issues? Even without NSSU, shouldn't I be manually upgrading the OS like:-

Step 1: 14.1X53 --> 17.1

Step 2: 17.1--> 17.4
Step 3: 17.4--> 18.3

Step 4: 18.3--> 18.4

Thanks!

I think this has been discussed in mutiple threads on this Forum, but the "I can't span more than 3 releases" was old school Junos when people did upgrades using a much faster candence.  Therefore no one generally never ran into this situation to start with.  In the old days, Junos had E-EOL releases, which were Extended EOL releases, and most people went from one E-EOL to the next, within 2 years time.

I do not see the "official policy" from changing, but it real 3 or more generally works fine, especially with certain product families - namely EX and QFX.

My [personnal] view is if you have issues going from any A to some X release, you will run into the same issues somewhere along the line going from A to C to E to eventually X.

All I can tell you is you can go direct from 14.x to 18.x in this situation.

NSSU/ISSU is a completely different situation.  Going from one release to another is more complex. Therefore these types of upgrades are support only under specific rules, at least at this time.

In the end, your choice on what you do and how you perfrom the upgrade.  Our comments are just other views from real-world experience.

Hi vakas10 .

I hope everything is ok.

My team and I have done many upgrades from 14 to 18 in a single hop with no issues as long as the configuration has not syntax or compatibility issues, but it's ok to jump from 14 to 17 then 18 through the regular upgrade, meaning that you need to put the Junos image in var/tmp folder in the master routing engine then issue the command request system software add/var/tmp/image name.tgz.

In regards to NSSU , if possible do not try it, the procedure above can take less time than NSSU, if NSSU fails can even cause a longer downtime than regular upgrades.

This command will install the same image in all the members at a time and requires a single reboot.

If this solves your problem, please mark this post as "Accepted Solution" so we can help others too.

Kind regards