This article describes how to replace the Routing Engine on one node of the cluster.
Also refer to the following articles as per requirement:
If certificate-based VPNs are used, see KB26879 - How to copy certificates after RE replacement in HA cluster [juniper.net] .
For information on replacing the complete node in a chassis cluster, see KB21134 - RMA replacement of a node in a Chassis Cluster [juniper.net] .
To prepare a standalone high-end SRX device to join an SRX Chassis cluster configuration, see KB28044 - How to prepare a standalone high-end SRX Series to join another high-end SRX configured for chassis cluster using USB snapshot [juniper.net] .
To prepare a standalone branch SRX device to join an SRX Chassis cluster configuration, see KB22679 - How to prepare a standalone SRX Branch to join another SRX Branch configured for chassis cluster using USB snapshot [juniper.net] .
Adding licenses from the CLI
KB21665 - Replacing the SCB or RE on a high-end SRX in a chassis cluster [juniper.net]
The following steps are performed to replace a Routing Engine on one node of a cluster. In this walkthrough, we are going to use node0 as the example.
Prepare to shut down node0
Failover the data-plane redundancy-group(s) (RG1+) from node0 to node1:
user@node0> request chassis cluster failover reset redundancy-group 1 user@node0> request chassis cluster failover redundancy-group 1 node 1
Failover the control-plane redundancy-group (RG0) from node0 to node1 (if necessary):
user@node0> request chassis cluster failover reset redundancy-group 0 user@node0> request chassis cluster failover redundancy-group 0 node 1
Run a traffic test, proceed if traffic test passed.
Find the chassis cluster ID:
user@node0> show chassis cluster status Cluster ID: 1
Back up original RE0 in Node0
Note: Since 12.1X47+, we support auto-synchronizing of the active configuration from the node which is RG0 primary to the node designated as the secondary. This means when the RE is replaced and comes online, the primary will perform a configuration synchronization to the second automatically without the need to do anything else. Be advised this does not include licenses or scripts mentioned below so it is advised to ensure backing up of these if necessary.
Manually Back up the configuration:
root@node0> edit root@node0# save /var/tmp/node0-config-YYYY-MM-DD
Copy the configuration to an external server with SCP enabled:
root@node0> start shell root@node0% scp /var/tmp/node0-config-YYYY-MM-DD root@ <server ip> :/node0-config-YYYY-MM-DD
Check for any licenses installed - show system licenses. If yes, these need to be backed up:
user@node0> show system license keys
Check for any licenses installed - show system licenses. If yes, these need to be backed up:Check for any scripts that are referenced in the configuration - "show configuration system scripts" and "show configuration event-options"
root@node0% scp /var/db/scripts/commit/commit-script.slax root@ <server ip> :/commit-script.slax
Swap RE0 on Node0
Halt the system (from devices that do not support halt, request a soft power-off instead) then physically turn off the power on node0:
user@node0> request system halt =or= user@node0> request vmhost halt
Disconnect all cables connected to node0, including cables connected to the revenue ports and the control and fabric links.
Remove the original RE0 from node0.
Insert the new RE0 replacement in node0.
Reconnect all power to node0.
Reconnect the console cable and the cable to the fxp0 interface, leave the rest of cables disconnected.
Precautions to prevent split brain scenario
Confirm again that all cables on node0 are disconnected only the console and fxp0 interfaces are connected
We can confirm this with onsite tech if one is not physically present
Check the status of the control and fabric link on the other node (node1) to ensure they are not showing up
user@node1> show chassis cluster interfaces Control link status: Down <-- verify it is down Control interfaces: Index Interface Monitored-Status Internal-SA Security 0 em0 Down Disabled Disabled 1 em1 Down Disabled Disabled Fabric link status: Down <-- verify it is down Fabric interfaces: Name Child-interface Status Security (Physical/Monitored) fab0 xe-11/0/3 Down / Down Disabled fab0
Prepare new RE0
Power on node0.
Log in to RE0 from the console.
Configure the fxp0 interface address, and add the necessary route to reach to the external server:
user# set system services sshu user# set interfaces fxp0 unit 0 family inet address <ip address/mask> user# set system root-authentication plain-text-password user# commit
For SRX5K Only (SRX5400,5600 & 5800): The chassis cluster information being in the SCB would come up with cluster enabled and would equally require the control-ports to be defined. You can use the following command from node1 to fetch this and apply to the RE replacement:
user@node1> show configuration chassis cluster control-ports | display set
We'll need to install the image that node1 is running onto node0. You can load the image from external server (or from usb and loading it locally), then reboot the system:
root> start shell %cd /var/tmp %scp root@ <server ip> : junos-srx5000-15.1X49-D140.2-domestic.tgz . %cli root> request system software add /var/tmp/junos-srx5000-15.1X49-D140.2-domestic.tgz
Before system reboot from the upgarde, configure the chassis cluster id and node id, then reboot the system (Note: This part can be skipped for SRX5K - SRX5400,SRX5600 & SRX5800):
user> set chassis cluster cluster-id 1 node 0 reboot
Re-apply any scripts (f applicable)
Apply the licenses (If applicable) (Refer to link mentioned in the summary section):
user@node0> request system license add terminal (Paste in the licenses)
Check RE0 for any chassis alarm messages:
user@node0> show chassis alarms
Halt node0 so it can be powered on from the console:
Bring up node0
Reconnect all the cables to node0.
Power on node0 from the console by pressing any key.
The primary node should then start synchronzing its configuration to the secondary at this point though, if you prefer, you can also add in the configuration manually as well.
Check the chassis cluster status on node1:
user@node0> show chassis cluster status
Node0 comes up and becomes secondary on both RG0 and RG1.
Redundancy group: 0 , Failover count: 1 node0 129 secondary no no None node1 128 primary no no None Redundancy group: 1 , Failover count: 1 node0 129 secondary no no None node1 128 primary no no None
Monitor the show chassis cluster status and wait until the node0 priority on RG1 changes to the configured value
Check that sessions are showing up on node0 and is nearly equal to the sessions on the primary node - node1
user@node0> show security monitoring
Failover RG1 to node0, and run a traffic test:
user@node1> request chassis cluster failover reset redundancy-group 1 user@node1> request chassis cluster failover redundancy- group 1 node 0 user@node1> request chassis cluster failover reset redundancy-group 1
Failover RG0 to node0, and run a traffic test:
user@node1> request chassis cluster failover reset redundancy-group 0 user@node1> request chassis cluster failover redundancy-group 0 node 0 user@node1> request chassis cluster failover reset redundancy-group 0
2026-06-01: Added in new formatting as well as made mention of the auto-synchronizing feature so while copying the configuration in manually is fine, the cluster will auto-sync once the RE is replaced and powered on.
2019-07-11: Some of the commands are incorrect, "redundant-group" instead of "redundancy-group", added some minor formatting corrections, and included instructions on how to backup /var/log. 2019-06-28: Added details related to adding license and scripts and steps to prevent split brain. 2018-06-27: Removed steps to sync configs, based upon default Junos OS X47+ behavior of cluster config sync.