[j-nsp] VC (2x EX4200) JunOS Upgrade without downtime ?

[Tore Anderson]

* Giovanni Bellac

> Each of our customer (layer2) rack-switches are connected with a
> trunk (lacp) to the VC. So we can shutdown one EX4200 of the VC (2x
> EX4200) without downtime on paper  ?
> 
> 
> I have read in the forums of Juniper, that you CAN NOT upgrade a VC
> without downtime, because the updated member will NOT join the VC.
> 
> Is that right ? Is a JunOS upgrade on a VC without downtime
> impossible ?

Hi Giovanni,

I recently did some testing of this in a lab. I could not find a way to
upgrade the VC without any service interruption at all, precisely
because a newly-upgraded switch will not join the VC. However, you can
keep the impact fairly low, by doing things in the optimal order. Note
that in my testing I only had two members in the VC, and each downstream
switch multihomed (using LACP trunks) to each of the physical switches
in the VC. I don't really know how this would work if you have more than
two switches in your VC. In any case, assuming that FPC0 is currently
the RE, and FPC1 is the backup:

1) Ensure «no-split-detection» is set under [edit virtual-chassis]

2) Upgrade and reboot FPC1. All ports on that switch will go down,
however the service interruption is negligible - limited to some packet
loss for a split second while the LACP trunks converge on FPC0. After
FPC1 comes back up, it won't join the VC, and remain in the «Inactive»
state, with all ports disabled.

3) Reboot FPC0. FPC1 will now assume mastership, a process which led to
around 30 seconds of downtime on the LACP trunks in my lab setup. You
are now on the new code, and when FPC0 comes backup, it will be in the
«Inactive» state, just like FPC1 was earlier. FWIW, I also did testing
of OSPF adjacencies to the VC running on top of those LACP trunks, those
had ~55 seconds of extra downtime (total ~85 seconds before everything
was back to normal).

4) Ensure that the new code works fine. When happy, upgrade and reboot
FPC0. There's no service interruption, as FPC0 wasn't involved in
pushing packets at this point anyway. When it comes back up, it re-joins
the VC (assuming the backup role) and you're all done.

You could of course skip step 3, instead do a upgrade+reboot of FPC0
immediately. However, if you only do a simple reboot to transfer RE
ownership to the upgraded switch, it is very easy to revert to the old
code if the new one doesn't work properly - just reboot FPC1.

Good luck,
-- 
Tore Anderson
Redpill Linpro AS - http://www.redpill-linpro.com
Tel: +47 21 54 41 27