You should activate NSB too as you use LAG, it's not required but highly recommanded. https://www.juniper.net/documentation/us/en/software/junos/high-availability/topics/concept/nssu-ex-series.html
VC must be in preprovisionned mode and "no-split-detection" must be enabled as you are in a two member VC.
About horror stories, NSSU should be used with care and i will works fine.
You should double check the upgrade path (test on preprod or lab setup) or ask the validated upgrade path for EX4600 to the GTAC.
don't forget to add the "force-host" option on the upgrade command.
Good luck !
Sent: 12-06-2021 08:56
From: Unknown User
Subject: EX4600 virtual chassis NSSU
I have 2 EX4600 switches connected in a virtual chassis and I was planning on doing NSSU upgrade on them for the 1st time from version 19.1R3-S2.3 to version 20.2R3-S2. Usually I would just schedule some downtime but we have acquired some services/clients that need to have as little downtime(LAGs are configured with interfaces on both members) as possible and NSSU seems the best course of action.
While researching what is needed for the NSSU the only thing I found was that the only thing needed was Graceful Routing Engine switchover (GRES) and nonstop active routing (NSR) to be enabled and the procedure seems straight forward.
But reading through different forums I see a lot of horror stories with this type of upgrade. Are there any obvious pitfalls I should be careful of and take notice of? Any advice that this runs as smoothly as possible would be greatly appreciated.