If your jump is not specified on the link, Juniper may not be able to confirm if there will be any unexpected behavior or if NSSU will fail. If that is the case, we suggest performing a normal upgrade using "request system sofware add" command and reboot all switches after using "request system reboot". More info:
EX Series devices are delivered with preinstalled Junos operating system (Junos OS). Before you start this procedure, decide which software package you need and download it. For information on which packages to use for which upgrades, see Junos OS Installation Package Names.
For better understanding kindly find the Below documents and KB's.
Considering all the 6 *EX4200 are in Virtual chassis, I am proving the below solution:
1. what is the solution for upgrade Junos with less downtime?
Nonstop software upgrade (NSSU) enables you to upgrade the software running on all member switches of supported Virtual Chassis with minimal traffic disruption during the upgrade.
This procedure describes how to upgrade the software running on all Virtual Chassis or mixed Virtual Chassis members using NSSU. When the upgrade completes, all members are running the new version of the software. The upgrade includes a graceful Routing Engine switchover, so the original Virtual Chassis backup member switch becomes the new master.
During NSSU, the master copies the new software image to all the members in the Virtual Chassis and reboots them in turn. If copying the new software to a member fails or rebooting a member fails, NSSU aborts the upgrade process and logs the error. In this case, you must manually perform recovery measures for members left in an incompatible state to restore all members to running the same version of the software. Starting in Junos OS Release 14.1X53-D40, NSSU automatically invokes recovery measures after either of these failures, as follows:
if NSSU aborts due to a copy error, the master removes the new image from any members to which it was already copied.
If any member fails to reboot, NSSU automatically initiates a clean Virtual Chassis restart by bringing down and rebooting the entire Virtual Chassis. All members come up running the new software at the same time. This action cleanly recovers correct Virtual Chassis operation more quickly than having an unstable Virtual Chassis running different versions of the software trying to converge.
As mentioned, NSSU (EX only) will upgrade and reboot members of a VC one at a time, but just as with ISSU, there are a number of requirements and restrictions - check link above for exact details.
NOTE: NSSU success rate has not been high, especially for older products (like EX4200 VC). This form of upgrade is in general still not recommend, and if issues arise during the upgrade, additional downtime could be created.
Standard Software Upgrade (https://www.juniper.net/documentation/en_US/junos/topics/topic-map/install-software-on-ex.html#id-un...) which follows 'request system software add' with a reboot. Best practice is to NOT use reboot option, but instead wait for add to complete, and then reboot. The "add" portion will take come time, as image is copied to RE Master, who then send image to all members, but this step can be taken prior to any outage or maintenance window. When reboot of the whole VC is performed, all connections will go down, and return once reboot is complete, which is generally in the area of 1-3 minutes.
For both VC and VCF configurations with EX and/or QFX, Standard Software Upgrades are recommended best practice, at this time.