Srx Mnha

SRX Multi-Node High Availability (MNHA)

Overview

Multi-Node High Availability (MNHA) is Juniper SRX high availability built around independent SRX nodes that synchronize runtime state over routed HA links. Unlike chassis cluster, MNHA nodes do not become a single logical chassis. Each node keeps its own control plane, hostname, management, routing protocols, interface addressing, and node-specific configuration. Stateful firewall/NAT/IPsec runtime objects can still synchronize so traffic can survive a path or node failover when the design keeps routing, interfaces, policy, and HA state aligned.

Use MNHA as an L3-first HA design. Routing policy, BFD, link monitoring, service redundancy groups, and optional VIP behavior determine which node handles traffic. Avoid treating MNHA as a drop-in chassis-cluster clone; it solves different problems and has different failure modes.

Scope and routing

Use this skill only for MNHA-specific design and behavior. Use parsing-srx-configs for full-config extraction, srx-nat for general NAT, and srx-policy for general policy design.

Chassis Cluster vs MNHA

Chassis cluster is the traditional SRX L2 HA model:

• two nodes form one logical chassis
• active/backup control plane behavior
• shared cluster configuration
• reth interfaces with virtual IP/MAC behavior
• redundancy group ownership changes during failover
• nodes usually need the same L2 domains for clustered interfaces
• failover may depend on gratuitous ARP and L2 convergence

MNHA is different:

• nodes remain independent SRX devices
• each node has its own routing process and control plane
• both nodes can maintain routing adjacencies at the same time
• forwarding preference is normally driven by routing policy, BFD, and SRG state
• state synchronization is separate from full configuration synchronization
• ICL/ICD are logical routed links, not chassis-cluster HA/fabric ports
• designs can be routed, default-gateway/L2-like, or hybrid

Key design translation:

| Chassis cluster habit | MNHA interpretation | |---|---| | One shared config | Independent configs; synchronize only what should match | | Reth/VIP everywhere | Use routed node IPs where possible; use VIPs only when the design requires them | | RG master owns traffic | Routing and SRG state influence traffic path | | Active/passive control plane | Independent active control planes | | Dedicated HA/fabric assumptions | Routed ICL/ICD paths with security/routing/MTU planning |

Always verify platform and Junos support in Juniper Pathfinder / Feature Explorer and current Juniper documentation before deployment. MNHA feature support, scale, asymmetric-flow support, multi-node support, and platform support are release-dependent.

Chassis-Cluster to MNHA Interface Migration

Read references/mnha-advanced-workflows.md before converting chassis-cluster reth members. The migration requires a per-node decision between local physical interfaces and a local ae; cluster LACP does not prove the upstream is a valid standalone-node LAG.

Deployment Modes

Routed / L3 MNHA

Routed MNHA is the cleanest MNHA model.

Characteristics:

• no interface VIP required for normal forwarding
• each node has unique interface IP addresses
• each node peers with upstream/downstream routers independently
• BGP, OSPF, static metrics, or policy decide preferred paths
• SRG0 is commonly involved for default active/active service behavior
• symmetry is strongly preferred for stateful inspection

Use routed MNHA when:

• the network can route to either SRX node
• you want fast failover with routing/BFD
• geo-redundancy or L3 separation matters
• you want to avoid L2 stretch and virtual MAC dependencies

Failover only covers the routed sides. Each node has its own interface IP on every segment, so a directly-attached host that uses one node's IP as its static default gateway does not fail over — kill that node and the host is stranded (no floating gateway on that segment). Routed failover works only where a router (BGP/OSPF/BFD) re-converges to the survivor. An L2 segment of plain hosts that must survive a node loss needs default-gateway mode (VIP) or upstream ECMP — decide per segment (common to have the core-facing side routed while a client/DMZ side needs a VIP). Field-confirmed 2026-07: an internet-facing host with a static gateway of the active node's IP lost all connectivity on failover while the BGP-driven core-facing side reconverged cleanly.

Default-Gateway MNHA

Default-gateway mode provides L2-like gateway behavior with VIP/vMAC semantics.

Characteristics:

• a VIP is installed on the active node for an SRG
• clients use the VIP as their default gateway
• backup node does not install that VIP
• failover moves the VIP and sends ARP/GARP behavior to update the L2 domain
• requires shared L2 where the VIP is used

Use default-gateway mode when:

• hosts cannot be changed away from a shared default gateway address
• migrating from chassis cluster and preserving gateway addressing is important
• L2 gateway semantics are required on one or more segments

L2-adjacency caveats for deployment-type switching / default-gateway mode:

