SRX

Hey guys,

I currently have an SRX345 active/passive chassis cluster. The node 0 is an SRX345-SYS-JB-2AC and the node 1 is an SRX345-SYS-JB. I will be replacing the node 1 with the 2AC model. I was looking over the [SRX] RMA replacement of a node in a Chassis Cluster article. My hesitation with this is that it is explicitly calling out the process being for high-end SRX, which the 345 is not. 

So I am wondering what the best way to go about doing this is, to ensure proper mastership after adding node 1 (node 0 remains the cluster master for RG0 and RG1+), and to ensure that the config on node 0 is propagated correctly to the node 1, and that node 1 doesn't overwrite node 0's config. 

I think one of the big questions for me is how the config sync behavior works. If I add node 1 with a blank config, will node 0 automatically sync to node 1?

Knowing the article is for high-end devices, I was planning to do:

1. Deactivate preempt and interface monitor on node 0.
2. Power off the old node 1 and remove it from the rack.
3. Install the new node 1 in the rack.
4. Power node 1 up and get it upgraded to the code installed on node 0.
5. Connect the control and fabric links between the two nodes and do a 'set chassis cluster cluster-id 1 node 1 reboot' on node 1
6. Log into node 0 and confirm node 1 is in the cluster as the secondary
7. Do a 'commit force' on node 0 to force the config to sync to the secondary (is this needed?)
8. Bring up node 1's revenue ports and activate preempt and interface monitor on RG1.

Do we see any issues with this procedure? What is the best way to go about this? Do I need node 1 to join with the exact config that 0 has, as the article describes?

Thank you.

No, it won't. Unlike, say, EX switch virtual chassis which can "adopt" an amnesiac factory-default switch, you should prepare your replacement SRX while it's isolated.

The article you pointed to describes the procedure pretty well, though there's a caveat they don't mention -- you have to prepare everything your configuration needs before you enable chassis cluster. For example, if your configuration makes use of AppID, you need to enable AppID and download the app signature database prior to enabling chassis cluster. If you don't, you won't be able to update AppID on the isolated cluster node, and because of that your configuration won't commit.

So, the process is like this:

