Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Example: Configure Multinode High Availability in a Default Gateway Deployment

SUMMARY In this example, you'll establish Multinode High Availability between SRX Series devices in a default gateway (Layer 2 network) deployment.

Overview

In Multi-Node High Availability, participating SRX Series devices operate as independent nodes in a Layer 2 network. An encrypted logical interchassis link (ICL) connects the nodes over a routed network. Participating nodes backup each other to ensure a fast synchronized failover in case of system or hardware failure.

In Multinode High Availability, activeness is determined at the services redundancy group (SRG) level. The SRX Series device, on which the SRG1 is active, hosts the floating IP address and steers traffic towards it using the floating IP address. During a failover, the floating IP address moves from the old active node to the new active node and continues the communication client devices.

Note:

As of Junos OS Release 22.3R1, we support a two-node configuration in the Multinode High Availability solution.

Lets start with an overview about the topology you'll be using in this example.

Requirements

This example uses the following hardware and software components:

  • Two SRX Series devices or vSRX instances

  • Two Juniper Networks EX9214 Ethernet Switches

  • Junos OS Release 22.3R1

Topology

Figure 1 shows the topology used in this example.

Figure 1: Multinode High Availability in Default Gateway Deployment Multinode High Availability in Default Gateway Deployment

As shown in the topology, two SRX Series devices are connected to switches on trust and untrust side. An encrypted logical interchassis link (ICL) connects the nodes over a routed network. The nodes communicate with each other using a routable IP address (floating IP address) over the network. Loopback interfaces are used to host the IP addresses on SRX Series devices.

In general, you can use Aggregated Ethernet (AE) or a revenue Ethernet port on the SRX Series devices to setup an ICL connection. In this example, we've used GE ports for the ICL. We've also configured a routing instance for the ICL path to ensure maximum segmentation.

In a typical high availability deployment, you have multiple routers and switches on the northbound and southbound sides of the network. For this example, we are using two switches on both sides of SRX Series devices.

You'll perform the following tasks to build a Multinode High Availability setup:

  • Configure a pair of SRX Series devices as local and peer nodes by assigning IDs.
  • Configure services redundancy groups (SRGs).
  • Configure virtual IP addresses for activeness determination and enforcement.
  • Configure a VPN profile for the high availability (ICL) traffic using IKEv2.
  • Configure appropriate security policies to manage traffic in your network.
  • Configure stateless firewall filtering and quality of service (QoS) as per your network requirements.

  • Configure interfaces and zones according your network requirement. You must allow services such as IKE for link encryption and SSH for configuration synchronization as host inbound system services on the security zone that is associated with the ICL.

You can configure the following options on SRG0 and SRG1:

  • SRG1: Active/backup signal route, deployment type, activeness priority, preemption, virtual IP address (for default gateway deployments), activeness probing and process packet on backup.

  • SRG1: BFD monitoring, IP monitoring, and interface monitoring options on SRG1.

  • SRG0: shutdown on failure and install on failure route options.

    When you configure monitoring (BFD or IP or Interface) options under SRG1, we recommend not to configure the shutdown-on-failure option under SRG0.

For interchassis link (ICL), we recommend the following configuration settings:

  • Use a loopback (lo0) interface using an aggregated Ethernet interface (ae0), or any revenue Ethernet interface to establish the ICL. Do not to use the dedicated HA ports (control and fabric ports) if available on your SRX Series device).
  • Set MTU of 1514
  • Allow the following services on the security zone associated with interfaces used for ICL
    • IKE, high-availability, SSH

    • Protocols depends on the routing protocols you need

    • BFD to monitor the neighboring routes

Configuration

Before You Begin

Install the Junos IKE package on your SRX Series. You require this step for ICL encryption.

CLI Quick Configuration

To quickly configure this example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, copy and paste the commands into the CLI at the [edit] hierarchy level, and then enter commit from configuration mode.

These configurations are captured from a lab environment, and are provided for reference only. Actual configurations may vary based on the specific requirements of your environment.

On SRX-1 Device

On SRX-2 Device

The following sections show configuration snippets on the switches required for setting up Multinode High Availability setup in the network.

On Switch (EX9214 Ethernet Switch)

On Switch (EX9214 Ethernet Switch)

