Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

Example: Configuring an Active/Passive Cluster Deployment

 

This example shows how to set up basic active/passive chassis clustering on a high-end SRX Series device.

Requirements

This example uses the following hardware and software components:

  • Two Juniper Networks SRX5800 Services Gateways with identical hardware configurations running Junos OS Release 9.6 or later.

  • One Juniper Networks MX240 3D Universal Edge Router running Junos OS Release 9.6 or later.

  • One Juniper Networks EX8208 Ethernet Switch running Junos OS Release 9.6 or later.

Note

This configuration example has been tested using the software release listed and is assumed to work on all later releases.

Before you begin:

  • Physically connect the two SRX Services Gateways (back-to-back for the fabric and control ports).

Note

This configuration example has been tested using the software release listed and is assumed to work on all later releases.

Overview

This example shows how to set up basic active/passive chassis clustering on a pair of high-end SRX Series devices. The basic active/passive example is the most common type of chassis cluster.

The basic active/passive chassis cluster consists of two devices:

  • One device actively provides routing, firewall, NAT, VPN, and security services, along with maintaining control of the chassis cluster.

  • The other device passively maintains its state for cluster failover capabilities should the active device become inactive.

Figure 1 shows the topology used in this example.

Figure 1: Basic Active/Passive Chassis Clustering Topology on a Pair of High-End SRX Series Devices
Basic Active/Passive Chassis
Clustering Topology on a Pair of High-End SRX Series Devices

Configuration

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 this example, perform the following procedures:

Configuring the Control Ports

Step-by-Step Procedure

Select FPC 1/13, because the central point (CP) is always on the lowest SPC/SPU in the cluster (for this example, it is slot 0). For maximum reliability, place the control ports on a separate SPC from the central point (for this example, use the SPC in slot 1). You must enter the operational mode commands on both devices.

Note

Control port configuration is required for SRX5600 and SRX5800 Services Gateways. No control port configuration is needed for SRX1400, SRX3400, or SRX3600 devices.

To configure the control port for each device and commit the configuration:

  1. Configure the control port for SRX5800-1 (node 0) and commit the configuration.
  2. Configure the control port for SRX5800-2 (node 1) and commit the configuration.

Enabling Cluster Mode

Step-by-Step Procedure

Before the cluster is formed, you must configure control ports for each device, as well as assign a cluster ID and node ID to each device.

A reboot is required to enter into cluster mode after the cluster ID and node ID are set. You can cause the system to boot automatically by including the reboot parameter in the CLI command line. You must enter the operational mode commands on both devices. When the system boots, both the nodes come up as a cluster.

Note

Since there is only a single cluster on the segments, the example uses cluster ID 1 with Device SRX5800-1 as node 0 and Device SRX5800-2 as node 1.

To set the two devices in cluster mode:

  1. Enable cluster mode on the SRX5800-1 (node 0).
  2. Enable cluster mode on the SRX5800-2 (node 1).
    Note

    If you have multiple SRX device clusters on a single broadcast domain, make sure that you assign different cluster IDs to each cluster to avoid MAC address conflict.

    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 1 through 15. Setting a cluster ID to 0 is equivalent to disabling a cluster.

    Now the devices are a pair. From this point forward, configuration of the cluster is synchronized between the node members, and the two separate devices function as one device.

Configuring Cluster Mode

Step-by-Step Procedure

Note

In cluster mode, the cluster is synchronized between the nodes when you execute a commit command. All commands are applied to both nodes regardless of which device the command is configured on.

To configure an active/passive chassis cluster on a pair of high-end SRX Series devices:

  1. Configure the fabric (data) ports of the cluster that are used to pass real-time objects (RTOs) in active/passive mode. This example uses one of the 1-Gigabit Ethernet ports. Define two fabric interfaces, one on each chassis, to connect together.
  2. Because the SRX Services Gateway chassis cluster configuration is contained within a single common configuration, use the Junos OS node-specific configuration method called groups to assign some elements of the configuration to a specific member only.

    The set apply-groups ${node} command uses the node variable to define how the groups are applied to the nodes. Each node recognizes its number and accepts the configuration accordingly. You must also configure out-of-band management on the fxp0 interface of the SRX5800 using separate IP addresses for the individual control planes of the cluster.

  3. Configure redundancy groups for chassis clustering.

    Each node has interfaces in a redundancy group where interfaces are active in active redundancy groups (multiple active interfaces can exist in one redundancy group). Redundancy group 0 controls the control plane and redundancy group 1+ controls the data plane and includes the data plane ports. For any active/passive mode cluster, only redundancy group 0 and redundancy group 1 need to be configured. This example uses two reth interfaces; both reth interfaces are members of redundancy group 1. Besides redundancy groups, you must also define:

    • Redundant Ethernet Interface count—Configure how many redundant Ethernet interfaces (reth) can possibly be configured so that the system can allocate the appropriate resources for it.

    • Priority for control plane and data plane—Define which device has priority (for chassis cluster, high priority is preferred) for the control plane, and which device is preferred to be active for the data plane.

      Note

      In active/passive or active/active mode, the control plane (redundancy group 0) can be active on a chassis different from the data plane (redundancy group 1+ and groups) chassis. However, for this example, we recommend having both the control and data plane active on the same chassis member.

  4. Configure the data interfaces on the platform so that in the event of a data plane failover, the other chassis cluster member can take over the connection seamlessly.

    Seamless transition to a new active node occurs with data plane failover. In case of control plane failover, all the daemons are restarted on the new node. This promotes a seamless transition to the new node without any packet loss.

    Define the following items:

    • Membership information of the member interfaces to the reth interface.

    • Which redundancy group the reth interface is a member of. For this active/passive example, it is always 1.

    • The reth interface information such as the IP address of the interface.

  5. Configure the chassis cluster behavior in case of a failure.

    Each interface is configured with a weight value that is deducted from the redundancy group threshold of 255 upon a link loss. The failover threshold is hard coded at 255 and cannot be changed. You can alter an interface link’s weights to determine the impact on the chassis failover.

    When a redundancy group threshold reaches 0, that redundancy group fails over to the secondary node.

    Enter the following commands on the SRX5800-1:

    This step completes the chassis cluster configuration part of the active/passive mode example for the SRX5800. The rest of this procedure describes how to configure the zone, virtual router, routing, the EX8208, and the MX480 to complete the deployment scenario.

