# Srx Mnha > 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. - **Type:** Skill - **Install:** `agentstack add skill-fastrevmd-lab-fwskillsshare-srx-mnha` - **Verified:** Yes — security-reviewed for prompt injection and unsafe behavior - **Seller:** [fastrevmd-lab](https://agentstack.voostack.com/s/fastrevmd-lab) - **Installs:** 0 - **Category:** [AI & ML](https://agentstack.voostack.com/c/ai-and-ml) - **Latest version:** 0.1.0 - **License:** Apache-2.0 - **Upstream author:** [fastrevmd-lab](https://github.com/fastrevmd-lab) - **Source:** https://github.com/fastrevmd-lab/fwskillsshare/tree/main/skills/srx-mnha - **Website:** https://mechub.org ## Install ```sh agentstack add skill-fastrevmd-lab-fwskillsshare-srx-mnha ``` Requires the [AgentStack CLI](https://agentstack.voostack.com/docs/cli). Works with Claude Code, Cursor, and any MCP-compatible agent. ## About # 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: ```junos 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: ```text 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: ```junos 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: ```junos 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: ```junos 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: ```text 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](https://github.com/fastrevmd-lab) - **Source:** [fastrevmd-lab/fwskillsshare](https://github.com/fastrevmd-lab/fwskillsshare) - **License:** Apache-2.0 - **Homepage:** https://mechub.org Install and usage instructions live in the source repository linked above. ## Pricing - **Free** — Free ## Security capabilities Automated source analysis of v0.1.0 — what this tool can access: - **Network access:** no - **Filesystem access:** no - **Shell / process execution:** no - **Environment & secrets:** no - **Dynamic code execution:** no *"Yes" means the capability is present in the source — more access means more to trust, not that it is unsafe.* ## Versions - **0.1.0** — security scan: passed — Imported from the upstream source. ## Links - Listing page: https://agentstack.voostack.com/l/skill-fastrevmd-lab-fwskillsshare-srx-mnha - Seller: https://agentstack.voostack.com/s/fastrevmd-lab - Browse the marketplace: https://agentstack.voostack.com/browse --- Listed on AgentStack — the marketplace for AI agent skills and MCP servers. Every listing is security-reviewed. Creators keep 70%.