Thanks for the video Colin. Is it possible to upgarde only the backup RE first, then reboot. And if all goes right, update the master as well. I need to make sure there won't be no impact. Regards,
As-salamu alaikum! You have an amazing voice, brother. Is that a Focusrite Scarlett USB audio interface in your videos? If so, how do you like it? Regarding VC upgrades... virtual-chassis on its own doesn't support a hitless upgrade process, but that's not unique to Juniper. Stacking, regardless of the vendor, requires every stack member to run the same version of code during normal operations. There is also a required reboot for any switch going through an upgrade, so hosts connected to that switch will lose connectivity. What does this all mean? Let's start with your requirement for "no impact". I've encountered folks that operate critical networks insisting that network-attached hardware cannot be offline even for a second. Think hospital networks, electrical grid IT networks, and similar. The thing is, if what you are plugging into the network only has one network interface, that device is not built for high-availability! To put it a different way, you can ensure no/minimal network disruption during an upgrade only if each device connected to the virtual-chassis has a minimum of 2 links (in a LAG), and those 2 links are connected to different switches. In this way, while one switch in the stack is upgrading and unavailable, the connected host can still function over the link to the other switch. To answer your question, you can upgrade the BK first, but all you'll be able to confirm is that it boots with the correct software. VC functions are very limited during the upgrade process, so there's no meaningful VC testing you can do post-upgrade. What I suggest is the NSSU process: www.juniper.net/documentation/us/en/software/junos/high-availability/topics/concept/nssu-ex-series.html Pay very close attention to the configuration requirements if you choose to use NSSU! When NSSU fails, it's almost always because one of the many prerequisites hasn't been met. This process will do a bunch of verification checks, upgrade the BK RE first, then start upgrading the VC line-cards one at a time. Finally, the RE (master) will switchover mastership to the BK and upgrade itself. I hope this helps!
Should be a similar workflow, if not the same. There are two methods: - Upgrade each member separately: www.juniper.net/documentation/us/en/software/nce/nce-171-qfx-vc-upgade/index.html - Upgrade using NSSU: www.juniper.net/documentation/us/en/software/junos/junos-install-upgrade/topics/topic-map/install-software-on-qfx.html I don't have QFX platforms to test with, so I can't record a video for you. :(
Thanks for the video Colin.
Is it possible to upgarde only the backup RE first, then reboot.
And if all goes right, update the master as well.
I need to make sure there won't be no impact.
Regards,
As-salamu alaikum! You have an amazing voice, brother. Is that a Focusrite Scarlett USB audio interface in your videos? If so, how do you like it?
Regarding VC upgrades... virtual-chassis on its own doesn't support a hitless upgrade process, but that's not unique to Juniper. Stacking, regardless of the vendor, requires every stack member to run the same version of code during normal operations. There is also a required reboot for any switch going through an upgrade, so hosts connected to that switch will lose connectivity.
What does this all mean?
Let's start with your requirement for "no impact". I've encountered folks that operate critical networks insisting that network-attached hardware cannot be offline even for a second. Think hospital networks, electrical grid IT networks, and similar. The thing is, if what you are plugging into the network only has one network interface, that device is not built for high-availability!
To put it a different way, you can ensure no/minimal network disruption during an upgrade only if each device connected to the virtual-chassis has a minimum of 2 links (in a LAG), and those 2 links are connected to different switches.
In this way, while one switch in the stack is upgrading and unavailable, the connected host can still function over the link to the other switch.
To answer your question, you can upgrade the BK first, but all you'll be able to confirm is that it boots with the correct software. VC functions are very limited during the upgrade process, so there's no meaningful VC testing you can do post-upgrade.
What I suggest is the NSSU process: www.juniper.net/documentation/us/en/software/junos/high-availability/topics/concept/nssu-ex-series.html
Pay very close attention to the configuration requirements if you choose to use NSSU! When NSSU fails, it's almost always because one of the many prerequisites hasn't been met.
This process will do a bunch of verification checks, upgrade the BK RE first, then start upgrading the VC line-cards one at a time. Finally, the RE (master) will switchover mastership to the BK and upgrade itself.
I hope this helps!
Colin grate video ! I have a question , could I do the same process for QFX VC (5100) ?
Should be a similar workflow, if not the same. There are two methods:
- Upgrade each member separately: www.juniper.net/documentation/us/en/software/nce/nce-171-qfx-vc-upgade/index.html
- Upgrade using NSSU: www.juniper.net/documentation/us/en/software/junos/junos-install-upgrade/topics/topic-map/install-software-on-qfx.html
I don't have QFX platforms to test with, so I can't record a video for you. :(
Very helpful to me Colin, thank you soo much!
Awesome! Glad it was helpful!