Configuring Zones, Virtual Routers, and Routes

Step-by-Step Procedure

Configure and connect the reth interfaces to the appropriate zones and virtual routers. For this example, leave the reth0 and reth1 interfaces in the virtual router (default) and the routing table (inet.0), which does not require any additional configuration.

To configure zones, virtual routers, and routes:

  1. Configure reth interfaces to the appropriate zones and virtual routers.
  2. Configure static routes to the other network devices.

Configuring the EX8208

Step-by-Step Procedure

For the EX8208, the following commands provide only an outline of the applicable configuration as it pertains to this active/passive full mesh example for the SRX5800, most notably the VLANs, routing, and interface configuration.

To configure the EX8208:

  1. Configure the interfaces.
  2. Configure the VLANs.
  3. Configure a static route.

Configuring the MX240

Step-by-Step Procedure

For the MX240, the following commands provide only an outline of the applicable configuration as it pertains to this active/passive mode example for the SRX5800, most notably you must use an integrated routing and bridging (IRB) interface within a virtual switch instance on the switch.

To configure the MX240:

  1. Configure the interfaces.
  2. Configure the static routes.
  3. Configure the bridge domains.

Configuring Miscellaneous Settings

Step-by-Step Procedure

This active/passive mode example for the SRX5800 does not describe in detail miscellaneous configurations such as how to configure NAT, security policies, or VPNs. They are essentially the same as they would be for standalone configurations.

However, if you are performing proxy ARP in chassis cluster configurations, you must apply the proxy ARP configurations to the reth interfaces rather than the member interfaces because the RETH interfaces hold the logical configurations.

You can also configure separate logical interface configurations using VLANs and trunked interfaces in the SRX5800. These configurations are similar to the standalone implementations using VLANs and trunked interfaces.

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.

{primary:node0}
user@host>show chassis cluster status

Meaning

The sample output shows the status of the primary and secondary nodes and that there are no manual fail overs.

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

Meaning

The sample output shows each interface’s status, weight value, and the redundancy group to which that interface belongs.

Verifying Chassis Cluster Statistics

Purpose

Verify information about chassis cluster services and control link statistics (heartbeats sent and received), fabric link statistics (probes sent and received), and the number of real-time objects (RTOs) sent and received for services.

Action

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

{primary:node0}
user@host> show chassis cluster statistics

Meaning

Use the sample output to:

  • Verify that the Heartbeat packets sent is incrementing.

  • Verify that the Heartbeat packets received is a number close to the number of Heartbeats packets sent.

  • Verify that the Heartbeats packets errors is zero.

This verifies that the heartbeat packets are being transmitted and received without errors.

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

Meaning

Use the sample output to:

  • Verify that the Heartbeat packets sent is incrementing.

  • Verify that the Heartbeat packets received is a number close to the number of Heartbeats packets sent.

  • Verify that the Heartbeats packets errors is zero.

This verifies that the heartbeat packets are being transmitted and received without errors.

Verifying Chassis Cluster Data Plane Statistics

Purpose

Verify information about the number of real-time objects (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

Meaning

The sample output shows the number of RTOs sent and received for various services.

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 show chassis cluster status redundancy-group command.

{primary:node0}
user@host> show chassis cluster status redundancy-group 1

Meaning

The sample output shows the status of the primary and secondary nodes and that there are no manual fail overs.

Troubleshooting with Logs

Purpose

Look at the system log files to identify any chassis cluster issues. You should look at the system log files 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

Results

From operational mode, confirm your configuration by entering the show configuration command. If the output does not display the intended configuration, repeat the user@host instructions in this example to correct the configuration.

If you are done configuring the device, enter commit from configuration mode.