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

This topic describes how to configure Multinode High Availability in active/backup mode for a default gateway (Layer 2) deployment.

Overview

For the list of supported features across different platforms and software releases, see Feature Explorer.

In Multinode High Availability, participating Junos Firewalls 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 MNHA default gateway (L2) mode, both SRX Series Firewall nodes appear as a single gateway by sharing a virtual IP (VIP) and MAC address. Devices in the network use this VIP as their default gateway, so these devices don’t need to know which node is actually handling the traffic. Each group has one active node that forwards traffic and one backup node for failover, making it a simple and transparent next-hop design for the network.

Requirements

This example uses the following hardware and software components:

  • Two supported Junos firewalls or virtual Firewall Instances
  • Two Juniper Networks Switches at the other end
  • Junos OS Release 26.2R1

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

In this topology, clients in the LAN send traffic to the default gateway (the VIP). The switch forwards this traffic to both SRX Series Firewall nodes, but only the active node for that SRG (for example, SRX‑01 in the diagram) owns the VIP and processes the packets. The active node performs security checks, creates sessions, and forwards the traffic toward the untrust side. At the same time, it synchronizes session information with the backup node over the ICL link so that the peer is always ready to take over.

If the active node or its path fails, the backup node quickly takes over the VIP and vMAC. Traffic from the LAN and untrust side is then redirected to the new active node without requiring any changes on the hosts. Because sessions were already synchronized, most flows continue with minimal disruption, providing seamless failover in the network.

This example uses direct connections between the SRX Series Firewalls and switches for simplicity; in particular, the inter‑chassis link (ICL) in the HA Link zone is established using the ge-0/0/2.0 interface directly between devices. However, in production deployments, these links can also traverse an intermediate routed network.

Table 1 shows the details on interfaces configuration used in this example.

Table 1: Interfaces and IP Address Configuration on Security Devices
Device Interface Zone IP Address Configured For
SRX-01 ge-0/0/2.0 halink 10.22.0.1/24 Interchassis -link (ICL)
ge-0/0/3.0 trust 10.1.0.1/24 Connects to Switch-01
ge-0/0/4.0 untrust 10.2.0.1/24 Connects to Switch-02
SRX-02 ge-0/0/2.0 halink 10.22.0.2/24 Interchassis -link (ICL)
ge-0/0/3.0 trust 10.1.0.2/24 Connects to Switch-01
ge-0/0/4.0 untrust 10.2.0.2/24 Connects to Switch-02

You'll perform the following tasks to build an MNHA setup:

  • Configure a pair of firewalls as local and peer nodes by assigning IDs.
  • Configure services redundancy groups (SRGs).
  • Configure virtual IP addresses for activeness determination and enforcement. In this example, a single virtual IP is configured with both IPv4 and IPv6 addresses using multiple ip statements to enable dual-stack support.
  • Configure a VPN profile for the high availability (ICL) traffic using IKEv2.
  • Configure appropriate security policies to manage traffic in your network.
  • 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.

Configuration

Before You Begin

Junos IKE package is required on your firewalls for MNHA configuration. This package is available as a default package or as an optional package on firewalls. See Support for Junos IKE Package for details.

If the package is not installed by default on your device, use the following command to install it. 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. Next, 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-01

On SRX-02

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

On Switch -01

On Switch -02

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 the physical interfaces with appropriate descriptions and IP addresses.

    • SRX-01

    • SRX-02
  2. Configure the security policy. SRX-01 and SRX-02
    CAUTION:
    The security policy shown in this example is only for demonstration and testing. You should configure security policies as per your network needs. Ensure that your security policies allow only the applications, users, and devices that you trust.
  3. Configure security zones, assign interfaces to the zones, and specify the allowed system services for the security zones.

    • SRX-01
    • SRX-02

      For an MNHA setup, this configuration typically includes allowing IKE, BGP, and BFD. Always tailor the security rules to align with your network and security requirements.

  4. Configure Chassis High Availability Identity. Establish the local device identity and peer relationship.

    • SRX-01
    • SRX-02

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

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

    • SRX-01
    • SRX-02

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

  6. Configure liveness detection parameters.

    • SRX-01
    • SRX-02
  7. Create the SRG with deployment type and peer association.

    • SRX-01
    • SRX-02
  8. Set up virtual IP addresses and interface for seamless failover.
    • SRX-01
    • SRX-02
      Note: Configuring the use-virtual-mac option is the recommended option in most cases, except where the surrounding infrastructure would not support a moving virtual MAC address active on a port in addition to the local MAC address.
  9. Enable monitoring of critical interfaces for automatic failover:

    • SRX-01
    • SRX-02
  10. Encrypt the ICL by configuring an IKEv2-based VPN profile, and define the required IKE and IPsec parameters.

    SRX-01 and SRX-02

    For the MNHA feature, you must configure the IKE version as v2-only and specify the ha-link-encryption option to encrypt the ICL to secure high availability traffic flow between the nodes.

Results (SRX-01)

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-02)

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

Use the show commands to confirm that the configuration is working properly.

Check MNHA Details

Purpose

View and verify the details of the MNHA setup configured on your security device.

Action

From operational mode, run the following command:

SRX-01

SRX-02

Meaning

Verify these details from the command output:

  • HA link to peer (10.22.0.1 or 10.22.0.2 over ge-0/0/2.0) is established (Conn State UP).

  • 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 shows Status: ACTIVE or Status: BACKUP to display current status of SRG.

Check Multinode High Availability Peer Node Status

Purpose

View and verify the peer node details.

Action

From operational mode, run the following command:

SRX-01

SRX-02

Meaning

Verify these details from the command output:

  • The HA peer connection is established and healthy (Conn State UP, Encrypted YES).
  • Synchronization appears successful (Cold Sync Status COMPLETE).
  • No packet send/receive errors are reported, indicating clean HA control-plane communications.

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:

SRX-01

SRX-02

Meaning

Verify these details from the command output:

  1. Peer node details (deployment type, status, signal routes); peer is healthy and in ready backup state, indicating failover capability.
  2. Virtual IP information (IP and VMAC); VIPs are displayed as INSTALLED on the active node and monitored interfaces are Up.
  3. VMAC (for example, 00:10:db:fe:01:02) associated with the virtual IP.
  4. Backup node VIP status, where VIPs are showing NOT INSTALLED.
  5. Dual-stack support, with both IPv4 and IPv6 VIPs present.
  6. SRG status, where SRG 1 is active and in READY control-plane state with no failures.

Verify IP Address Installation on Interfaces

Purpose

Verify that the virtual IP addresses are installed on the interfaces.

Action

From operational mode, run the following command:

SRX-01

SRX-02

For brevity, the show command output is truncated to display only a few samples.

Meaning

The command output provides the following information:

  • On the active node, the interface shows both dual-stack virtual IPs 10.1.0.200/16 and 22001:db8:6700::3/64 are installed on interface ge-0/0/3.0 for VIP index 1 and 10.2.0.200/16 and 2001:db8:6701::7/64 are installed on interface ge-0/0/4.0 for VIP index 2.
  • On the backup node, only the local interface IP addresses are present, and the VIP is not installed.

This output ensures that only the active node handles traffic. During a failover, the VIP moves from the active node to the backup node, maintaining service continuity for both IPv4 and IPv6 traffic