Example: Configuring an SRX Series Services Gateway for the Branch as a Chassis Cluster
This example shows how to set up chassis clustering on an SRX Series for the branch device.
Requirements
Before you begin:
- Physically connect the two devices and ensure that they are the same models. For example, on the SRX210 Services Gateway, connect fe-0/0/7 on node 0 to fe-0/0/7 on node 1.
- Set the two devices to cluster mode and reboot the devices.
You must enter the following operational mode commands on both devices,
for example:
- On node 0:user@host> set chassis cluster cluster-id 1 node 0 reboot
- On node 1:user@host> set chassis cluster cluster-id 1 node 1 reboot
The cluster-id is the same on both devices, but the node ID must be different because one device is node 0 and the other device is node 1. The range for the cluster-id is 0 through 15 and setting it to 0 is equivalent to disabling cluster mode.
- On node 0:
- After clustering occurs for the devices, continuing with
the SRX210 Services Gateway example, the fe-0/0/7 interface
on node 1 changes to fe-2/0/7. After the reboot, the following
interfaces are assigned and repurposed to form a cluster:
- fe-0/0/6 becomes fxp0 and is used for individual management of the chassis cluster.
- fe-0/0/7 becomes fxp1 and is used as the control link within the chassis cluster.
- The other interfaces are also renamed on the secondary device. For example, the ge-0/0/0 interface is renamed ge-2/0/0 on node 1 on the secondary device.
See Node Interfaces on Active SRX Series Chassis Clusters for complete mapping of the SRX Series devices.
Note: The ports used for the control link, fe-0/0/7, must be connected with a cable. A switch cannot be used to connect the control link. You must also decide which port to use as the third link to connect the devices and use as the fabric link between the devices. This port can be any available Gigabit Ethernet or Fast Ethernet port other than fe-0/0/6 and fe-0/0/7.
From this point forward, configuration of the cluster is synchronized between the node members and the two separate devices function as one device.
Overview
This example shows how to set up chassis clustering on an SRX Series for the branch device. The following services gateways for the branch are supported:
- SRX100
- SRX210
- SRX220
- SRX240
- SRX550
- SRX650
Depending on the device used, node 1 renumbers its interfaces by adding the total number of system FPCs to the original FPC number of the interface. See Table 1 for interface renumbering on the SRX Series device.
Table 1: SRX Series Services Gateways Interface Renumbering
SRX Series Services Gateway | Control Link Name | Renumbering Constant | Node 0 Interface Name | Node 1 Interface Name |
---|---|---|---|---|
SRX100 | fe-0/0/7 | 1 | fe-0/0/0 | fe-1/0/0 |
SRX210 | fe-0/0/7 | 2 | ge-0/0/0 | ge-2/0/0 |
SRX220 | ge-0/0/7 | 3 | ge-0/0/0 | ge-3/0/0 |
SRX240 | ge-0/0/1 | 5 | ge-0/0/0 | ge-5/0/0 |
SRX550 | ge-0/0/1 | 9 | ge-0/0/0 | ge-9/0/0 |
SRX650 | ge-0/0/1 | 9 | ge-0/0/0 | ge-9/0/0 |
After clustering is enabled, the system creates fxp0, fxp1, and fab interfaces. Depending on the device, the fxp0 and fxp1 interfaces that are mapped to a physical interface are not user defined. However, the fab interface is user defined. see Table 2 for mapping of the fxp0 and fxp1 interfaces on the SRX Series devices.
Table 2: SRX Series Services Gateways fxp0 and fxp1 Interfaces Mapping
SRX Series Services Gateway | fxp0 Interface | fxp1 Interface | fab Interface |
---|---|---|---|
SRX100 | fe-0/0/6 | fe-0/0/7 | user defined |
SRX210 | fe-0/0/6 | fe-0/0/7 | user defined |
SRX220 | fe-0/0/6 | fe-0/0/7 | user defined |
SRX240 | ge-0/0/0 | ge-0/0/1 | user defined |
SRX550 | ge-0/0/0 | ge-0/0/1 | user defined |
SRX650 | ge-0/0/0 | ge-0/0/1 | user defined |
Figure 1 shows the topology used in this example.
Figure 1: SRX Series for the Branch Topology Example