• The VIP rides on the aeN.unit (or physical unit) directly — no IRB/bridge-domain is introduced. The gateway is an interface VIP, not a routed SVI.
• The gateway vMAC moves on failover. Adjacent switches must accept that MAC move: check MAC-move limits, Dynamic ARP Inspection (DAI), storm-control, and EVPN/MLAG duplicate-MAC protection — any of these can suppress or block the moved vMAC and silently break failover even though the SRG shows ACTIVE.
• Use an SRG monitor-object to tie the segment's uplink to failover (interface

monitoring hangs off a named monitor-object with weights and thresholds, not a bare monitor interface knob): ``junos set chassis high-availability services-redundancy-group monitor monitor-object interface interface-name weight 100 set chassis high-availability services-redundancy-group monitor monitor-object interface threshold 100 set chassis high-availability services-redundancy-group monitor monitor-object object-threshold 100 set chassis high-availability services-redundancy-group monitor srg-threshold 100 ` interface-name takes the physical IFD (e.g. ge-0/0/2). Failover fires when accumulated weight reaches the interface threshold, the object threshold, and the SRG threshold — size weights accordingly (see references/source-hybrid-mnha-with-ebgp.md` for a weighted BFD + interface example).

• Chassis-cluster interface-monitor weights do not map 1:1 to SRG monitoring. Do not port cluster monitor weights directly; redesign monitoring around SRG active/backup semantics and test failover explicitly.

Hybrid MNHA

Hybrid mode combines routed and default-gateway behavior.

Common pattern:

• one side uses VIP/default-gateway behavior for an attached L2 segment
• the other side uses routed eBGP/OSPF/static paths
• SRG1+ controls active/backup service ownership for VIPs and route signaling
• BFD and interface monitoring can drive failover decisions

Use hybrid MNHA when:

• internal clients need a shared gateway VIP
• external/upstream connectivity is routed and redundant
• branch, campus, or mixed L2/L3 migration designs require both models

Services Redundancy Groups

Juniper articles refer to Services Redundancy Groups, abbreviated SRGs. Use the Junos hierarchy under chassis high-availability services-redundancy-group.

SRG0

SRG0 is the default forwarding group for routed MNHA behavior.

Operational model:

• no active/backup ownership model like a VIP group
• both nodes can be ready to forward
• no VIP/vMAC ownership is normally involved
• routing determines which node sees traffic
• runtime state can synchronize over ICL

If ICL is lost, state synchronization is affected. Routing may still deliver packets to either node, but stateful continuity is at risk until synchronization is restored.

SRG1 and Higher

SRG1+ provides active/backup service behavior.

Use SRG1+ for:

• default gateway VIPs
• hybrid mode VIPs
• route signaling based on active/backup status
• interface/BFD/object monitoring tied to failover
• IPsec termination designs that require synchronized tunnel/SAs, where supported
• active/active distribution by using different SRGs active on different nodes

Common SRG1+ attributes:

set chassis high-availability services-redundancy-group  deployment-type 
# deployment-type: routed/L3 = routing; hybrid = hybrid; default-gateway/L2 = switching
set chassis high-availability services-redundancy-group  peer-id 
set chassis high-availability services-redundancy-group  activeness-priority 

Verify:

show chassis high-availability services-redundancy-group 

Look for:

• deployment type
• ACTIVE or BACKUP status
• activeness priority
• preemption state
• peer status
• health status
• failover readiness
• VIP status when configured

Config model: flat (≤24.x) vs grid (26.x) — RELEASE-DEPENDENT

The chassis high-availability syntax changed by release. The flat local-id local-ip / peer-id peer-ip form used elsewhere in this skill and in the ≤24.x sources is rejected on Junos 26.x, which needs the grid model (grid-id, local-domain-id, peer-domain-id … peer-id). Symptom of the wrong model: commit fails, or show chassis high-availability information returns mode not configured even though your config is present. Confirm the model for the target release before writing config.

The complete grid-model configuration, field-confirmed on vSRX 26.2R1.7 (routed pair, SRG1 deployment-type routing, with the Node B mirror pattern), is in references/mnha-grid-model-field-notes.md. Two commit-blocking rules:

• **activeness-probe dest-ip src-ip is mandatory for `deployment-type

routing** (commit fails otherwise). src-ip is a **sub-field of dest-ip`** — one statement. Aim it at a real reachable data-segment address, not the ICL.

• Enabling chassis-HA needs a reboot to activate (says mode not configured

until then); a node may take two reboot cycles to reach Node Status: ONLINE.

ICL: Inter-Chassis Link

The ICL is the MNHA cluster communication and state-synchronization path. It is logical and routed; it does not require the physical HA/fabric ports used by chassis cluster.

ICL carries or supports:

• liveness / cluster communication
• cold sync after reconnect
• runtime object synchronization
• firewall session sync
• NAT state sync
• IPsec state sync where applicable
• HA-related control exchange

