Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

Example: Configuring an Active/Active Layer 3 Cluster Deployment

 

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

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.

  • Two Juniper Networks EX8208 Ethernet Switches running Junos OS Release 9.6 or later.

    • Any EX Series switch can be used here.

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

A chassis cluster consists of two SRX Series devices with identical hardware. Active/active clustering on SRX Series devices is supported for those environments that want to maintain traffic on both chassis cluster members whenever possible. In an active/active deployment, only the data plane is in active/active mode; the control plane is in active/passive mode. This allows one control plane to control both chassis members as a single logical device, allowing the control plane to fail over to the other device in case of failure. Having only the data plane in active/active mode allows the data plane to failover independently of the control plane.

Active/active configuration also allows ingress interfaces to be on one cluster device and the egress interfaces to be on the other. When the ingress and egress interfaces are set up on different devices, the data traffic must pass through the data fabric to the other cluster device and out the egress interface.

This active/active chassis clustering example requires you to configure two redundant Ethernet (reth) interfaces—reth0 and reth1—for each node and ensure they are connected together by one or more switches. A reth interface bundles the two physical interfaces (one from each node) together. A reth interface is assigned to a redundancy group.

Figure 1 shows the topology used in this example.

Figure 1: Active/Active Layer 3 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

Configure the control port for each device.

Select FPC 1 and FPC 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 (this example uses the SPC in slot 1).

Note

Control port configuration is required only for SRX5600 and SRX5800 devices. No control port configuration is needed for SRX1400, SRX3400, and SRX3600 devices because they use a fixed control port.

  1. Configure the control ports and commit the configuration:

Enabling Cluster Mode

Step-by-Step Procedure

Assign a cluster ID and node ID to each device.

Set the two devices to cluster mode by adding a cluster ID and node ID on each and rebooting. You can configure the system to boot automatically by including the reboot parameter in the set command.

Note

Since there is only a single cluster on the segments, this 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 SRX5800-1 (node 0).
  2. Enable cluster mode on 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 conflicts.

    When the system reboots, the nodes come up as a cluster. 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 Parameters

Step-by-Step Procedure

Note

In cluster mode, all commands and configuration are applied to both nodes.

To configure chassis cluster settings:

  1. Configure a fabric (data) port on each device to enable traffic to pass from one device to the other for cases where traffic arrives on an ingress interface on one node but leaves on another node.Note

    A 10-Gigabit Ethernet connection is recommended for active/active deployments.

  2. Configure each device’s fxp0 interface for out-of-band management. Assign a separate IP address for each device (control plane) of the cluster.

    Because the SRX Services Gateway chassis cluster configuration is contained within a single common configuration, to assign some elements of the configuration to a specific member only, use the Junos OS node-specific configuration method called groups. 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.

  3. Configure redundancy groups for chassis clustering.

    Each node has interfaces in a redundancy group. Redundancy group 0 controls the control plane, it defines which node will be the primary. Redundancy group 1+ controls the data plane and includes the data plane ports. This active/active clustering mode example uses 2 reth interfaces with redundancy groups 0, 1, and 2.

    As part of redundancy group configuration, you must also define the priority for control plane and data plane—which device is preferred for the control plane, and which device is preferred for the data plane. (For chassis clustering, higher priority is preferred.)

    Note

    The control plane (redundancy group 0) and data plane (redundancy group 1+) can each be active on a different chassis. However, for this example, we recommend having both the control and data plane active on the same chassis member. Redundancy group 0 (RG0) and redundancy group 1 (RG1) default to the active state on node 0, whereas, redundancy group 2 (RG2) defaults to active state on node 1.

  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.

    Define the following items:

    • The maximum number of reth interfaces for the cluster, so that the system can allocate the appropriate resources for them.

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

    • Membership information of the member interfaces to reth interfaces.

    • The mapping of reth interfaces to redundancy groups.

  5. Configure the 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. When a redundancy group threshold reaches 0, that redundancy group fails over to the secondary node.

    Note

    If the control-link-recovery feature is not enabled, a manual reboot is required to bring the secondary node back into sync with the primary node.

    Note

    Individual VLANs on an interface are not monitored. Only interfaces as a whole are monitored.

    This step completes the chassis cluster configuration.

  6. Configure other interfaces that do not belong to the reth interfaces. These are the upstream interfaces towards the ISPs.

    The following sections describe how to configure zones, security policies, NAT, routing, and the EX8208 Core Switches to complete the deployment scenario.

Configuring Zones, Policies, NAT, and Routes

Step-by-Step Procedure

Configure and connect the reth interfaces to the appropriate zones and define a security policy that permits outbound traffic. Also, for this example we will use a default route and NAT to enable end hosts to reach the Internet.

To configure zones, policies, NAT, and routes:

  1. Assign the interfaces to the appropriate zones.
  2. Configure a policy to allow traffic from the hosts in the trust zone to the Internet.
  3. Configure source NAT for outbound traffic.
  4. Define a default static route to enable hosts to reach the Internet.

Configuring the EX8208-1

Step-by-Step Procedure

For the EX8208, the following commands provide configuration only as it pertains to this active/active example for the SRX5800, most notably the VLANs, routing, and interface configuration.

  1. Configure the interfaces.
    Note

    The end host is sending untagged traffic.

  2. Configure the VLANs.
  3. Enable RSTP.
    Note

    In this example, RSTP is not strictly required as there is no Layer 2 loop. However, a typical environment would likely have more switches, which would require the protocol to be enabled.

Configuring the EX8208-2

Step-by-Step Procedure

To configure the EX8208-2:

  1. Configure the interfaces.
    Note

    The end host is sending untagged traffic.

  2. Configure the VLANs.
  3. Enable RSTP.
    Note

    In this example, RSTP is not strictly required as there is no Layer 2 loop. However, a typical environment would likely have more switches, which would require the protocol to be enabled.

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.

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.

Meaning

The sample output provides status information about the control and fabric links. It also shows each reth interface’s status, weight value, and redundancy group.

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.

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.

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.

Meaning

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

Verifying Chassis Cluster Redundancy Group Status

Purpose

Verify the status of a redundancy group.

Action

From operational mode, enter the chassis cluster status redundancy-group command.

Meaning

The sample output shows that redundancy group 1 is functioning normally, with no preemptions, manual fail overs, or other failures.

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.

Results

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

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