Skip to content
Notifications
Clear all

Help: HA pair failing over for no apparent reason.

2 Posts
2 Users
0 Reactions
4 Views
(@data_skeptic_ray)
Estimable Member
Joined: 4 months ago
Posts: 127
Topic starter   [#18707]

Alright, let's cut through the usual vendor script. I'm dealing with a SonicWall HA pair (specifically, NSa 5700s on SonicOS 7) that's decided to develop a personality. It's failing over to the standby unit with what the logs charmingly call a "HA failover due to unit failure." The diagnostics show all green, no hardware faults, and both units are practically idling at 15% CPU.

I've ruled out the obvious: link monitoring is stable, no flapping on the monitored interfaces, heartbeat sync is perfect. No environmental issues, power is clean. The failovers are random—sometimes days apart, sometimes twice in an hour. The support KBs are, predictably, a circular loop of "check heartbeat, check firmware."

Before I get handed another RMA that probably won't fix it, has anyone actually done a proper root cause on something like this? I'm skeptical of the "unit failure" log event when the unit, post-failover, is fully operational as the passive node. This feels like a software bug masquerading as a hardware fault.

What I'm looking for:
* Specific, non-default HA timers you had to adjust.
* Any correlation with specific traffic patterns or security service loads (even if low).
* Actual diagnostic commands beyond the basic `show ha` that revealed something the GUI didn't.
* Firmware version where this stopped (or started).

I'm tired of superstition and guesswork. What actually worked?


Data skeptic, not a data cynic.


   
Quote
(@isabella2)
Reputable Member
Joined: 1 week ago
Posts: 148
 

Ah, the classic "unit failure" ghost in the machine. You're right to be skeptical - that log entry is the vendor's catch-all for "something spooked us, but we're not saying what."

I chased this same phantom on a different vendor's gear a while back. The key was, counterintuitively, *nothing* in the HA-specific timers or traffic loads. The culprit was a low-level process watchdog, completely unrelated to HA, that would occasionally hiccup and trigger a global "unit health" check. The HA logic, seeing that single failed internal heartbeat, would dutifully fail over, reporting the generic error. The diagnostic lights? All green, of course. The fix was a firmware patch for a memory leak in an IPS signature loader, of all things.

So my pushback to your approach: stop looking at HA. Start combing the *other* logs for any minor, non-fatal process restart that *correlates* with your failover timestamps. Look at the security service subsystems, especially if you have DPI or SSL inspection enabled, even at low load. The "unit failure" is often a lazy interpretation of a single sub-process panicking.


Price ≠ value.


   
ReplyQuote