SRX cluster

You can find step by step instructions to set up an SRX firewall chassis cluster in different branch models. Before starting your cluster config, please make sure you have installed the JTAC recommended release which you can find at

Please note that these instructions below belong to several branch models each of which has slightly different configuration. Pick the one you have. You can also use HA configuration tool developed by Juniper for easier configuration at here.

1) In branch SRX devices (but only 1XX and 2xx models)  ethernet switching must be disabled before enabling cluster.

***ethernet switching must be disabled on other interfaces as well not only ge-0/0/0.0 which is an example.

These changes aren’t sufficient. Delete control link and management ports as well. For example,

in srx210 cluster;

To remove management interface

To remove control link interface

in SRX650 cluster
management (fxp0)

control link

if you don’t delete these interfaces you will receive the following type of warning during boot or commit.

2) Once you issue;

on node 0

on node 1

Nodes will be rebooted, cluster may not come up if there is a configuration error.

After the systems are booted, you will have such an output;

If this is the case, configure the following management interface (fxp0) only on the primary as the config will be pushed to secondary automatically.

Setup host names and management IP addresses as follow.

fxp0 interface is the new interface name in the cluster environment and one dedicated port is assigned in each branch device. For example in an SRX210 cluster, fe-0/0/6 interface of each node must be used as the management interface. To check for other branch devices look at TABLE1

Configuration will look like below;

4) Configure fabric links (data-plane): Fabric interface is a dedicated interface in each node and you pick one available  in branch SRX devices. It is used to sync RTO’s (Real-Time Object) e.g sessions and can also pass traffic.

One thing to mention is  if we take SRX240 as an example, ge-5/0/4 is indeed ge-0/0/4 interface of node1. Don’t think that it is a mistake. Look at TABLE2 to see why it changes so.

SRX 240
First make sure there is no logical unit on fabric interface.

You have to delete the logical interface otherwise you will get the following error;

Once committed, the fabric link modifications must  be propagated to the node1 automatically if the cluster is UP.

SRX210 (only node1’s fabric interface starts with fe-2)

SRX650 (if I choose ge-0/0/2 on both nodes as fabric links)

Here is how the configuration looks like for SRX650;

 Check status;

Assume we have two uplinks connected to two SRX 210 devices.  Node0 is primary and node1 is secondary.

The above topology is so simplistic as it is to show how redundancy group works.

Below is the configuration according to which there are two redundancy groups. RG0 is for
control plane which no preempt is available. In RG1 node0 has higher priority and primary.
ge-0/0/0 interface is monitored actively and has a weight 255 which means if it fails,
its weight will be subtracted from 255 which results 0 and RG1 will fail over.

Redundancy Group Config 
reth-count defines how many reth interfaces we have.

Redundant Ethernet Config
According to this config,  ge-0/0/1 and ge-2/0/1 (indeed ge-0/0/1 of node1) interfaces
form reth0 interface.  As RG1 also monitors ge-0/0/0 actively , if it fails,
node1 will take over RG1.

Cluster status Failover
Here we can see that node0 is primary for RG1 and preempt enabled

Once ge-0/0/0 fails, the following output occurs

As it can be seen, priority of node0 is set to zero once it fails. Because preempt is ON,
if ge-0/0/0 link is back online, RG1 will fail over to node0 and folllowing output will
be printed (note failover count is incremented)


In SRX 240 models:

[stextbox id=”info” caption=”TIPS”]

a) For control plane links, use ge-0/0/1 on both nodes . You can cross connect both interfaces.

b) For fabric link, you can use any interfaces on nodes but pay attention to interface numbering in chassis cluster.  ge-5/0/4 is indeed interface ge-0/0/4 of node1,
this is because all interfaces after clustering is enabled start with ge-5/0/ on node1

c) Don’t leave any logical unit on any interfaces of data plane,fabric links. If so, you can receive such an error;

[edit interfaces fab0 fabric-options member-interfaces]
‘ge-0/0/4’    Logical unit is not allowed on fabric member
error: commit failed: (statements constraint check failed)

d) If during the configuration you loose synchronization between nodes, try to run “commit full” to remedy the situation.


Here are two tables from Juniper documents regarding cluster interfaces assignments: