Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

close
keyboard_arrow_left
list Table of Contents
file_download PDF
{ "lLangCode": "en", "lName": "English", "lCountryCode": "us", "transcode": "en_US" }
English
keyboard_arrow_right

Configuring Chassis Clustering on SRX Series Devices

date_range 28-Nov-23

SRX Series Services gateways can be configured to operate in cluster mode, where a pair of devices can be connected together and configured to operate like a single device to provide high availability. When configured as a chassis cluster, the two nodes back up each other, with one node acting as the primary device and the other as the secondary device, ensuring stateful failover of processes and services in the event of system or hardware failure. If the primary device fails, the secondary device takes over processing of traffic.

For SRX300, SRX320, SRX340, SRX345, and SRX380 devices, connect ge-0/0/1 on node 0 to ge-0/0/1 on node 1. The factory-default configuration does not include HA configuration. To enable HA, if the physical interfaces used by HA have some configurations, these configurations need to be removed. Table 1 lists the physical interfaces used by HA on SRX300, SRX320, SRX340, SRX345, and SRX380.

Table 1: Mapping Between HA Interface and Physical Interface on SRX300, SRX320, SRX340, SRX345, and SRX380

Device

fxp0 Interface (HA MGT)

fxp1 Interface (HA Control)

Fab Interface

SRX300

ge-0/0/0

ge-0/0/1

User defined

SRX320

ge-0/0/0

ge-0/0/1

User defined

SRX340

dedicated

ge-0/0/1

User defined

SRX345

dedicated

ge-0/0/1

User defined

SRX380

dedicated

ge-0/0/1

User defined

For more information, see the following topics:

Example: Configure Chassis Clustering on SRX Series Firewalls

This example shows how to set up chassis clustering on an SRX Series Firewall (using SRX1500 or SRX1600 as example).

Requirements

Before you begin:

  • Physically connect the two devices and ensure that they are the same models. For example, on the SRX1500 or SRX1600 Firewall, connect the dedicated control ports on node 0 and 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:

      content_copy zoom_out_map
      user@host> set chassis cluster cluster-id 1 node 0 reboot
      
    • On node 1:

      content_copy zoom_out_map
      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 255 and setting it to 0 is equivalent to disabling cluster mode.

  • After clustering occurs for the devices, continuing with the SRX1500 or SRX1600 Firewall example, the ge-0/0/0 interface on node 1 changes to ge-7/0/0.

    After clustering occurs,

    • For SRX300 devices, the ge-0/0/1 interface on node 1 changes to ge-1/0/1.

    • For SRX320 devices, the ge-0/0/1 interface on node 1 changes to ge-3/0/1.

    • For SRX340 and SRX345 devices, the ge-0/0/1 interface on node 1 changes to ge-5/0/1.

    After the reboot, the following interfaces are assigned and repurposed to form a cluster:

    • For SRX300 and SRX320 devices, ge-0/0/0 becomes fxp0 and is used for individual management of the chassis cluster.

    • SRX340 and SRX345 devices contain a dedicated port fxp0.

    • For all SRX300, SRX320, SRX340, SRX345, and SRX380 devices, ge-0/0/1 becomes fxp1 and is used as the control link within the chassis cluster.

    • The other interfaces are also renamed on the secondary device.

    See Understanding SRX Series Chassis Cluster Slot Numbering and Physical Port and Logical Interface Naming for complete mapping of the SRX Series Firewalls.

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 Firewall using the SRX1500 or SRX1600 device as example.

The node 1 renumbers its interfaces by adding the total number of system FPCs to the original FPC number of the interface. See Table 2 for interface renumbering on the SRX Series Firewall.

Table 2: SRX Series Firewalls Interface Renumbering

SRX Series Services Gateway

Renumbering Constant

Node 0 Interface Name

Node 1 Interface Name

SRX300

1

ge-0/0/0

ge-1/0/0

SRX320

3

ge-0/0/0

ge-3/0/0

SRX340

SRX345

SRX380

5

ge-0/0/0

ge-5/0/0

SRX1500

7

ge-0/0/0

ge-7/0/0

SRX1600

7

ge-0/0/0

ge-7/0/0

After clustering is enabled, the system creates fxp0, fxp1, and em0 interfaces. Depending on the device, the fxp0, fxp1, and em0 interfaces that are mapped to a physical interface are not user defined. However, the fab interface is user defined.

Figure 1 shows the topology used in this example.

Figure 1: SRX Series Firewalls (SRX1500) In Chassis ClusterSRX Series Firewalls (SRX1500) In Chassis Cluster

Configuration

Procedure

CLI Quick Configuration

To quickly configure a chassis cluster on an SRX1500 Firewall, copy the following commands and paste them into the CLI:

On {primary:node0}

content_copy zoom_out_map
[edit]
set groups node0 system host-name srx1500-1
set groups node0 interfaces fxp0 unit 0 family inet address 192.16.35.46/24
set groups node1 system host-name srx1500-2
set groups node1 interfaces fxp0 unit 0 family inet address 192.16.35.47/24
set groups node0 system backup-router <backup next-hop from fxp0> destination <management network/mask>
set groups node1 system backup-router <backup next-hop from fxp0> destination <management network/mask>
set apply-groups "${node}"
set interfaces fab0 fabric-options member-interfaces ge-0/0/1
set interfaces fab1 fabric-options member-interfaces ge-7/0/1
set chassis cluster redundancy-group 0 node 0 priority 100
set chassis cluster redundancy-group 0 node 1 priority 1
set chassis cluster redundancy-group 1 node 0 priority 100
set chassis cluster redundancy-group 1 node 1 priority 1
set chassis cluster redundancy-group 1 interface-monitor ge-0/0/5 weight 255
set chassis cluster redundancy-group 1 interface-monitor ge-0/0/4 weight 255
set chassis cluster redundancy-group 1 interface-monitor ge-7/0/5 weight 255
set chassis cluster redundancy-group 1 interface-monitor ge-7/0/4 weight 255
set chassis cluster reth-count 2
set interfaces ge-0/0/5 gigether-options redundant-parent reth1
set interfaces ge-7/0/5 gigether-options redundant-parent reth1
set interfaces reth1 redundant-ether-options redundancy-group 1
set interfaces reth1 unit 0 family inet address 203.0.113.233/24
set interfaces ge-0/0/4 gigether-options redundant-parent reth0
set interfaces ge-7/0/4 gigether-options redundant-parent reth0
set interfaces reth0 redundant-ether-options redundancy-group 1
set interfaces reth0 unit 0 family inet address 198.51.100.1/24
set security zones security-zone Untrust interfaces reth1.0
set security zones security-zone Trust interfaces reth0.0 

If you are configuring SRX300, SRX320, SRX340, SRX345, and SRX380 devices, see Table 3 for command and interface settings for your device and substitute these commands into your CLI.

Table 3: SRX Series Firewalls Interface Settings

Command

SRX300

SRX320

SRX340

SRX345

SRX380

set interfaces fab0 fabric-options member-interfaces

ge-0/0/2

ge-0/0/2

ge-0/0/2

set interfaces fab1 fabric-options member-interfaces

ge-1/0/2

ge-3/0/2

ge-5/0/2

set chassis cluster redundancy-group 1 interface-monitor

ge-0/0/3 weight 255

ge-0/0/3 weight 255

ge-0/0/3 weight 255

set chassis cluster redundancy-group 1 interface-monitor

ge-0/0/4 weight 255

ge-0/0/4 weight 255

ge-0/0/4 weight 255

set chassis cluster redundancy-group 1 interface-monitor

ge-1/0/3 weight 255

ge-3/0/3 weight 255

ge-5/0/3 weight 255

set chassis cluster redundancy-group 1 interface-monitor

ge-1/0/4 weight 255

ge-3/0/4 weight 255

ge-5/0/4 weight 255

set interfaces

ge-0/0/3 gigether-options redundant-parent reth0

ge-0/0/3 gigether-options redundant-parent reth0

ge-0/0/3 gigether-options redundant-parent reth0

set interfaces

ge-0/0/4 gigether-options redundant-parent reth1

ge-0/0/4 gigether-options redundant-parent reth1

ge-0/0/4 gigether-options redundant-parent reth1

set interfaces

ge-1/0/3 gigether-options redundant-parent reth0

ge-3/0/3 gigether-options redundant-parent reth0

ge-5/0/3 gigether-options redundant-parent reth0

set interfaces

ge-1/0/4 gigether-options redundant-parent reth1

ge-3/0/4 gigether-options redundant-parent reth1

ge-5/0/4 gigether-options redundant-parent reth1

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 in the CLI User Guide.

To configure a chassis cluster on an SRX Series Firewall:

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.

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

    content_copy zoom_out_map
    user@host# set groups node0 system host-name srx1500-1
    user@host# set groups node0 interfaces fxp0 unit 0 family inet address 192.16.35.46/24
    user@host# set groups node1 system host-name srx1500-2
    user@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.

    content_copy zoom_out_map
    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.

    content_copy zoom_out_map
    user@host# set apply-groups "${node}"
    
  2. 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.

    content_copy zoom_out_map
    user@host# set interfaces fab0 fabric-options member-interfaces ge-0/0/1
    user@host# set interfaces fab1 fabric-options member-interfaces ge-7/0/1
    
  3. 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.

    content_copy zoom_out_map
    user@host# set chassis cluster redundancy-group 0 node 0 priority 100
    user@host# set chassis cluster redundancy-group 0 node 1 priority 1
    user@host# set chassis cluster redundancy-group 1 node 0 priority 100
    user@host# set chassis cluster redundancy-group 1 node 1 priority 1
    
  4. Set up interface monitoring to monitor the health of the interfaces and trigger redundancy group failover.

    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.

    content_copy zoom_out_map
    user@host# set chassis cluster redundancy-group 1 interface-monitor ge-0/0/5 weight 255
    user@host# set chassis cluster redundancy-group 1 interface-monitor ge-0/0/4 weight 255
    user@host# set chassis cluster redundancy-group 1 interface-monitor ge-7/0/5 weight 255
    user@host# set chassis cluster redundancy-group 1 interface-monitor ge-7/0/4 weight 255
    

    Interface failover only occurs after the weight reaches 0.

  5. Set up the redundant Ethernet (reth) interfaces and assign the redundant interface to a zone.

    content_copy zoom_out_map
    user@host# set chassis cluster reth-count 2
    user@host# set interfaces ge-0/0/5 gigether-options redundant-parent reth1
    user@host# set interfaces ge-7/0/5 gigether-options redundant-parent reth1
    user@host# set interfaces reth1 redundant-ether-options redundancy-group 1
    user@host# set interfaces reth1 unit 0 family inet address 203.0.113.233/24
    user@host# set interfaces ge-0/0/4 gigether-options redundant-parent reth0
    user@host# set interfaces ge-7/0/4 gigether-options redundant-parent reth0
    user@host# set interfaces reth0 redundant-ether-options redundancy-group 1
    user@host# set interfaces reth0 unit 0 family inet address 198.51.100.1/24
    user@host# set security zones security-zone Untrust interfaces reth1.0
    user@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 (...).

