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 (MNHA) in active/backup mode for a default gateway (Layer 2) deployment. Organizations can maintain business continuity by automatically transferring active services and traffic steering capabilities to backup nodes without disrupting client communications.

Tip:
Table 1: Readability Score and Time Estimates

Readability Score

Flesch Reading Ease: 45-50 (College level)

Flesch-Kincaid Grade Level: 12-14

Reading Time

15-20 minutes (average reading speed)

Configuration Time

90-120 minutes (experienced engineer on testbed)

Example Prerequisites

Hardware requirements

SRX Series Firewalls and EX9214 Ethernet Switches

Software requirements

  • Junos OS Release 26.2R1
  • Configure firewall filtering and quality of service (QoS) as per your network requirements and have appropriate security policies to manage traffic in your network.

  • In a typical high-availability setup, you use multiple routers and switches on both the northbound and southbound sides. In this example, use two switches on each side of the firewalls. Configure all upstream and downstream routers according to your network requirements

  • Install the Junos IKE package on your security devices using the command request system software add optional://junos-ike.tgz. The junos-ike package is included in your Junos software packages (Junos OS Release 20.4R1 onwards).

Additional requirements

  • Console/SSH access to all devices

  • Management network connectivity

  • Valid licensing for advanced features

  • Backup of existing configurations recommended

Before You Begin

Benefits

  • Geographic Redundancy: Enables high availability across geographically dispersed locations.
  • Encrypted Interchassis Communication: Provides secure IPsec-encrypted logical interchassis link (ICL) for control plane synchronization over untrusted networks.
  • Flexible Traffic Steering: Provides greater network flexibility by supporting high availability across Layer 3 (L3) and switched network segments.

Know more

Multinode High Availability

Hands-on experience

Advanced Juniper Security On-Demand

Learn more

vLab Sandbox: Standalone vSRX

Functional Overview

Multinode High Availability Active/passive MNHA deployment configured in switching mode on both SRX-01 and SRX-02 firewalls. SRX-01 is configured as primary with activeness priority 200 and preemption enabled, while SRX-02 serves as backup with priority 1.
Interchassis Link (ICL) Encryption IPsec encryption profile named IPSEC_VPN_ICL is applied to the HA control link (ge-0/0/2) between two nodes.
Virtual IP Addresses (VIPs) Two virtual IP addresses configured for failover: 10.1.0.200/16 on trust zone interfaces (ge-0/0/3.0) and 10.2.0.200/16 on untrust zone interfaces (ge-0/0/4.0) on both firewalls, providing seamless failover without IP address changes.
Interface Monitoring Health monitoring configured on both SRX Series Firewalls for interfaces ge-0/0/3 (trust) and ge-0/0/4 (untrust) to trigger failover events when interface failures are detected.
Virtual MAC Addresses Virtual MAC addresses automatically assigned to trust and untrust interfaces on both SRX Series Firewalls to ensure consistent MAC addressing during HA failover events.
Primary Verification Tasks Verify MNHA status and synchronization between SRX-01 and SRX-02. Confirm active/backup roles with correct priority settings, and validate IPsec encryption on the ICL.

Topology Illustration

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

Topology Overview

Table 2: 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

Note:

For complete sample configurations on the DUT, see:

Step 1: Configure Physical Interfaces

Configure the physical interfaces that will participate in the high availability setup, including the HA link, trust zone interface, and untrust zone interface.

  • SRX-01

  • SRX-02

The interface configuration establishes three critical network segments for the MNHA. Interface ge-0/0/2 serves as the dedicated HA link. Interface ge-0/0/3 connects to the trust zone, handling internal network traffic. Interface ge-0/0/4 connects to the untrust zone, managing external network traffic.

Step 2: Configure Security Zones

Define security zones and assign interfaces to appropriate zones with required host-inbound traffic services and protocols.

  • SRX-01
  • SRX-02

Security zones segment network traffic and enforce security policies. The untrust and trust zones permit IKE, ping, SSH, and BGP/BFD services for connectivity, management, and routing, while the halink zone is dedicated to high availability.

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.

