Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
LostBoY
Advisor
Jump to solution

Failvoer issue on Vsec GW Cluster R81.20

I have a Checkpoint vsec Cluster in AWS on R80.40. Recently i upgraded it to R81.20 however somehow the HA functionality is not working on R81.20

As in AWS ..default route is pointed towards eni of active member (say Member A) and when a failover occurs eni changes automatically to that of secondary member (Mem B). However this is not happening on R81.20 in my case , even after simulating the failover default route still points to eni of Member A even though Member B is active. Is there any specific config required to be done on R81.20 wrt failover ?

any help is appreciated.

1 Solution

Accepted Solutions
LostBoY
Advisor

Issue is resolved now..turned out there was an issue with the GW DNS due to which it wasnt able to connect to AWS Services which would have led to a route swithover.

as soon as DNS was resolved route switch is working as expected.

Thank you to everyone who replied to this thread 🙂

View solution in original post

9 Replies
the_rock
Legend
Legend

Have not heard of issue like this yet. What happens if you run cphaprob commands on both members, does it show correct state as it should after failover? It would make sense that ENI would automatically switch over to other member upon failover, I agree 100%. 

Do you see any relevant info/logs on AWS side at all?

0 Kudos
LostBoY
Advisor

Cphaprob commands show the correct state after i simulate the failover.. its just that the eni isnt switching.. at aws side also i didnt find anything.

There is one thing though ..in r80.40 i used to run these as Active active.. but in r80.20 documentation for cloudguard its specifically mentioned to work as an active standby unit with an additonal option in smartconsole as "use in geo cloud mode".

I wonder if thats the issue and it isnt supposed to run in active active in a way as it did in r80.40

0 Kudos
the_rock
Legend
Legend

Im pretty sure in R81+, you can only run as A-P, NOT A-A

0 Kudos
LostBoY
Advisor

Yea in the documentation also only A/P is mentioned but i configured my R81 with A/A and it seems to work fine.

I think may b the A/P option with "use Geo Mode" in R81 serves the same purpose as an A/A cluster as the external routing also is similar

0 Kudos
Nir_Shamir
Employee Employee
Employee

It doesn't matter if it's A/A or A/P  , both work in the same way with the external route table.

Check $FWDIR/log/aws_had.elg log file if there are any exceptions there 

0 Kudos
Dmitry_Gorn
Employee
Employee

Hi,

 

That would depend on which solution did you upgrade from - single az or cross az cluster.

R81.20 cross az cluster uses a different Active-Standby architecture.

Please refer to the updated upgrading documentation index and specifically to the following document:

In case of upgrading a cross-az cluster, additional steps are required to complete the upgrade.

 

Regards,

Dmitry

 

 

 
LostBoY
Advisor

I followed this exact same document while upgrding..however i tried to configure my cluster  as A/A as well as A/S and both seem to work fine. In R80.40 use geo cluster with A/S wasnt an option which is available in R81. I wonder why A/A is not mentioned in the document there as it seems to be working fine.

0 Kudos
LostBoY
Advisor

Issue is resolved now..turned out there was an issue with the GW DNS due to which it wasnt able to connect to AWS Services which would have led to a route swithover.

as soon as DNS was resolved route switch is working as expected.

Thank you to everyone who replied to this thread 🙂

the_rock
Legend
Legend

Good job and tx for sharing!

Leaderboard

Epsum factorial non deposit quid pro quo hic escorol.