Configuration
CLI Quick Configuration
To quickly configure a chassis cluster on an SRX210 Services Gateway, copy the following commands and paste them into the CLI:
On {primary:node0}
If you are configuring an SRX Series for the branch device other than the SRX210 device, see Table 3 for command and interface settings for your device and substitute these commands into your CLI.
Table 3: SRX Series Services Gateways for the Branch Interface Settings
Command | SRX100 | SRX210 | SRX220 | SRX240 | SRX550 SRX650 |
---|---|---|---|---|---|
set interfaces fab0 fabric-options member-interfaces | fe-0/0/1 | ge-0/0/1 | ge-0/0/0 to ge-0/0/5 | ge-0/0/2 | ge-0/0/2 |
set interfaces fab1 fabric-options member-interfaces | fe-1/0/1 | ge-2/0/1 | ge-3/0/0 to ge-3/0/5 | ge-5/0/2 | ge-9/0/2 |
set chassis cluster redundancy-group 1 interface-monitor | fe-0/0/0 weight 255 | fe-0/0/3 weight 255 | ge-0/0/0 weight 255 | ge-0/0/5 weight 255 | ge-1/0/0 weight 255 |
set chassis cluster redundancy-group 1 interface-monitor | fe-0/0/2 weight 255 | fe-0/0/2 weight 255 | ge-3/0/0 weight 255 | ge-5/0/5 weight 255 | ge-10/0/0 weight 255 |
set chassis cluster redundancy-group 1 interface-monitor | fe-1/0/0 weight 255 | fe-2/0/3 weight 255 | ge-0/0/1 weight 255 | ge-0/0/6 weight 255 | ge-1/0/1 weight 255 |
set chassis cluster redundancy-group 1 interface-monitor | fe-1/0/2 weight 255 | fe-2/0/2 weight 255 | ge-3/0/1 weight 255 | ge-5/0/6 weight 255 | ge-10/0/1 weight 255 |
set interfaces | fe-0/0/2 fastether-options redundant-parent reth1 | fe-0/0/2 fastether-options redundant-parent reth1 | ge-0/0/2 fastether-options redundant-parent reth0 | ge-0/0/5 gigether-options redundant-parent reth1 | ge-1/0/0 gigether-options redundant-parent reth1 |
set interfaces | fe-1/0/2 fastether-options redundant-parent reth1 | fe-2/0/2 fastether-options redundant-parent reth1 | ge-0/0/3 fastether-options redundant-parent reth1 | ge-5/0/5 gigether-options redundant-parent reth1 | ge-10/0/0 gigether-options redundant-parent reth1 |
set interfaces | fe-0/0/0 fastether-options redundant-parent reth0 | fe-0/0/3 fastether-options redundant-parent reth0 | ge-3/0/2 fastether-options redundant-parent reth0 | ge-0/0/6 gigether-options redundant-parent reth0 | ge-1/0/1 gigether-options redundant-parent reth0 |
set interfaces | fe-1/0/0 fastether-options redundant-parent reth0 | fe-2/0/3 fastether-options redundant-parent reth0 | ge-3/0/3 fastether-options redundant-parent reth1 | ge-5/0/6 gigether-options redundant-parent reth0 | ge-10/0/1 gigether-options redundant-parent reth0 |
Step-by-Step Procedure
The following example requires you to navigate various levels in the configuration hierarchy. For instructions on how to do that, see Using the CLI Editor in Configuration Mode.
To configure a chassis cluster on an SRX Series for the branch device:
![]() | Note: Perform Steps 1 through 5 on the primary device (node 0). They are automatically copied over to the secondary device (node 1) when you execute a commit command. The configurations are synchronized because the control link and fab link interfaces are activated. To verify the configurations, use the show interface terse command and review the output. |
- Set up hostnames and management IP addresses for each
device using configuration groups. These configurations are specific
to each device and are unique to its specific node.user@host# set groups node0 system host-name srx-node0user@host# set groups node0 interfaces fxp0 unit 0 family inet address 192.16.35.46/24user@host# set groups node1 system host-name srx-node1user@host# set groups node1 interfaces fxp0 unit 0 family inet address 192.16.35.47/24
Set the default route and backup router for each node.
user@host# set groups node0 system backup-router <backup next-hop from fxp0> destination <management network/mask>user@host# set groups node1 system backup-router <backup next-hop from fxp0> destination <management network/mask>Set the apply-group command so that the individual configurations for each node set by the previous commands are applied only to that node.
user@host# set apply-groups "${node}" - Define the interfaces used for the fab connection (data
plane links for RTO sync) by using physical ports ge-0/0/1 from each node. These interfaces must be connected back-to-back,
or through a Layer 2 infrastructure.user@host# set interfaces fab0 fabric-options member-interfaces ge-0/0/1user@host# set interfaces fab1 fabric-options member-interfaces ge-2/0/1
- Set up redundancy group 0 for the Routing Engine failover
properties, and set up redundancy group 1 (all interfaces are in one
redundancy group in this example) to define the failover properties
for the redundant Ethernet interfaces. user@host# set chassis cluster redundancy-group 0 node 0 priority 100user@host# set chassis cluster redundancy-group 0 node 1 priority 1user@host# set chassis cluster redundancy-group 1 node 0 priority 100user@host# set chassis cluster redundancy-group 1 node 1 priority 1
- Set up interface monitoring to monitor the health of the
interfaces and trigger redundancy group failover.
Note: We do not recommend Interface monitoring for redundancy group 0 because it causes the control plane to switch from one node to another node in case interface flap occurs.
user@host# set chassis cluster redundancy-group 1 interface-monitor fe-0/0/3 weight 255user@host# set chassis cluster redundancy-group 1 interface-monitor fe-0/0/2 weight 255user@host# set chassis cluster redundancy-group 1 interface-monitor fe-2/0/3 weight 255user@host# set chassis cluster redundancy-group 1 interface-monitor fe-2/0/2 weight 255Note: Interface failover only occurs after the weight reaches 0.
- Set up the redundant Ethernet (reth) interfaces and assign
the redundant interface to a zone. user@host# set chassis cluster reth-count 2user@host# set interfaces fe-0/0/2 fastether-options redundant-parent reth1user@host# set interfaces fe-2/0/2 fastether-options redundant-parent reth1user@host# set interfaces reth1 redundant-ether-options redundancy-group 1user@host# set interfaces reth1 unit 0 family inet address 1.2.0.233/24user@host# set interfaces fe-0/0/3 fastether-options redundant-parent reth0user@host# set interfaces fe-2/0/3 fastether-options redundant-parent reth0user@host# set interfaces reth0 redundant-ether-options redundancy-group 1user@host# set interfaces reth0 unit 0 family inet address 10.16.8.1/24user@host# set security zones security-zone Untrust interfaces reth1.0user@host# set security zones security-zone Trust interfaces reth0.0
Results
From operational mode, confirm your configuration by entering the show configuration command. If the output does not display the intended configuration, repeat the configuration instructions in this example to correct it.
For brevity, this show command output includes only the configuration that is relevant to this example. Any other configuration on the system has been replaced with ellipses (...).
> show configuration
version x.xx.x; groups { node0 { system { host-name SRX210-1; backup-router 10.100.22.1 destination 66.129.243.0/24; } interfaces { fxp0 { unit 0 { family inet { address 192.16.35.46/24; } } } } } node1 { system { host-name SRX210-2; backup-router 10.100.21.1 destination 66.129.243.0/24; } interfaces { fxp0 { unit 0 { family inet { address 192.16.35.47/24; } } } } } } apply-groups "${node}"; chassis { cluster { reth-count 2; redundancy-group 0 { node 0 priority 100; node 1 priority 1; } redundancy-group 1 { node 0 priority 100; node 1 priority 1; interface-monitor { fe–0/0/3 weight 255; fe–0/0/2 weight 255; fe–2/0/2 weight 255; fe–2/0/3 weight 255; } } } } interfaces { fe–0/0/2 { fastether–options { redundant–parent reth1; } unit 0 { family inet { address 2.2.2.2/30; } } } fe–0/0/3 { fastether–options { redundant–parent reth0; } } fe–2/0/2 { fastether–options { redundant–parent reth1; } } fe–2/0/3 { fastether–options { redundant–parent reth0; } } fab0 { fabric–options { member–interfaces { ge–0/0/1; } } } fab1 { fabric–options { member–interfaces { ge–2/0/1; } } } reth0 { redundant–ether–options { redundancy–group 1; } unit 0 { family inet { address 10.16.8.1/24; } } } reth1 { redundant–ether–options { redundancy–group 1; } unit 0 { family inet { address 1.2.0.233/24; } } } } ... security { zones { security–zone Untrust { interfaces { reth1.0; } } security–zone Trust { interfaces { reth0.0; } } } policies { from–zone Trust to–zone Untrust { policy 1 { match { source–address any; destination–address any; application any; } then { permit; } } } } }
If you are done configuring the device, enter commit from configuration mode.
Verification
Confirm that the configuration is working properly.
- Verifying Chassis Cluster Status
- Verifying Chassis Cluster Interfaces
- Verifying Chassis Cluster Statistics
- Verifying Chassis Cluster Control Plane Statistics
- Verifying Chassis Cluster Data Plane Statistics
- Verifying Chassis Cluster Redundancy Group Status
- Troubleshooting with Logs
Verifying Chassis Cluster Status
Purpose
Verify the chassis cluster status, failover status, and redundancy group information.
Action
From operational mode, enter the show chassis cluster status command.
{primary:node0}
user@host# show chassis cluster status
Cluster ID: 1 Node Priority Status Preempt Manual failover Redundancy group: 0 , Failover count: 1 node0 100 primary no no node1 1 secondary no no Redundancy group: 1 , Failover count: 1 node0 0 primary no no node1 0 secondary no no
Verifying Chassis Cluster Interfaces
Purpose
Verify information about chassis cluster interfaces.
Action
From operational mode, enter the show chassis cluster interfaces command.
{primary:node0}
user@host> show chassis cluster interfaces
Control link name: fxp1 Redundant-ethernet Information: Name Status Redundancy-group reth0 Up 1 reth1 Up 1 Interface Monitoring: Interface Weight Status Redundancy-group fe-2/0/3 255 Up 1 fe-2/0/2 255 Up 1 fe-0/0/2 255 Up 1 fe-0/0/3 255 Up 1
Verifying Chassis Cluster Statistics
Purpose
Verify information about the statistics of the different objects being synchronized, the fabric and control interface hellos, and the status of the monitored interfaces in the cluster.
Action
From operational mode, enter the show chassis cluster statistics command.
{primary:node0}
user@host> show chassis cluster statistics
Control link statistics: Control link 0: Heartbeat packets sent: 2276 Heartbeat packets received: 2280 Heartbeat packets errors: 0 Fabric link statistics: Child link 0 Probes sent: 2272 Probes received: 597 Services Synchronized: Service name RTOs sent RTOs received Translation context 0 0 Incoming NAT 0 0 Resource manager 6 0 Session create 161 0 Session close 148 0 Session change 0 0 Gate create 0 0 Session ageout refresh requests 0 0 Session ageout refresh replies 0 0 IPSec VPN 0 0 Firewall user authentication 0 0 MGCP ALG 0 0 H323 ALG 0 0 SIP ALG 0 0 SCCP ALG 0 0 PPTP ALG 0 0 RPC ALG 0 0 RTSP ALG 0 0 RAS ALG 0 0 MAC address learning 0 0 GPRS GTP 0 0
Verifying Chassis Cluster Control Plane Statistics
Purpose
Verify information about chassis cluster control plane statistics (heartbeats sent and received) and the fabric link statistics (probes sent and received).
Action
From operational mode, enter the show chassis cluster control-plane statistics command.
{primary:node0}
user@host> show chassis cluster control-plane
statistics
Control link statistics: Control link 0: Heartbeat packets sent: 2294 Heartbeat packets received: 2298 Heartbeat packets errors: 0 Fabric link statistics: Child link 0 Probes sent: 2290 Probes received: 615
Verifying Chassis Cluster Data Plane Statistics
Purpose
Verify information about the number of RTOs sent and received for services.
Action
From operational mode, enter the show chassis cluster data-plane statistics command.
{primary:node0}
user@host> show chassis cluster data-plane statistics
Services Synchronized: Service name RTOs sent RTOs received Translation context 0 0 Incoming NAT 0 0 Resource manager 6 0 Session create 161 0 Session close 148 0 Session change 0 0 Gate create 0 0 Session ageout refresh requests 0 0 Session ageout refresh replies 0 0 IPSec VPN 0 0 Firewall user authentication 0 0 MGCP ALG 0 0 H323 ALG 0 0 SIP ALG 0 0 SCCP ALG 0 0 PPTP ALG 0 0 RPC ALG 0 0 RTSP ALG 0 0 RAS ALG 0 0 MAC address learning 0 0 GPRS GTP 0 0
Verifying Chassis Cluster Redundancy Group Status
Purpose
Verify the state and priority of both nodes in a cluster and information about whether the primary node has been preempted or whether there has been a manual failover.
Action
From operational mode, enter the chassis cluster status redundancy-group command.
{primary:node0}
user@host> show chassis cluster status redundancy-group
1
Cluster ID: 1 Node Priority Status Preempt Manual failover Redundancy group: 1, Failover count: 1 node0 100 primary no no node1 50 secondary no no
Troubleshooting with Logs
Purpose
Use these logs to identify any chassis cluster issues. You should run these logs on both nodes.
Action
From operational mode, enter these show log commands.
user@host> show log jsrpd
user@host> show log chassisd
user@host> show log messages
user@host> show log dcd
user@host> show traceoptions
Published: 2015-02-27
Related Documentation
- SRX Series
- Understanding Chassis Cluster Redundancy Groups.
- Node Interfaces on Active SRX Series Chassis Clusters
- Example: Configuring an SRX Series Services Gateway for the High-End as a Chassis Cluster
- Additional Information
- Chassis Cluster Feature Guide for Security Devices