Most of the time, these upgrades work without causing any issues. However, in rare occasions different issues may arise when an SRX is upgraded more than two EEoL versions ahead. Whether the upgrade method is minimum downtime, ISSU/ICU, or using the method of re-imaging the SRX with the bootable USB install media and then loading the configuration from the older Junos version onto the current Junos version. Please see the article [SRX] Junos upgrade paths for SRX platforms [juniper.net] for more detail on qualified Junos upgrade jumps for the SRX.

Symptoms most commonly include cluster related issues such as control or fabric link instability, or traffic issues after failover. However, the issues can affect any part of the system.

By re-imaging the SRX to the desired Junos version, we avoid the need for step upgrades as the old FreeBSD, Junos, and Linux (on some platforms) is wiped out and replaced with clean default versions. What is missing with this upgrade method is that the prescribed officially tested upgrade paths also account for ensuring that the configuration from the previous Junos version is properly adapted for the current Junos version. After re-imaging the box, the old configuration is loaded in the previous format. It is converted at the same time it is applied. This is not always a perfect process, as it is not tested and qualifies past the officially supported two EEoL version upgrade. Therefore, we need to take an extra step to refresh the box after it has loaded and committed the legacy configuration.

When upgrading via USB re-image in order to avoid multiple upgrade steps, we need to integrate an extra reboot to avoid problems that sometimes appear.

The configuration needs to be saved externally to USB and a separate USB drive needs to be prepared to be bootable with the install media image.

Cluster upgrade:

0 - Move all RGs to node0.

1 - Isolate node1, removing ports in the following order.

a. Remove revenue ports

b. Remove fabric ports

c. Remove control ports

2 - Re-image node1 to the new Junos version.

https://kb.juniper.net/KB19576 [juniper.net]

3 - Set cluster ID and reboot. SRX5K should be able to skip this step.

4 - Load the legacy configuration to node1.

a. Mount the USB with the config or configure fxp0 to copy the file to the SRX

b. load override /var/tmp/config.txt

c. commit check

d. Correct any config errors that may appear

e. commit

The next step is a critical step to help this go more smoothly.

5 - Reboot node1 to have it boot fresh from the configuration it has just converted to the new Junos version.

6 - Cut traffic over to node1

a. Remove the revenue ports from node0 first

b. Connect the revenue ports to node1

This can also be done by disabling the ports from the switch side.

If node1 is connected before node0 is disconnected, you run the risk of the switch automatically disabling ports to prevent both nodes from trying to use the same MAC at the same time.

7 - Do checks as needed for network stability on node1

8 - Re-image node0 to the new Junos version

9 - If SRX5K, add the control port configuration only.

If not SRX5K, set the cluster ID and reboot.

Important!

10 - Do not manually add the full configuration to node0

11 - Power off node0

12 - Reconnect all ports to all nodes

13 - Power on node0

Node0 will inherit the configuration that node1 has converted to the current Junos version.

This accomplishes two things.

a. Node1 has already converted the config to the new Junos version.

b. If there are any issues with node0 rejoining the cluster, node0 will not have any configuration that will allow it to interrupt the network.

14 - Perform any verifications and/or failover tests

Standalone upgrade:

1 - Re-image the SRX to the new Junos version.

2 - Load the legacy configuration.

a. Load override /var/tmp/config.txt

b. commit check

c. Correct any config errors that may appear

d. commit

3 - Reboot the SRX to have it boot fresh from the configuration it has just converted to the new Junos version.

In the case of ISSU upgrade, an additional rolling reboot after upgrade would be recommended.

NOTE: In both cases, the additional reboot after the configuration is completely sorted out on the first upgraded device is a critical step that must not be skipped.
 

2023-10-29 : Article Created
2023-10-29 : Expanded Product Categories
2024-06-22: Additional edits
2025-04-23: Linked to supported upgrade paths KB.
2025-11-25: Additional clarification for how this applies to every upgrade method to exceeds two EEOL versions.
2025-12-04: Formatting