This article will clarify the customer questions about the NSSU upgrade in the EX3400 device.
1) When the Mastership was transferred to the upgraded backup, we lost connectivity to the device for several seconds. I was under the impression it would be seamless
2) After the upgrade was completed, the Routing Engine (RE) that was the master at the beginning of the process was expected to remain the master. However, that was not the case, the Backup RE became the new master after the upgrade..
Customer has raised to clarify the NSSU Upgrade related queries.
1) When Mastership was transferred to the upgraded backup we lost connectivity to the device for a number of seconds, I was under the impression it would be seamless.
1. Brief Loss of Management Connectivity During Mastership Switch
Why This Happens: The "non-stop" in NSSU refers to the data plane. The forwarding of user traffic (data plane) continues uninterrupted on the Line Cards (LCs), which in an EX VC are the other member switches.
However, the control plane (which includes the routing protocol process, management daemons, etc.) on the new master is restarted as part of the mastership change process. Your SSH session, SNMP polls, and other management traffic rely on this control plane.
When mastership is manually transferred from the old master (running the old software) to the new master (now running the new software), the control plane on the new master initializes. This process involves:
This initialization takes several seconds, during which the device is unreachable.
Conclusion: A loss of management connectivity for 5-30 seconds is entirely normal and documented for NSSU. The key is that customer data traffic was not impacted.
2) When completed, I was of the understanding that what RE was master at the start of the process would be master again when the upgrade was completed; it was not the case, and Backup RE was now the new master.
Mastership Not Reverting to the Original RE. Why this happens is the intended behavior of the NSSU process. The process is designed to get all members onto the new software with minimal disruption. It is not designed to preserve the original mastership state.
The final step of an NSSU upgrade is for the member that was upgraded first (the original backup) to become the master. The member that was upgraded second (the original master) reboots into the new software and comes online as the new backup.
This sequence is actually crucial for stability. It ensures the node with the longest stable uptime on the new code (the new master) is in control, while the last node to reboot (which could have transient issues) comes online as a subordinate.
Conclusion: The mastership change is by design. You should never begin an NSSU with the expectation that the same member will be a master at the end. The pre-upgrade master will become the post-upgrade backup.
https://www.juniper.net/documentation/us/en/software/junos/high-availability/topics/concept/nssu-ex-series.html