SRX clusterYou 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 http://kb.juniper.net/KB21476

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.

12345

user@host#delete vlansuser@host#delete interfaces vlanuser@host#delete interfaces ge-0/0/0.0 family ethernet-switchinguser@host#delete securityuser@host#commit

***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

1 #delete interfaces fe-0/0/6

To remove control link interface

user@host#delete vlansuser@host#delete interfaces vluser@host#delete interfaces geuser@host#delete security

#delete interfaces fe-0/0/6

1 #delete interfaces fe-0/0/7

in SRX650 clustermanagement (fxp0)

1 #delete interfaces ge-0/0/0

control link

1 #delete interfaces ge-0/0/1

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

123456

Interface control process: [edit interfaces]Interface control process:   'fe-0/0/6'Interface control process:      HA management port cannot be configuredmgd: error: configuration check-out failedWarning: Commit failed, activating partial configuration.Warning: Edit the router configuration to fix these errors.

2) Once you issue;

#delete interfaces fe-0/0/7

#delete interfaces ge-0/0/0

#delete interfaces ge-0/0/1

Interface control process: [edit Interface control process: 'fe-0Interface control process: HAmgd: error: configuration check

on node 0

1 host>set chassis cluster cluster-id 1 node 0 reboot

on node 1

1 host>set chassis cluster cluster-id 1 node 1 reboot

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

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

1234567

{primary:node0}root@host1> show chassis cluster statusCluster ID: 1Node                  Priority          Status    Preempt  Manual failoverRedundancy group: 0 , Failover count: 1    node0                   1           primary        no       no  node1                   1           secondary      no       no

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.

host>set chassis cluster cluste

host>set chassis cluster cluste

{primary:node0}root@host1> show chassis cluCluster ID: 1Node Priority St

12345

set groups node0 system host-name berlinset groups node0 interfaces fxp0 unit 0 family inet address 172.16.20.1/24set groups node1 system host-name pragueset groups node1 interfaces fxp0 unit 0 family inet address 172.16.20.2/24set apply-groups "${node}"

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;

12345678910111213141516171819202122

groups {node0 {    system {      host-name berlin;    }  interfaces {      fxp0 {          unit 0 {                family inet {                  address 172.16.20.1/24;                }            }        }    }}node1 {    system {        host-name prague;  }    interfaces {        fxp0 {          unit 0 {

set groups node0 system host-set groups node0 interfaces fxpset groups node1 system host-set groups node1 interfaces fxp

groups {node0 { system { host-name berlin;

232425262728293031

                family inet {                  address 172.16.20.2/24;                }            }        }    }}}apply-groups "${node}"

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 240First make sure there is no logical unit on fabric interface.

12345

node0#delete interfaces ge-0/0/4.0Now configure fabric interfaces on node1.node0#set interfaces fab0 fabric-options member-interfaces ge-0/0/4node0#set interfaces fab1 fabric-options member-interfaces ge-5/0/4node0#commit

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

1234

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

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

node0#delete interfaces ge-0/0Now configure fabric interfacesnode0#set interfaces fab0 fabrnode0#set interfaces fab1 fabr

[edit interfaces fab0 fabric-optio 'ge-0/0/4' Logical unit is not allow ed on error: commit failed: (statements

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

1234

node0#delete interfaces fe-0/0/4.0node0#set interfaces fab0 fabric-options member-interfaces fe-0/0/4node0#set interfaces fab1 fabric-options member-interfaces fe-2/0/4node0#commit

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

1234

node0#delete interfaces ge-0/0/2.0node0#set interfaces fab0 fabric-options member-interfaces ge-0/0/2node0#set interfaces fab1 fabric-options member-interfaces ge-9/0/2node0#commit

Here is how the configuration looks like for SRX650;

12345678910111213

fab0 {    fabric-options {      member-interfaces {            ge-0/0/2;      }    }}fab1 {    fabric-options {        member-interfaces {            ge-9/0/2;        }    }

node0#delete interfaces fe-0/0/node0#set interfaces fab0 fabrnode0#set interfaces fab1 fabrnode0#commit

node0#delete interfaces ge-0/0node0#set interfaces fab0 fabrnode0#set interfaces fab1 fabrnode0#commit

fab0 { fabric-options { member-interfaces { ge-0/0/2;

14 }

 Check status;

123456789101112131415161718192021222324252627

root@host1> show chassis cluster data-plane interfacesfab0:    Name               Status    fe-0/0/5           upfab1:    Name               Status    fe-2/0/5           up{primary:node0}root@berlin> show interfaces terse fxp0.0Interface               Admin Link Proto    Local                 Remotefxp0.0                  up    up   inet     172.16.20.1/24{secondary:node1}root@prague> show interfaces terse fxp0.0Interface               Admin Link Proto    Local                 Remotefxp0.0                  up    up   inet     172.16.20.2/24Cluster Interfaces{primary:node0}root@host1> show chassis cluster interfacesControl link 0 name: fxp1Control link status: UpFabric interfaces: Name   Child-interface   Status fab0      fe-0/0/5          upfab0fab1       fe-2/0/5          upfab1Fabric link status: Up

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

root@host1> show chassis clufab0: Name Status fe-0/0/5 up

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 forcontrol 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.

12345678910111213

{primary:node0}[edit]root@host1# show chassis clusterreth-count 1;redundancy-group 1 {    node 0 priority 100;    node 1 priority 99;    preempt;  interface-monitor {        ge-0/0/0 weight 255;    }}redundancy-group 0 {    node 0 priority 100;

{primary:node0}[edit]root@host1# show chassis clureth-count 1;redundancy-group 1 {

1415

    node 1 priority 99;}

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

1234567891011121314151617181920212223242526272829

{primary:node0}[edit]root@host1# show interfacesge-0/0/0 {    unit 0 {        family inet {            address 212.45.64.1/24;        }    }}ge-0/0/1 {    gigether-options {        redundant-parent reth0;    }}ge-2/0/1 {    gigether-options {        redundant-parent reth0;    }}reth0 {    redundant-ether-options {        redundancy-group 1;    }    unit 0 {        family inet {            address 10.200.2.210/24;      }    }}

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

{primary:node0}[edit]root@host1# show interfacesge-0/0/0 { unit 0 {

1234567

{secondary:node1}root@host2> show chassis cluster status redundancy-group 1Cluster ID: 1Node                  Priority          Status    Preempt  Manual failoverRedundancy group: 1 , Failover count: 0    node0                   100         primary        yes      no  node1                   99          secondary      yes      no

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

1234567

{secondary:node1}root@host2> show chassis cluster status redundancy-group 1Cluster ID: 1Node                  Priority          Status    Preempt  Manual failoverRedundancy group: 1 , Failover count: 1    node0                   0           secondary      yes      no    node1                   99          primary        yes      no

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 willbe printed (note failover count is incremented)

123456

root@host2>show chassis cluster status redundancy-group 1Cluster ID: 1</div>Node                  Priority          Status    Preempt  Manual failoverRedundancy group: 1 , Failover count: 2    node0                   100         secondary      yes      no    node1                   99          secondary-hold yes      no

{secondary:node1}root@host2> show chassis cluCluster ID: 1Node Priority St

{secondary:node1}root@host2> show chassis cluCluster ID: 1Node Priority St

root@host2>show chassis clusCluster ID: 1</div>Node Priority StRedundancy group: 1 , Failover

 THINGS TO CONSIDER

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 membererror: 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.

[/stextbox]

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