[j-nsp] qfx5100 software upgrades and virtual-chassis

[Louis Kowolowski]

It seems reasonable, and no worse than the situation now, with mis-matched versions. I don't see why the host software would have anything to do with VC, seems like it should just be handling VM operations, and doing hardware-passthrough...


> On Sep 6, 2018, at 12:01 PM, Chuck Anderson <cra at WPI.EDU> wrote:
> 
> Logically, why couldn't you isolate one member at a time, do the upgrade, then rejoin it to the VC?
> 
> On Thu, Sep 06, 2018 at 11:12:59AM -0500, Louis Kowolowski wrote:
>> I currently have a 6 node VC of qfx5100. All are running 14.1X53-D43.7 and host software 13.2X51-D38. In discussions with JTAC, they claim that upgrading the host software to match the VM, it requires a reboot of *all* nodes in the VC at the same time.
>> 
>> Has anybody else had to deal with this? Are there any work-arounds? Taking the whole thing down is extremely awkward. Can we do a rolling upgrade (manually, I know ISSU/NSSU doesn't handle this) and stay operational? We are working on a plan to re-architect this into 2x 3 node VC and MC-LAG them together, but it would be nice to be able to fix this more short-term.

--
Louis Kowolowski                                louisk at cryptomonkeys.org
Cryptomonkeys:                                   http://www.cryptomonkeys.com/

Making life more interesting for people since 1977