Design, configure, audit, and troubleshoot Juniper SRX Multi-Node High Availability. Use when handling routed, default-gateway, or hybrid modes, chassis-cluster migration, SRGs, ICL or ICD, session sync, BGP or BFD failover, VIPs, IPsec, NAT, proxy ARP, routing instances, or DHCP. Use focused SRX skills for non-MNHA behavior.
Installation
Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.
Design, configure, audit, and troubleshoot Juniper SRX Multi-Node High Availability. Use when handling routed, default-gateway, or hybrid modes, chassis-cluster migration, SRGs, ICL or ICD, session sync, BGP or BFD failover, VIPs, IPsec, NAT, proxy ARP, routing instances, or DHCP. Use focused SRX skills for non-MNHA behavior.
version
1.3.1
author
["fastrevmd-lab","Claude","GPT"]
license
MIT
metadata
{"hermes":{"tags":["srx","junos","mnha","high-availability","chassis-cluster","srg","icl","icd","bgp","bfd","ipsec","ike","nat","routing-instance","dhcp"],"related_skills":["parsing-srx-configs","srx-nat","srx-policy","srx-autovpn-full-tunnel","srx-ipsec-hub-spoke"]},"sources":[{"title":"DHCP on MNHA: Back to Basics","author":"James Rathbun","url":"https://community.juniper.net/blogs/james-rathbun/2026/04/22/dhcp-on-mnha-back-to-basics?CommunityKey=44efd17a-81a6-4306-b5f3-e5f82402d8d3","retrieved":"2026-05-14"},{"title":"Multi-Node High Availability Basics","author":"Steven Jacques","url":"https://community.juniper.net/blogs/steven-jacques/2024/12/20/multi-node-high-availability-basics?CommunityKey=44efd17a-81a6-4306-b5f3-e5f82402d8d3","retrieved":"2026-05-14"},{"title":"Hybrid MNHA with eBGP","author":"James Rathbun","url":"https://community.juniper.net/blogs/james-rathbun/2025/06/12/hybrid-mnha-with-ebgp?CommunityKey=44efd17a-81a6-4306-b5f3-e5f82402d8d3","retrieved":"2026-05-14"},{"title":"SRX clustering: from Chassis Cluster to MultiNode High Availability","author":"Laurent Paumelle","url":"https://community.juniper.net/blogs/laurentp/2026/02/15/srx-from-chassis-cluster-to-mnha","retrieved":"2026-05-14"},{"title":"MNHA, IPSec and Multiple Routing Instances","author":"James Rathbun","url":"https://community.juniper.net/blogs/james-rathbun/2026/03/30/mnha-ipsec-and-multiple-routing-instances?CommunityKey=44efd17a-81a6-4306-b5f3-e5f82402d8d3","retrieved":"2026-05-14"}]}
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):
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-monitorweights 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
show chassis high-availability services-redundancy-group <SRG>
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 <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 <X> src-ip <Y> 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 <LOCAL_ICL_IP>
set chassis high-availability peer-id <PEER_ID> peer-ip <PEER_ICL_IP>
set chassis high-availability peer-id <PEER_ID> interface <ICL_SOURCE_INTERFACE>
set chassis high-availability peer-id <PEER_ID> routing-instance <ICL_RI>
set chassis high-availability peer-id <PEER_ID> liveness-detection minimum-interval <MS>
set chassis high-availability peer-id <PEER_ID> liveness-detection multiplier <COUNT>
set chassis high-availability services-redundancy-group 0 peer-id <PEER_ID>
Security-zone example for an ICL interface:
set security zones security-zone ICL interfaces <ICL_INTERFACE>
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 <LOCAL_ICD_IP>
set chassis high-availability peer-id <PEER_ID> peer-forwarding-ip <PEER_ICD_IP>
set chassis high-availability peer-id <PEER_ID> peer-forwarding-ip interface <ICD_INTERFACE.UNIT>
set chassis high-availability peer-id <PEER_ID> peer-forwarding-ip liveness-detection minimum-interval <MS>
set chassis high-availability peer-id <PEER_ID> peer-forwarding-ip liveness-detection multiplier <COUNT>
ICD verification:
show chassis high-availability data-plane statistics
show security flow session source-prefix <SRC> destination-prefix <DST> 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, and test takeover through the intended forwarding path before declaring stateful failover ready.
Configuration Synchronization
Read the configuration synchronization section of references/mnha-advanced-workflows.md. Keep node-local interfaces and routing intentionally distinct while maintaining equivalent security policy, objects, NAT logic, profiles, and shared SRG behavior. Use the peer-sync pattern in references/mnha-config-patterns.md; never store real secrets in skill files, tickets, or chat.
Hybrid MNHA with eBGP Pattern
Read the hybrid-routing section of references/mnha-advanced-workflows.md before coupling SRG state to route preference. Validate signal-route tables, route filters, metrics, BFD behavior, VIP ownership, ARP refresh, and both failover and failback convergence. Use the complete route-filtered examples in references/mnha-config-patterns.md.
DHCP on MNHA
Read the DHCP section of references/mnha-advanced-workflows.md. Prefer relay to an external service; if local DHCP is required, use non-overlapping pools and node-local server identifiers because lease databases are not assumed to synchronize. Complete patterns are in references/mnha-config-patterns.md.
Verification Checklist
Before production cutover:
Platform and Junos release support verified in current Juniper docs.
Deployment mode selected: routed, default-gateway, or hybrid.
SRG usage documented: SRG0 only, SRG1+, or multiple SRGs.
ICL reachability verified in the intended routing instance.
ICL zone host-inbound services are restricted but sufficient.
If ICL encryption is required, IKED/IPsec HA link encryption is validated before cutover.
Shared security policy, NAT, application, and profile config are equivalent where stateful failover is expected.
Node-specific routing/interface configuration is intentionally different and documented.
Forwarding interface/logical-unit design is compatible with stateful failover expectations.
Symmetric routing is preferred or ICD/asymmetric-flow design is explicitly validated.
If advanced inspection services are in policy, steady-state cross-node/Z-mode forwarding has been eliminated or explicitly validated against Juniper support guidance.
IPsec on MNHA uses SRG1+, has managed-services ipsec, and IKED/package requirements are verified for the Junos release.
VPN floating loopbacks, ICL context, physical underlay interfaces, security zones, and routing instances align; IKE gateway lookup has been tested from both nodes.
Intra-zone IKE/ESP policy exists when VPN traffic is received on a physical interface and terminates on a loopback in the same zone.
Remote-access pools are common per SRG or split per active/active SRG design to prevent address collisions after failover.
NAT/SNAT pools, route advertisements, and upstream next hops produce deterministic return paths; proxy ARP is avoided unless explicitly tested.
Sessions show Active/Warm state across both nodes.
BGP/OSPF/static route preference selects the intended node.
BFD sessions are stable and timers are realistic for the platform.
Failover tests cover single-link, dual-link, node reboot, ICL loss, and failback/preemption if used.
DHCP uses relay when possible; if local DHCP is used, pools are split and non-overlapping.
Troubleshooting Commands
MNHA state:
show chassis high-availability information
show chassis high-availability services-redundancy-group 0
show chassis high-availability services-redundancy-group <SRG>
show configuration chassis high-availability | display set
ICL and HA liveness:
show route <PEER_ICL_IP>
ping routing-instance <ICL_RI> <PEER_ICL_IP>
show security ipsec security-associations # only when ICL encryption is enabled
show security ike security-associations # only when ICL encryption is enabled
Session, IPsec, routing, VIP, and DHCP checks are listed inline in their sections above.
Common Pitfalls
Treating MNHA like chassis cluster. MNHA nodes are independent devices with synchronized runtime state, not one logical chassis.
Forgetting configuration synchronization. Security policy and NAT differences can break stateful failover even when sessions synchronize.
Building routed MNHA but allowing asymmetric flows accidentally. Prefer symmetry; use ICD only when planned and tested.
Using broad lab security settings in production. Avoid default-policy permit-all, host-inbound all, or broad direct-route export unless explicitly intended.
Exporting too many routes from signal-route policy. Put route filters on every accept term.
Using production prefixes as signal routes. Use reserved, non-routed, non-conflicting prefixes.
Assuming BFD timers from a lab are safe everywhere. Tune timers per hardware, topology, and operational tolerance.
Enabling preemption without testing routing readiness. Failback can blackhole traffic if SRG ownership returns before BGP/forwarding is converged.
Assuming DHCP state is shared. For local DHCP, split pools and use node-specific server identifiers; prefer relay when possible.
Ignoring ICL security and reachability. If ICL fails, sync fails; if ICL is exposed, HA state can become a security risk.
Anchoring MNHA IPsec on a floating loopback in a different routing instance from the ICL/MNHA context. IKE gateway lookup is control-plane/self-traffic behavior; route leaking that fixes transit traffic may not fix IKE.
Putting the VPN loopback and receiving physical interface in different security zones. The tunnel can fail with reroute errors even when basic IP reachability exists.
Assuming process-packet-on-backup or ICD makes all asymmetric designs safe. Advanced inspection services need bidirectional visibility; sustained cross-node flows should be engineered out of steady state.
Using proxy ARP for NAT pool reachability as if MNHA were chassis cluster. Both independent nodes can answer ARP, and return traffic can land on the wrong node.
Reusing the same remote-access address pool across independently active SRGs without splitting ranges. Failover may preserve a pool, but active/active SRGs can collide.
Forgetting to dissolve groups node0 / groups node1. On a chassis cluster those per-node groups carried node-specific config; on MNHA each node is a standalone device, so that config must become direct system/interface configuration on the respective node. Leaving it as apply-groups node0/node1 (which has no cluster context to key on) drops the settings.
Forgetting that management/enrollment identity is per-node. outbound-ssh, EMS, and Security Director Cloud device-id are node-local: after migration each SRX re-enrolls as a separate managed device. Plan the re-enrollment and update inventory/licensing per node rather than expecting the cluster's single managed-device identity to carry over.
Leaving a stray static default route via an unzoned management/extra leg — black-holes transit return traffic. See Field-Confirmed Behaviors below.
Using the flat local-id local-ip / peer-id peer-ip config on Junos 26.x. It commits but never activates (mode not configured); 26.x needs the grid model plus a reboot. See "Config model: flat vs grid".
Omitting activeness-probe dest-ip <X> src-ip <Y> on an SRG with deployment-type routing — commit fails activeness-probe … mandatory. src-ip is a sub-field of dest-ip, one statement.
A signal-route export policy that re-advertises only learned routes and forgets the node's own connected transit subnets — the far side can't route back to on-transit sources (SNAT addresses, downstream transit IPs) and return traffic black-holes. Add a from protocol direct … route-filter <transit> exact accept term.
Assuming a configured SRG1 always elects a single active. If cold-sync doesn't converge, both nodes self-elect ACTIVE (active/active); routing failover still works but stateful sync does not. Check Conn State/Cold Sync Status, not just Node Status.
Leaving fxp0 on DHCP on a node whose failover depends on a BGP-learned default — the DHCP default (Access-internal, pref 12) beats BGP (170) and black-holes transit. Make fxp0 static.
Field-Confirmed Behaviors
Full write-ups live in references/mnha-grid-model-field-notes.md; the pitfalls
above index them. Confirmed on live pairs:
vSRX3 24.4R1.9 hybrid pair (issue #7):
an unzoned-leg static default black-holes transit (pitfall 18); the backup node
does not service SRG data traffic (Process Packet In Backup State: NO is
expected, not a fault); the high-availability host-inbound knob commit-checks
clean.
vSRX 26.2R1.7 routed pairs (grid model, eBGP + signal-route MED steering):
grid model + reboot required on 26.x (pitfall 19); failed cold-sync leaves both
nodes self-elected ACTIVE — routing failover survives, stateful sync does not
(pitfall 22); signal-route export must include connected transit subnets
(pitfall 21); active/active SNAT wants per-node pools + proxy-ARP addresses;
fxp0 on DHCP black-holes transit (pitfall 23); on KVM/Proxmox a soft reboot
can leave the vSRX dataplane un-enumerated and chassis-cluster mode never forms
its control link — MNHA was the only workable HA model there.
Source Notes
This original operational playbook was informed by five attributed Juniper
Community TechPosts by James Rathbun, Steven Jacques, and Laurent Paumelle.
Concise Inspired by notes under references/ preserve source links,
release-specific cautions, and verification implications without reproducing
the articles.
Sections on chassis-cluster interface migration, SRG monitor-object syntax, and pitfalls 16-23 are field/QA additions beyond the five source articles; live-verified items are called out in Field-Confirmed Behaviors. The "Config model: flat vs grid" section, the routed-mode single-gateway caveat, and the vSRX-26.2 behaviors come from a 2026-07 deployment of two routed MNHA pairs on vSRX 26.2R1.7 (grid model, SRG1 deployment-type routing, eBGP + signal-route MED steering); the grid syntax is release-dependent, so verify against the target release.
Per user instruction, ambiguous or conflicting article details were not encoded as hard guidance. Where support depends on platform or Junos release, this skill points operators to current Juniper documentation instead of freezing a source-specific matrix.