content_copy zoom_out_map
> show configuration
version x.xx.x;
groups { 
    node0 { 
        system { 
            host-name SRX1500-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 SRX1500-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 {
                ge–0/0/5 weight 255;
                ge–0/0/4 weight 255;
                ge–7/0/5 weight 255;
                ge–7/0/4 weight 255;
            }
        } 
    }
}
interfaces { 
    ge–0/0/5 {
        gigether–options {
            redundant–parent reth1; 
        } 
    } 
    ge–0/0/4 { 
        gigether–options {
            redundant–parent reth0; 
        } 
    } 
    ge–7/0/5 { 
        gigether–options {
            redundant–parent reth1; 
        } 
    } 
    ge–7/0/4 { 
        gigether–options {
            redundant–parent reth0; 
        } 
    } 
    fab0 { 
        fabric–options {
            member–interfaces {
                ge–0/0/1;
            } 
        } 
    } 
    fab1 { 
        fabric–options {
            member–interfaces {
                ge–7/0/1;
            } 
        } 
    } 
    reth0 { 
        redundant–ether–options { 
            redundancy–group 1;
        }
        unit 0 { 
            family inet {
                address 198.51.100.1/24;
            } 
        } 
    } 
    reth1 { 
        redundant–ether–options { 
            redundancy–group 1;
        }
        unit 0 { 
            family inet {
                address 203.0.113.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

Purpose

Verify the chassis cluster status, failover status, and redundancy group information.

Action

From operational mode, enter the show chassis cluster status command.

content_copy zoom_out_map
{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.

content_copy zoom_out_map
{primary:node0}
user@host> show chassis cluster interfaces
Control link name: em0

Redundant-ethernet Information:
    Name         Status      Redundancy-group
    reth0        Up          1
    reth1        Up          1

Interface Monitoring:
    Interface         Weight    Status    Redundancy-group
    ge-7/0/5          255       Up        1
    ge-7/0/4          255       Up        1
    ge-0/0/5          255       Up        1
    ge-0/0/4          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.

content_copy zoom_out_map
{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.

content_copy zoom_out_map
{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.

content_copy zoom_out_map
{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.

content_copy zoom_out_map
{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.

content_copy zoom_out_map
user@host> show log jsrpd
user@host> show log chassisd
user@host> show log messages
user@host> show log dcd
user@host> show traceoptions

Viewing a Chassis Cluster Configuration

Purpose

Display chassis cluster verification options.

Action

From the CLI, enter the show chassis cluster ? command:

content_copy zoom_out_map
{primary:node1}
user@host> show chassis cluster ?
Possible completions:
  interfaces           Display chassis-cluster interfaces
  statistics           Display chassis-cluster traffic statistics
  status               Display chassis-cluster status

Viewing Chassis Cluster Statistics

Purpose

Display information about chassis cluster services and interfaces.

Action

From the CLI, enter the show chassis cluster statistics command:

content_copy zoom_out_map
{primary:node1}
user@host> show chassis cluster statistics

Control link statistics:
    Control link 0:
        Heartbeat packets sent: 798
        Heartbeat packets received: 784
Fabric link statistics:
    Child link 0
        Probes sent: 793
        Probes received: 0
Services Synchronized:
    Service name                              RTOs sent    RTOs received
    Translation context                       0            0
    Incoming NAT                              0            0
    Resource manager                          0            0
    Session create                            0            0
    Session close                             0            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
    RTSP ALG                                  0            0
content_copy zoom_out_map
{primary:node1}
user@host> show chassis cluster statistics

Control link statistics:
    Control link 0:
        Heartbeat packets sent: 258689
        Heartbeat packets received: 258684
    Control link 1:
        Heartbeat packets sent: 258689
        Heartbeat packets received: 258684
Fabric link statistics:
    Child link 0
        Probes sent: 258681
        Probes received: 258681
    Child link 1
        Probes sent: 258501
        Probes received: 258501
Services Synchronized:
    Service name                              RTOs sent    RTOs received
    Translation context                       0            0
    Incoming NAT                              0            0
    Resource manager                          0            0
    Session create                            1            0
    Session close                             1            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
content_copy zoom_out_map
{primary:node1}
user@host> show chassis cluster statistics

Control link statistics:
    Control link 0:
        Heartbeat packets sent: 82371
        Heartbeat packets received: 82321
    Control link 1:
        Heartbeat packets sent: 0
        Heartbeat packets received: 0

Clearing Chassis Cluster Statistics

To clear displayed information about chassis cluster services and interfaces, enter the clear chassis cluster statistics command from the CLI:

content_copy zoom_out_map
{primary:node1}
user@host> clear chassis cluster statistics

Cleared control-plane statistics
Cleared data-plane statistics

Understanding Automatic Chassis Cluster Synchronization Between Primary and Secondary Nodes

When you set up an SRX Series chassis cluster, the SRX Series Firewalls must be identical, including their configuration. The chassis cluster synchronization feature automatically synchronizes the configuration from the primary node to the secondary node when the secondary joins the primary as a cluster. By eliminating the manual work needed to ensure the same configurations on each node in the cluster, this feature reduces expenses.

If you want to disable automatic chassis cluster synchronization between the primary and secondary nodes, you can do so by entering the set chassis cluster configuration-synchronize no-secondary-bootup-auto command in configuration mode.

At any time, to reenable automatic chassis cluster synchronization, use the delete chassis cluster configuration-synchronize no-secondary-bootup-auto command in configuration mode.

To see whether the automatic chassis cluster synchronization is enabled or not, and to see the status of the synchronization, enter the show chassis cluster information configuration-synchronization operational command.

Either the entire configuration from the primary node is applied successfully to the secondary node, or the secondary node retains its original configuration. There is no partial synchronization.

If you create a cluster with cluster IDs greater than 16, and then decide to roll back to a previous release image that does not support extended cluster IDs, the system comes up as standalone.

If you have a cluster set up and running with an earlier release of Junos OS, you can upgrade to Junos OS Release 12.1X45-D10 and re-create a cluster with cluster IDs greater than 16. However, if for any reason you decide to revert to the previous version of Junos OS that did not support extended cluster IDs, the system comes up with standalone devices after you reboot. However, if the cluster ID set is less than 16 and you roll back to a previous release, the system will come back with the previous setup.

Verifying Chassis Cluster Configuration Synchronization Status

Purpose

Display the configuration synchronization status of a chassis Understanding Automatic Chassis Cluster Synchronization Between Primary and Secondary Nodescluster.

Action

From the CLI, enter the show chassis cluster information configuration-synchronization command:

content_copy zoom_out_map
{primary:node0}
user@host> show chassis cluster information configuration-synchronization

node0:
--------------------------------------------------------------------------

Configuration Synchronization:
    Status:
        Activation status: Enabled
        Last sync operation: Auto-Sync
        Last sync result: Not needed
        Last sync mgd messages:

    Events:
        Mar  5 01:48:53.662 : Auto-Sync: Not needed.

node1:
--------------------------------------------------------------------------

Configuration Synchronization:
    Status:
        Activation status: Enabled
        Last sync operation: Auto-Sync
        Last sync result: Succeeded
        Last sync mgd messages:
            mgd: rcp: /config/juniper.conf: No such file or directory
            mgd: commit complete

    Events:
        Mar  5 01:48:55.339 : Auto-Sync: In progress. Attempt: 1
        Mar  5 01:49:40.664 : Auto-Sync: Succeeded. Attempt: 1
external-footer-nav