IP Addressing and Network Preparation for Multinode High Availability

Device Model

In Multinode High Availability, you must use the same SRX Series Firewall model as your nodes. For example, if you use the SRX5600 as one node, you must use another SRX5600 as the other node

In case of the SRX5000 line of devices, ensure that SPCs, NPCs, and IOCs have the same slot placement and type.

Software Version

Install the compatible version of Junos OS on the participating security devices.

Software Licenses

You do not need any specific license for the Multinode High Availability feature. However, licenses are unique to each SRX Series and cannot be shared between the nodes in a Multinode High Availability setup. Therefore, you must use identical licenses on both the nodes. If both SRX Series Firewalls do not have an identical set of licenses, the system is not ready for the deployment.

Network Accessibility

Both the nodes in the Multinode High Availability setup must be able to reach each other using the ICL path. This path uses (whether the ICL is encrypted or not) IP address, protocol, and port details. You must ensure that this communication is allowed between the nodes if any firewall or other inspection is in place.

The floating IP address that you use for each node must be routable IP (logical routed path) across the network.

We recommend to bind the ICL to the loopback interface (lo0) or an aggregated Ethernet interface (ae0) and have more than one physical link (LAG/LACP) that ensure path diversity for highest resiliency. You can also use a revenue Ethernet port on the SRX Series Firewalls to setup an ICL connection. Ensure that you separate the transit traffic in revenue interfaces from the high availability (HA) traffic.

Using IP Address Pools in Multinode High Availability Configuration

When you configure multiple SRGs (active/active mode) in Multinode High Availability, ensure that address pools used by SRGs in an access profile must not overlap. Also ensure that address and address pool configured in the RADIUS server for the hosts connected to different SRGs must be unique.

Example: Following sample shows address pool configurations with access profile localpool and localpool2 for SRG1 and SRG2 respectively:

In this example, Services Redundancy Groups - SRG1 and SRG2 - are in the same network (192.0.2.0/24). However, IP addresses in address pools are distributed to avoid overlapping (192.0.2.1/24—192.0.2.127 for SRG1 and 192.0.2.128—192.0.2.255 for SRG2).

Similarly you must use unique IP address and address pools for user configurations in the RADIUS server.

In case you assign same address for hosts in two SRGs, then Multinode High Availability deletes the new host and halts IKE negotiations with the following message:

System Log displays the following message:

IPv4 and IPv6 Address Consideration

Table 1 provides details on IPv4 and IPv6 address support for Multinode High Availability deployments.

Support available for the configuration of IPv6 addresses for the active signal route, backup signal route, and install on failure route options under services-redundancy-group configurations on your MNHA setup.

Dual-Stack Virtual IP Addresses in Multinode High Availability

MNHA supports dual‑stack (IPv4 and IPv6) virtual IP support for the default gateway mode and hybrid mode deployments. In these deployments, you can assign both an IPv4 address and an IPv6 address to the same virtual IP under [edit chassis high-availability services-redundancy-group] hierarchy. With dual-stack support, you can configure one IPv4 address and one IPv6 address on the same virtual IP by adding multiple ip statements. If you configure only one address family, service redundancy group behavior (SRG) remains same as in single-stack deployments.

The SRG manages installation state and failover for both address families as a single virtual IP entry. This approach keeps default gateway behavior consistent on dual-stack interfaces without requiring separate virtual IP indexes for IPv4 and IPv6.

If split-brain prevention probing is configured for an SRG with dual-stack virtual IP addresses, the system probes each configured address and evaluates the results together. If either the IPv4 or IPv6 virtual IP address responds, the probe is considered successful. This behavior helps prevent incorrect role decisions when only one address family is affected.

This support improves MNHA adoption in dual‑stack environments and enables the system to manage and fail over IPv4 and IPv6 virtual IP addresses to maintain traffic continuity and high availability.

To configure dual-stack virtual IP addresses, add one IPv4 prefix and one IPv6 prefix under the same SRG ID and virtual IP index as shown in the following sample:

To verify that the SRG tracks both addresses on the same index, use:

show chassis high-availability services-redundancy-group 1

show chassis high-availability information detail

• Verify IPv4 and IPv6 Virtual IP (VIP) Installation
• Check Installation of Virtual IPs on Interfaces

In the above sample, on the active node, the interface shows both dual-stack virtual IPs 10.1.0.200/16 and 2001: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 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.

For complete configuration, see Example: Configure Multinode High Availability in a Default Gateway Deployment.

Scaling Virtual IP Support in MNHA

You can increase the number of virtual IP (VIP) addresses per Services Redundancy Group (SRG) up to 2000 in Multinode High Availability (MNHA) switching (default gateway) mode and on the L2 side of Hybrid mode.

In earlier implementations, the virtual MAC address (VMAC) was derived using the SRG identifier and VIP index. As a result, each VIP required a unique VMAC, limiting the number of VIPs to approximately 32 per SRG.

With this enhancement, VMAC is generated using a combination of the following parameters:

• Grid identifier (grid-id)
• Services redundancy group identifier (SRG-ID)
• Virtual MAC identifier (virtual-mac-id)

This decouples VMAC assignment from the VIP index, allowing multiple VIPs to share the same VMAC and significantly increasing the supported scale

Grid-ID (Configured at the chassis level)

Virtual MAC ID (Configured per interface within an SRG)

This configuration must be consistent for the same interface across SRGs.

This enhancement enables the following:

• Up to ~2000 VIPs per SRG
• Up to 16 interfaces per SRG. This 16 interface limit applies at the physical interface (IFD) level. A single physical interface (or AE bundle) can host multiple logical subinterfaces and VIPs. Using all 16 interfaces is not required; fewer, including a single interface with multiple subinterfaces, may be used
• A physical or aggregated Ethernet interface can be configured in multiple SRGs
• Up to 15 MNHA pairs can coexist within a single Layer 2 broadcast domain. That is, upto 15 MNHA pairs with unique grid-id for each pair can be connected to the same L2 switch and the grid-id will differentiate with unique vMAC though same SRG id and interface id used.

Backward Compatibility - If the grid-id is not configured, the system continues to use the legacy VMAC generation method based on SRG-ID and VIP index. In this case, the VIP scale remains limited to approximately 32 per SRG.