I am doing some testing and require to downgrade my virtual chassis from 17.4 to 17.3.
NSSU can't work for downgrade.
Been googling around but i am not able to find the right steps to properly downgrade a virtual chassis with minimum downtime
q1) Should I connect to the backup switch (e.g request session member 2) and issue a request system software add ... reboot ?
q2) When the member switch with an older version is back up, does it still join back the virtual chassis ? Will it remain as inactive status ( how does Juniper determine which switch become inactive ? shortest uptime ?)
q3) when the member switch is back, if it remain as inactive, then should i proceed to issue request system software add ... reboot on the master switch ? When the master switch reboot, will the inactive memer switch become the new master ?
Does this means i will have a downtime for virtual chassis firmware downgrade ?
I am using 2 x qfx5100-48s-6q to setup my virtual-chassis.
You cannot avoid some kind of downtime when doing downgrades.
The easiest way will be to just do a normal software installation with 17.3 software and do the reboot and accept the ~10 minutes of downtime.
Two switches running different Junos versions will not join the same VC. You could have "auto-sw upgrade" enabled for an older version to be upgraded... but again - only upgrades.
If you want to minimize downtime during a downgrade I would go for something like this (via the serial console on each switch).
1. Ensure local storage of Junos 17.3 software on each switch
2. shut all revenue interfaces on standby member (fpc1)
3. Unplug VCP cables to seperate fpc1 member from fpc0.
4. Downgrade fpc1 and reboot. It will keep knowledge about fpc0 but have all revenue ports disabled so it case on split-detection it will not affect production.
5. at the same time deactivate all fpc0 ports on the master and enable alle fpc1 on the newly downgraded fpc1. This will give a 30-60-90 seconds downtime depending on protocols running. Everything now runs on fpc1
6. Downgrade fpc0 and reboot.
7. After reboot, replug the VCP cables. fpc0 will have lower uptime an loose the election for master (EXCEPT if you have configured them otherwise... please check your configuration and virtual-chassis behaviour). Fpc1 still remembers fpc0 ports as active and should just rejoin when fpc0 is ready.
....but again - maybe just plan with 10 minutes downtime and keep it simple :-)