Branch SRX Chassis Cluster Failover Drops Voice and SSH Sessions
Northwind Retail runs a two-node SRX345 chassis cluster at its headquarters, supporting 250 office users and two 300 Mbps ISP links. Both reth interfaces are in redundancy group 1, active on node 0. The trust-to-untrust policy applies IPS, antivirus, and web filtering. Session synchronization is enabled, and a recent health check shows both nodes healthy. During a planned failover to node 1, ICMP and new HTTPS sessions recover in about 8 seconds, but established SSH sessions and active SIP voice calls drop. The voice team insists the SRX is at fault because stateful failover should preserve everything. The network manager wants to repeat the failover at noon tomorrow to capture logs and asks whether the cluster can also run a Junos upgrade on node 0 at the same time to save a maintenance window. The cluster uses dedicated control and fabric links.
1. Explain why established SSH and SIP sessions can drop even though session synchronization is enabled. What would you verify before agreeing that the SRX is misconfigured?
Read the worked answer
Session synchronization preserves many stateful sessions, but it is not a guarantee that every flow or every inspection state survives a failover. First verify the failover type: a warm failover with the failed node still running is different from a cold failover after a reboot or link loss, and session synchronization depends on the control link being healthy. Second, confirm which redundancy group owns the sessions and whether the reth interfaces and the session are in the same group; asymmetric ownership can break return traffic. Third, check whether the dropped flows use ALGs or UTM inspection. SIP ALG state and application inspection state are not always fully synchronized, so the new node may discard packets it cannot associate with a synchronized session. Finally, verify the failover reason with chassis cluster status and logs. The 8-second recovery also points to interface or IP-monitoring timers, not just session sync. I would not call the SRX misconfigured until I had compared a warm failover, checked RG ownership, and reviewed the session table on the new node.
2. The manager proposes a noon failover plus a node 0 Junos upgrade. Give your recommendation and the risks.
Read the worked answer
I would not combine a production failover with a Junos upgrade at noon. A planned failover during business hours already risks dropping long-lived voice and SSH sessions, and the upgrade adds a second variable: if node 0 reboots or the fabric/control link resets, the failover may become a cold failover rather than the warm failover being tested. Session synchronization cannot be assumed to cover all ALG or UTM state, and an upgrade may change session synchronization behavior or require a reboot of both nodes. The safer plan is a maintenance window with a documented rollback, a pre-upgrade backup, and a test of failover before and after the upgrade. If the business requires daytime testing, isolate the test to a low-impact redundancy group or a lab pair. Do not use the noon change to 'save' a maintenance window; that turns a controlled test into an unplanned outage with two possible causes.
3. Which redundancy-group settings affect failover timing, and how could they produce the observed 8-second recovery?
Read the worked answer
Failover timing is influenced by redundancy-group priority, preempt, failover delay, and interface or IP monitoring. If preempt is enabled with a delay, the group may wait before moving back or before declaring a node active. Interface monitoring can trigger a failover when a monitored link goes down, while IP monitoring can hold traffic until a probe succeeds. The 8 seconds may therefore be the sum of link-failure detection, RG transition, and IP-monitoring delay rather than session synchronization alone. I would check the configured thresholds, monitor weights, and any hold-down timers. I would also compare the failover count and timestamps with the syslog events for the reth interfaces. If IP monitoring is configured to track an ISP gateway and the probe interval is long, new sessions will wait even though the RG has already switched. The fix is to tune timers deliberately, not simply to disable monitoring, because monitoring protects against blackholing traffic on a failed uplink.