Step 3: Configure IKE Proposal for HA Link Encryption (SRX-01 and SRX-02)

Create the IKE Phase 1 proposal that defines cryptographic parameters for the encrypted HA link tunnel.

The IKE proposal defines secure HA link communication using preshared keys, DH Group 14, SHA-256, and AES-256-CBC, with a 1-hour lifetime. The settings must match on both MNHA nodes for successful IKE negotiation

Step 4: Configure IKE Policy and Gateway (SRX-01 and SRX-02)

Define the IKE policy that references the proposal and configure the IKE gateway for HA link encryption.

The IKE policy links the cryptographic proposal with authentication credentials, while the IKE gateway uses IKEv2-only for secure and efficient tunnel establishment. This gateway is later referenced by the IPsec VPN to protect HA synchronization traffic between MNHA members.

Step 5: Configure IPsec Proposal and Policy (SRX-01 and SRX-02)

Create the IPsec Phase 2 proposal and policy that define data plane encryption parameters for the HA link tunnel.

The IPsec proposal secures HA traffic using ESP and AES-256-GCM for efficient encryption and integrity protection. The IPsec policy encapsulates these settings and is referenced by the VPN configuration.

Step 6: Configure IPsec VPN for HA Link Encryption (SRX-01 and SRX-02)

Create the IPsec VPN profile specifically designated for high availability link encryption.

The IPsec VPN combines the IKE gateway and IPsec policy to create an encrypted HA tunnel. The ha-link-encryption option designates the VPN for secure HA communication.

Step 7: Configure Security Policy (SRX-01 and SRX-02)

Establish the default security policy for traffic processing through the firewall.

The default permit-all policy allows traffic between zones without requiring explicit security rules. It is useful for lab or initial deployments but should be replaced with restrictive policies in production environments.

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.

Step 8: Configure Chassis High Availability Local Identity

Define the local device's identity within the high availability setup.

  • SRX-01
  • SRX-02

The local ID and local IP uniquely identify this MNHA member. The local ID (1) distinguishes it from its peer, while the local IP (10.22.0.2) is used for HA communication.

Step 9: Configure Chassis High Availability Peer Identity

Define the peer device's identity and connectivity parameters within the HA.

  • SRX-01
  • SRX-02

The peer configuration identifies the remote HA member and enables secure HA communication over the dedicated HA link. 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. Liveness detection sends heartbeats every 200 ms and declares the peer down after three missed heartbeats, allowing fast failover detection.

Step 10: Configure Services Redundancy Group

Create and configure the services redundancy group that manages virtual IPs and failover behavior.

  • 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.
  • Services redundancy group enables active/passive failover in the high availability setup.
  • Switching mode is used for Layer 2 adjacent HA deployments.
  • Virtual IPs (VIPs) move between the HA members during failover.
  • Virtual MACs (VMACs) move with VIPs, preventing ARP issues and enabling seamless failover.
  • Interface monitoring tracks critical interfaces and triggers failover if they fail.
  • Preemption allows a higher-priority device to regain active status after recovery.
  • Activeness priority 200 ensures this device becomes the active node during MNHA startup and recovery.

Step 11: Commit Configuration

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

Table 3: Summary of Verification Commands Used
Command Verification Task
show chassis high-availability information

Validate overall High Availability (HA) status on the active and backup nodes, including whether HA is enabled, node roles, and core HA health indicators.

show chassis high-availability peer-info

Confirm the peer node is reachable.

show chassis high-availability services-redundancy-group

Verify redundancy group status, priorities, preempt behavior, and failover readiness.

show interface terse

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

show security ipsec security-associations ha-link-encryption detail

Confirm HA link encryption IPsec SAs are established (IKE/IPsec is up for the HA path).

Verify High Availability Formation and Peer Connectivity

Purpose

Validate that the MNHA s properly formed with both nodes online, peer discovery is successful, and the encrypted control channel between nodes is operational. This verification confirms the foundation for all HA operations, including state synchronization and failover capability.

Action

SRX-01

SRX-02

