topic Re: Failover Secondary/Active problem in Network Security

Failover Secondary/Active problem

Leopardi — Tue, 21 Mar 2023 09:44:26 GMT

FPR 2110 with ASA 9.14.3.18

Hello, everyone,
we have an architecture of two ASAs with the above versions that failover between them and are clustered.
Last week we noticed that when doing failover communication with the hello message , some vpn clients would drop. For this reason we decided to isolate the secondary, going to turn off all the communication ports with internal and external and the port that was supposed to do the failover, keeping management on so that it would remain reachable. Now, on Saturday, we don't understand the reasons, what was supposed to be secondary has requested failover and has become the active one, we believe, with the managment interface because it has also taken the managment ip of the primary. We have no persistent logs, a high log buffer and not even a log server. We only see this from the show failover history command where we can clearly see that both devices are active. Do you have any explanation? G

reetings

Re: Failover Secondary/Active problem

tvotna — Tue, 21 Mar 2023 10:33:41 GMT

I believe this shouldn't normally happen, unless secondary was rebooted or there was a temporary communication failure between primary and secondary over management interface. In both such cases secondary would become active, because failover link is down, and split-brain would not be resolved, even though both units have working management interface which could potentially be used to send failover messages. This is design defect CSCvz08085 ENH: Avoid split brain when failover link comm is not possible during boot/election process

Re: Failover Secondary/Active problem

MHM Cisco World — Tue, 21 Mar 2023 13:34:55 GMT

you mention active/standby in your post and then you mention cluster,
which case is Active/Standby or Cluster ??

Re: Failover Secondary/Active problem

Leopardi — Thu, 23 Mar 2023 14:15:23 GMT

Sorry for the inconsistency, it is an Active/standby system. The last, we have resolved switching off the managment interface from the secondary switch and making it completely isolated