Design guidance:

• source ICL from stable loopback or dedicated interface addresses
• place ICL in a dedicated routing instance when practical
• when using MNHA IPsec with floating loopback tunnel anchors, the ICL routing instance and the floating loopback/external-interface routing instance must align; route leaking is not a safe substitute for IKE gateway lookup
• allow HA-related host-inbound services on the ICL zone
• if encrypting ICL, allow IKE and use the Junos HA link encryption model
• keep ICL RTT under the platform/release requirement for geo designs; the supplied sources use less than 100 ms as the design bound
• use redundant paths where possible
• do not assume ICL must be back-to-back; it can traverse routed infrastructure
• size the encrypted ICL for RTO/session-sync bursts, not just steady state; James Rathbun's field rule of thumb is roughly 1 Gbps per 100,000 concurrent sessions and keeping utilization below about 75% for resync and connection-per-second bursts

Minimal conceptual stanza:

set chassis high-availability local-id local-ip 
set chassis high-availability peer-id  peer-ip 
set chassis high-availability peer-id  interface 
set chassis high-availability peer-id  routing-instance 
set chassis high-availability peer-id  liveness-detection minimum-interval 
set chassis high-availability peer-id  liveness-detection multiplier 
set chassis high-availability services-redundancy-group 0 peer-id 

Security-zone example for an ICL interface:

set security zones security-zone ICL interfaces 
set security zones security-zone ICL host-inbound-traffic system-services high-availability
set security zones security-zone ICL host-inbound-traffic system-services ssh
set security zones security-zone ICL host-inbound-traffic protocols all

For production, restrict host-inbound services and protocols to the exact required set. Do not copy broad lab all permissions without review.

ICD: Inter-Chassis Datalink

ICD is an optional datapath used when asymmetric routing can deliver packets for one flow to different SRX nodes.

Use ICD when:

• ECMP or routed topology can produce asymmetry
• hybrid designs may send one direction to one node and return traffic to the other
• L7 inspection needs one node to see enough packets to classify or inspect a flow
• you cannot guarantee symmetric routing during normal or failure states
• multiple SRGs can be active on different nodes and create sustained cross-node, Z-mode-like forwarding

Design notes:

• prefer symmetric routing first
• use ICD deliberately when asymmetry is part of the design
• account for encapsulation overhead and MTU
• validate platform/release support for asymmetric flow and ICD behavior
• test with real application traffic, not only ping
• ICD may be used during the initial TCP 3-way handshake and while advanced inspection services need bidirectional visibility; do not assume every packet of every asymmetric flow will traverse ICD forever
• sustained cross-node flows with advanced inspection/plugin services are not a good steady-state design; engineer traffic so complete bidirectional flows normally land on one active node
• if ICD is down, asymmetric SYN/SYN-ACK or return traffic can fail even while synchronized sessions appear valid; check show chassis high-availability data-plane statistics and packet drops

ICD configuration pattern:

set chassis high-availability local-id local-forwarding-ip 
set chassis high-availability peer-id  peer-forwarding-ip 
set chassis high-availability peer-id  peer-forwarding-ip interface 
set chassis high-availability peer-id  peer-forwarding-ip liveness-detection minimum-interval 
set chassis high-availability peer-id  peer-forwarding-ip liveness-detection multiplier 

ICD verification:

show chassis high-availability data-plane statistics
show security flow session source-prefix  destination-prefix  pretty
show log messages | match "MNHA forward|re-route failed|reject NH|ICD"

(these strings come from flow traceoptions output — they appear in the configured security flow trace file, not the default messages log, unless traceoptions target messages)

Look for ICD Data counters when traffic is actually crossing the ICD. A valid Active/Warm session with packet counters split across nodes does not by itself prove the ICD is forwarding every packet.

IPsec VPNs on MNHA with Multiple Routing Instances

Read the IPsec section of references/mnha-advanced-workflows.md before configuring synchronized VPNs. SRG1+, the floating loopback, physical underlay, security zone, routing instance, ICL context, and route advertisement must align; route leaking alone may not fix control-plane IKE gateway lookup.

NAT, Proxy ARP, and Deterministic Routing

Read the NAT section of references/mnha-advanced-workflows.md before using translated addresses in an MNHA design. Keep policy and pools equivalent for stateful failover, prefer routed reachability over proxy ARP, and verify that egress selection and return routing remain deterministic on both nodes.

Runtime Object and Session Synchronization

Read the runtime synchronization section of references/mnha-advanced-workflows.md. Confirm that important sessions appear as Active/Warm across the peers, a

…

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: fastrevmd-lab
• Source: fastrevmd-lab/fwskillsshare
• License: Apache-2.0
• Homepage: https://mechub.org

Install and usage instructions live in the source repository linked above.