Meaning

  • Node Status: ONLINE confirms the local node is operational and participating in the HA setup.
  • Local-id: 1 and Peer Id: 2 validate unique node identification required for HA membership.
  • Conn State UP indicates HA link to peer (10.22.0.1 or 10.22.0.2 over ge-0/0/2.0) is established.

  • Encrypted: YES confirms IPsec encryption is protecting HA control traffic on interface.

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

  • Services Redundancy Group: 1 shows Status: ACTIVE or Status: BACKUP to display current status of SRG.

  • Cold Sync Status: COMPLETE verifies initial configuration synchronization has successfully finished, a prerequisite for SRG failover readiness.

Verify HA Peer Communication Details and Packet Exchange

Purpose

Confirm the internal secure tunnel parameters and validate bidirectional packet exchange between HA peers. This verification ensures the control plane communication infrastructure is healthy and capable of supporting state synchronization and failover messaging.

Action

SRX-01

SRX-02

Meaning

  • Conn State UP confirms that the HA peer connection is established and healthy.
    Note: The IP range (180.100.1.x) shown in the command output serves as the ICL IPsec traffic selector. The system dynamically assigns this IP range, and it is essential not to alter or modify it. Additionally, BFD (Bidirectional Forwarding Detection) will be automatically enabled for the broader 180.x.x.x IP range.
  • Internal Routing-instance: juniper_private1 is the system-generated VRF isolating HA control traffic from user data plane
  • Zero Send Error and Receive Error are reported, indicating clean HA control-plane communications.

Verify Services Redundancy Group Status and Role Assignment

Purpose

Validate SRG operational states, active/backup role assignment, and failover readiness across both HA nodes. This verification confirms proper resource ownership and ensures the HA can execute failover when required.

Action

SRX-01

SRX-02

Meaning

  • Status: ACTIVE on Node 1 and Status: BACKUP on Node 2 confirm proper role assignment for SRG 1. This indicates peer is healthy and in ready backup state, indicating failover capability.
  • Virtual IP Info: INSTALLED indicates VIPs are displayed on the active node. Where as on the backup node node, Virtual IP Info: NOT INSTALLED is displayed.
  • VMAC: 00:10:db:fe:01:02 and VMAC: 00:10:db:fe:01:01 are associated with the virtual IP on the active node.
  • Virtual IP Info: IP: 2001:db8:6701::7/64 and IP2: 10.2.0.200/24 confirms dual-stack support, with both IPv4 and IPv6 VIPs present.
  • Preemption: ENABLED on Node 1 means it will reclaim active status after recovery from failure
  • Preemption: DISABLED on Node 2 prevents unnecessary failovers when Node 1 returns online
  • Failure Events: NONE on both nodes confirms no monitoring failures (BFD, IP, Interface, Control Plane)
  • Health Status: HEALTHY and Failover Readiness: READY indicate the backup node can immediately assume active role if needed
  • System Integrity Check: COMPLETE on backup confirms configuration and state synchronization is current
  • Interface Monitoring Status: UP confirms the monitoring subsystem is actively tracking interface health
  • State: Up for both monitored interfaces means no link failures are detected that would trigger SRG failover

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

Verify IPsec Security Associations for HA Link Encryption

Purpose

Validate that IPsec tunnels protecting HA control traffic are established with correct encryption parameters and are actively processing traffic. This verification ensures confidentiality and integrity of configuration synchronization and state updates between HA nodes.

Action

Meaning

  • Local Gateway: 10.22.0.1 and Remote Gateway: 10.22.0.2 confirm tunnel endpoints match the HA peer addresses.
  • HA Link Encryption Mode: Inter-Chassis-Link confirms this is the dedicated HA encryption tunnel.
  • IPSEC_VPN_ICL Displays the name of IPsec VPN profile used.
    CAUTION:

    The IP range (180.100.1.x) shown in the command output serves as the ICL IPsec traffic selector. The system dynamically assigns this IP range, and it is essential not to alter or modify it. Additionally, BFD (Bidirectional Forwarding Detection) will be automatically enabled for the broader 180.x.x.x IP range.

Appendix 1: Set Commands on All Devices

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 might vary based on the 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

Appendix 2: Show Configuration Output

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.