Configuration

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.

  1. Configure Interfaces.

    We're using the interfaces ge-0/0/3 and ge-0/0/4 to connect to the switches, and using the ge-0/0/2 interface for ICL.

  2. Configure the loopback interface.

    Assign the IP address (10.11.0.1) to the loopback interface. This IP address acts as the floating IP address.

    Using the loopback interface ensures that at any given point, traffic from the adjacent devices will be steered toward the floating IP address (that is toward the active node).

  3. Configure the security policy.

    Ensure you have configured security policies as per your network requirements. In this example, you'll configure a policy to permit all traffic.

  4. Configure security zones, assign interfaces to the zones, and specify the allowed system services for the security zones.

    Assign the interfaces ge-0/0/3 and ge-0/0/4 to the trust and untrust zones respectively. Assign the lo0.0 interface to the untrust zone to connect over the public IP network. Assign the interface ge-0/0/2 to the halink zone. You use this zone to setup the ICL.

  5. Configure routing options.

  6. Configure both local node and peer node details such as node ID, lP addresses of the local node and peer node, and the interface for the peer node.

    You'll use the ge-0/0/2 interface for communicating with the peer node using the ICL.

  7. Attach the IPsec VPN profile IPSEC_VPN_ICL to the peer node.

    You'll need this configuration to establish a secure ICL link between the nodes.

  8. Configure Bidirectional Forwarding Detection (BFD) protocol options for the peer node.

  9. Associate the peer node ID 2 to the services redundancy group 0 (SRG0).

  10. Configure the services redundancy group 1 (SRG1).

    In this step, you are specifying the deployment type as switching because you are setting up Multinode High Availability as default gateway (Layer 2 network).

    Assign a virtual IP (VIP) address and an interface for SRG1.

  11. Configure IP and BFD monitoring parameters for SRG1 to check the reachability of an IP address and to detect failures in network.

  12. Configure an active signal route required for activeness enforcement.

    The active signal route IP address you assign is used for route preference advertisement. You must specify the active signal route along with the route-exists policy in the policy-options statement.

  13. Configure CA certificates as per your requirements.

  14. Define Internet Key Exchange (IKE) configuration for Multinode High Availability. An IKE configuration defines the algorithms and keys used to establish a secure connection.

    For the Multinode High availability feature, you must configure the IKE version as v2-only

  15. Specify the IPsec proposal protocol and encryption algorithm. Specify IPsec options to create a IPsec tunnel between two participant devices to secure VPN communication.

    Specifying the ha-link-encryption option encrypts the ICL to secure high availability traffic flow between the nodes.

    The same VPN name IPSEC_VPN_ICL must be mentioned for vpn_profile in chassis high availability configuration.

Configuration Options for Software Upgrades

In Multinode High Availability, during software upgrade, you can divert the traffic by closing down interfaces on the node. Here, traffic cannot pass through the nodes. Check Software Upgrade in Multinode High Availability for details.

  1. Configure all traffic interfaces under “shutdown-on-failure” option. Example:
    CAUTION:

    Donot use interfaces assigned for the interchassis link (ICL).

Results (SRX-1)

From configuration mode, confirm your configuration by entering the following commands. If the output does not display the intended configuration, repeat the configuration instructions in this example to correct it.

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

Results (SRX-2)

From configuration mode, confirm your configuration by entering the following commands. If the output does not display the intended configuration, repeat the configuration instructions in this example to correct it.

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

On your security devices, you'll get the following message that asks you to reboot the device:

Verification

Confirm that the configuration is working properly.

Check Multinode High Availability Details

Purpose

View and verify the details of the Multinode High Availability setup configured on your security device.

Action

From operational mode, run the following command:

On SRX-1

On SRX-2

Meaning

Verify these details from the command output:

  • Local node and peer node details such as IP address and ID.

  • The field Encrypted: YES indicates that the traffic is protected.

  • The field Deployment Type: SWITCHING indicates a default gateway (switching) mode configuration—that is, the network has switches connected at both ends (Layer 2 network).

  • The field Services Redundancy Group: 1 indicates the status of the SRG1 (ACTIVE or BACKUP) on that node.

Check Multinode High Availability Peer Node Status

Purpose

View and verify the peer node details.

Action

From operational mode, run the following command:

SRX-1

SRX-2

Meaning

Verify these details from the command output:

  • Peer node details such as interface used, IP address, and ID.

  • Encryption status, connection status, and cold synchronization status

  • Packet statistics across the node.

Check Multinode High Availability Service Redundancy Groups

Purpose

Verify that the SRGs are configured and working correctly.

Action

From operational mode, run the following command:

For SRG0:

For SRG1:

Meaning

Verify these details from the command output:

  • Peer node details such as deployment type, status, and active and back up signal routes.

  • Virtual IP Information such as IP address and virtual MAC address.

  • IP monitoring and BFD monitoring status.

Verify the Multinode High Availability Status Before and After Failover

Purpose

Check the change in node status before and after failover in a Multinode High Availability setup.

Action

To check the Multinode High Availability status on the backup node (SRX-2), run the following command from operational mode:

Under the Services Redundancy Group: 1 section, you can see the Status: BACKUP field. This field value indicates that the status of SRG 1 is backup.

Initiate the failover on the active node (SRX-1 device) and again run the command on the backup node (SRX-2).

Note that under the Services Redundancy Group: 1 section, the status of SRG1 has changed from BACKUP to ACTIVE.

You can also see peer node details under the Peer Information section. The output shows the status of peer as BACKUP.