1.  Backup your cluster configuration
2.  Turn on the replacement SRX on your test bench and prepare it:
   • create a basic config unrelated to your cluster, just to allow you to transfer files or whatever else you need
   • check the clock -- set the correct date and time if it's way off to avoid certificates validation failures during JunOS installation
   • install same JunOS version as node0
   • enable and update features as needed <-- the AppID example I mentioned, plus whatever else is needed for your configuration (maybe scripts, certificates, etc.; most basic configurations require nothing here)
   • copy over your latest configuration back to /var/tmp/
   • enable chassis cluster as node 1 and reboot (it will become master, that's fine)
   • isolate the device (i.e. leave it only with console connection)
   • restore the configuration you copied before and commit it -- it will complain about being unable to reach the other RE, but that's fine, as long as it manages to commit the config on the new node1; if it fails to commit the configuration, don't proceed, resolve the problem first
   • shut down
3. Toss the old node1
4. Connect the new node1
5. Power on the new node1
6. After enough time to allow for boot-up and synchronization and what not, check that everything is working normally

------------------------------
Nikolay Semov

Original Message:
Sent: 04-18-2025 12:05
From: TacticalDonut164
Subject: Process of replacing secondary node in SRX345 active/passive chassis cluster

Hey guys,

I currently have an SRX345 active/passive chassis cluster. The node 0 is an SRX345-SYS-JB-2AC and the node 1 is an SRX345-SYS-JB. I will be replacing the node 1 with the 2AC model. I was looking over the [SRX] RMA replacement of a node in a Chassis Cluster article. My hesitation with this is that it is explicitly calling out the process being for high-end SRX, which the 345 is not. 

So I am wondering what the best way to go about doing this is, to ensure proper mastership after adding node 1 (node 0 remains the cluster master for RG0 and RG1+), and to ensure that the config on node 0 is propagated correctly to the node 1, and that node 1 doesn't overwrite node 0's config. 

I think one of the big questions for me is how the config sync behavior works. If I add node 1 with a blank config, will node 0 automatically sync to node 1?

Knowing the article is for high-end devices, I was planning to do:

1. Deactivate preempt and interface monitor on node 0.
2. Power off the old node 1 and remove it from the rack.
3. Install the new node 1 in the rack.
4. Power node 1 up and get it upgraded to the code installed on node 0.
5. Connect the control and fabric links between the two nodes and do a 'set chassis cluster cluster-id 1 node 1 reboot' on node 1
6. Log into node 0 and confirm node 1 is in the cluster as the secondary
7. Do a 'commit force' on node 0 to force the config to sync to the secondary (is this needed?)
8. Bring up node 1's revenue ports and activate preempt and interface monitor on RG1.

Do we see any issues with this procedure? What is the best way to go about this? Do I need node 1 to join with the exact config that 0 has, as the article describes?

Thank you.

No, it won't. Unlike, say, EX switch virtual chassis which can "adopt" an amnesiac factory-default switch, you should prepare your replacement SRX while it's isolated.

The article you pointed to describes the procedure pretty well, though there's a caveat they don't mention -- you have to prepare everything your configuration needs before you enable chassis cluster. For example, if your configuration makes use of AppID, you need to enable AppID and download the app signature database prior to enabling chassis cluster. If you don't, you won't be able to update AppID on the isolated cluster node, and because of that your configuration won't commit.

So, the process is like this:

1.  Backup your cluster configuration
2.  Turn on the replacement SRX on your test bench and prepare it:
   • create a basic config unrelated to your cluster, just to allow you to transfer files or whatever else you need
   • check the clock -- set the correct date and time if it's way off to avoid certificates validation failures during JunOS installation
   • install same JunOS version as node0
   • enable and update features as needed <-- the AppID example I mentioned, plus whatever else is needed for your configuration (maybe scripts, certificates, etc.; most basic configurations require nothing here)
   • copy over your latest configuration back to /var/tmp/
   • enable chassis cluster as node 1 and reboot (it will become master, that's fine)
   • isolate the device (i.e. leave it only with console connection)
   • restore the configuration you copied before and commit it -- it will complain about being unable to reach the other RE, but that's fine, as long as it manages to commit the config on the new node1; if it fails to commit the configuration, don't proceed, resolve the problem first
   • shut down
3. Toss the old node1
4. Connect the new node1
5. Power on the new node1
6. After enough time to allow for boot-up and synchronization and what not, check that everything is working normally

Hey guys,

I currently have an SRX345 active/passive chassis cluster. The node 0 is an SRX345-SYS-JB-2AC and the node 1 is an SRX345-SYS-JB. I will be replacing the node 1 with the 2AC model. I was looking over the [SRX] RMA replacement of a node in a Chassis Cluster article. My hesitation with this is that it is explicitly calling out the process being for high-end SRX, which the 345 is not. 

So I am wondering what the best way to go about doing this is, to ensure proper mastership after adding node 1 (node 0 remains the cluster master for RG0 and RG1+), and to ensure that the config on node 0 is propagated correctly to the node 1, and that node 1 doesn't overwrite node 0's config. 

I think one of the big questions for me is how the config sync behavior works. If I add node 1 with a blank config, will node 0 automatically sync to node 1?

Knowing the article is for high-end devices, I was planning to do:

1. Deactivate preempt and interface monitor on node 0.
2. Power off the old node 1 and remove it from the rack.
3. Install the new node 1 in the rack.
4. Power node 1 up and get it upgraded to the code installed on node 0.
5. Connect the control and fabric links between the two nodes and do a 'set chassis cluster cluster-id 1 node 1 reboot' on node 1
6. Log into node 0 and confirm node 1 is in the cluster as the secondary
7. Do a 'commit force' on node 0 to force the config to sync to the secondary (is this needed?)
8. Bring up node 1's revenue ports and activate preempt and interface monitor on RG1.

Do we see any issues with this procedure? What is the best way to go about this? Do I need node 1 to join with the exact config that 0 has, as the article describes?

Thank you.

I tested this on my lab units, it seems to work correctly via this shortened process after doing a 'request chassis cluster configuration-synchronize' via console on the "new" node 1 then a 'commit full' on node 0.

Do you see any issues with going about it this way? It seems more simple than having to go through that other process of copying the config over, especially since I don't have any dependencies like AppSecure or IPS. 

No, it won't. Unlike, say, EX switch virtual chassis which can "adopt" an amnesiac factory-default switch, you should prepare your replacement SRX while it's isolated.

The article you pointed to describes the procedure pretty well, though there's a caveat they don't mention -- you have to prepare everything your configuration needs before you enable chassis cluster. For example, if your configuration makes use of AppID, you need to enable AppID and download the app signature database prior to enabling chassis cluster. If you don't, you won't be able to update AppID on the isolated cluster node, and because of that your configuration won't commit.

So, the process is like this:

1.  Backup your cluster configuration
2.  Turn on the replacement SRX on your test bench and prepare it:
   • create a basic config unrelated to your cluster, just to allow you to transfer files or whatever else you need
   • check the clock -- set the correct date and time if it's way off to avoid certificates validation failures during JunOS installation
   • install same JunOS version as node0
   • enable and update features as needed <-- the AppID example I mentioned, plus whatever else is needed for your configuration (maybe scripts, certificates, etc.; most basic configurations require nothing here)
   • copy over your latest configuration back to /var/tmp/
   • enable chassis cluster as node 1 and reboot (it will become master, that's fine)
   • isolate the device (i.e. leave it only with console connection)
   • restore the configuration you copied before and commit it -- it will complain about being unable to reach the other RE, but that's fine, as long as it manages to commit the config on the new node1; if it fails to commit the configuration, don't proceed, resolve the problem first
   • shut down
3. Toss the old node1
4. Connect the new node1
5. Power on the new node1
6. After enough time to allow for boot-up and synchronization and what not, check that everything is working normally

Hey guys,

I currently have an SRX345 active/passive chassis cluster. The node 0 is an SRX345-SYS-JB-2AC and the node 1 is an SRX345-SYS-JB. I will be replacing the node 1 with the 2AC model. I was looking over the [SRX] RMA replacement of a node in a Chassis Cluster article. My hesitation with this is that it is explicitly calling out the process being for high-end SRX, which the 345 is not. 

So I am wondering what the best way to go about doing this is, to ensure proper mastership after adding node 1 (node 0 remains the cluster master for RG0 and RG1+), and to ensure that the config on node 0 is propagated correctly to the node 1, and that node 1 doesn't overwrite node 0's config. 

I think one of the big questions for me is how the config sync behavior works. If I add node 1 with a blank config, will node 0 automatically sync to node 1?

Knowing the article is for high-end devices, I was planning to do:

1. Deactivate preempt and interface monitor on node 0.
2. Power off the old node 1 and remove it from the rack.
3. Install the new node 1 in the rack.
4. Power node 1 up and get it upgraded to the code installed on node 0.
5. Connect the control and fabric links between the two nodes and do a 'set chassis cluster cluster-id 1 node 1 reboot' on node 1
6. Log into node 0 and confirm node 1 is in the cluster as the secondary
7. Do a 'commit force' on node 0 to force the config to sync to the secondary (is this needed?)
8. Bring up node 1's revenue ports and activate preempt and interface monitor on RG1.

Do we see any issues with this procedure? What is the best way to go about this? Do I need node 1 to join with the exact config that 0 has, as the article describes?

Thank you.

I think it's one of those "do it at your own risk" types of things. I think the main concern is the behavior of the new node1 after it's connected and boots up but before you synchronize the config. As long as you can make sure it doesn't somehow try to take over revenue traffic, you'll probably be fine.

If you're in a position to experiment, why not. But taking a copy of the config from node0 and loading it on node1 in advance is really low effort and worth it, in my opinion, for peace of mind.

I tested this on my lab units, it seems to work correctly via this shortened process after doing a 'request chassis cluster configuration-synchronize' via console on the "new" node 1 then a 'commit full' on node 0.

Do you see any issues with going about it this way? It seems more simple than having to go through that other process of copying the config over, especially since I don't have any dependencies like AppSecure or IPS. 

No, it won't. Unlike, say, EX switch virtual chassis which can "adopt" an amnesiac factory-default switch, you should prepare your replacement SRX while it's isolated.

The article you pointed to describes the procedure pretty well, though there's a caveat they don't mention -- you have to prepare everything your configuration needs before you enable chassis cluster. For example, if your configuration makes use of AppID, you need to enable AppID and download the app signature database prior to enabling chassis cluster. If you don't, you won't be able to update AppID on the isolated cluster node, and because of that your configuration won't commit.

So, the process is like this:

1.  Backup your cluster configuration
2.  Turn on the replacement SRX on your test bench and prepare it:
   • create a basic config unrelated to your cluster, just to allow you to transfer files or whatever else you need
   • check the clock -- set the correct date and time if it's way off to avoid certificates validation failures during JunOS installation
   • install same JunOS version as node0
   • enable and update features as needed <-- the AppID example I mentioned, plus whatever else is needed for your configuration (maybe scripts, certificates, etc.; most basic configurations require nothing here)
   • copy over your latest configuration back to /var/tmp/
   • enable chassis cluster as node 1 and reboot (it will become master, that's fine)
   • isolate the device (i.e. leave it only with console connection)
   • restore the configuration you copied before and commit it -- it will complain about being unable to reach the other RE, but that's fine, as long as it manages to commit the config on the new node1; if it fails to commit the configuration, don't proceed, resolve the problem first
   • shut down
3. Toss the old node1
4. Connect the new node1
5. Power on the new node1
6. After enough time to allow for boot-up and synchronization and what not, check that everything is working normally

Hey guys,

I currently have an SRX345 active/passive chassis cluster. The node 0 is an SRX345-SYS-JB-2AC and the node 1 is an SRX345-SYS-JB. I will be replacing the node 1 with the 2AC model. I was looking over the [SRX] RMA replacement of a node in a Chassis Cluster article. My hesitation with this is that it is explicitly calling out the process being for high-end SRX, which the 345 is not. 

So I am wondering what the best way to go about doing this is, to ensure proper mastership after adding node 1 (node 0 remains the cluster master for RG0 and RG1+), and to ensure that the config on node 0 is propagated correctly to the node 1, and that node 1 doesn't overwrite node 0's config. 

I think one of the big questions for me is how the config sync behavior works. If I add node 1 with a blank config, will node 0 automatically sync to node 1?

Knowing the article is for high-end devices, I was planning to do:

1. Deactivate preempt and interface monitor on node 0.
2. Power off the old node 1 and remove it from the rack.
3. Install the new node 1 in the rack.
4. Power node 1 up and get it upgraded to the code installed on node 0.
5. Connect the control and fabric links between the two nodes and do a 'set chassis cluster cluster-id 1 node 1 reboot' on node 1
6. Log into node 0 and confirm node 1 is in the cluster as the secondary
7. Do a 'commit force' on node 0 to force the config to sync to the secondary (is this needed?)
8. Bring up node 1's revenue ports and activate preempt and interface monitor on RG1.

Do we see any issues with this procedure? What is the best way to go about this? Do I need node 1 to join with the exact config that 0 has, as the article describes?

Thank you.