sync interfaces going up and down (partially up)

[fabiofabio]

Hello,
this morning I replaced one of the two nodes in HA, the new one was configured and tested in a test environment and in fact now it has no problems. the problem occurs in the two interfaces (ETH4 and 5) that deal with the sync. these keep going up and down

from the smart console are partially up

ETH4 is set as secondary in sync while ETH5 is primary.
node 1 (the old one) restarted by itself when I attacked node 2 (new) and node 1 was not restarting for a year. at this moment node 1 is running and has no problems, but due to the problems on the interfaces there is no node 2 among the members of the HA

I read that I should broadcast the network cards to solve the problem but I don't want to, as it has worked so far. the problem shouldn't be here.

any suggestion?

thanks

[the_rock]

I cant say this 100%, but I believe it was never recommended to use 2 sync interfaces. Regardless, you can try below steps. I always use to do this when someone had issues with sync in the cluster.

Andy

https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solut...

[Chris_Atkinson]

Which GW version is this?

Note the use of more than one dedicated physical interface for synchronization redundancy is not supported. You can use Bonding for synchronization interface redundancy.

[fabiofabio]

this configuration works since 2014, I have no idea at this point how they made it work, however, can this modification to create the bonding be done hot? taking into account that I only have a functioning node and that I can no longer afford down periods.

[the_rock]

You can do sync debug from the link I sent, hope that helps, as it should give you a clue why its failing.

[the_rock]

Also, to add what @Chris_Atkinson said, I dont know if it says anywhere its not officially supported, but either way, all I can tell you from my experience is that I had customers run it and it does work, BUT, when it breaks, tough fixing it...its NOT an easy task, thats for sure.

[Chris_Atkinson]

For reference it's explained in the Cluster XL admin guide here:

https://sc1.checkpoint.com/documents/R81/WebAdminGuides/EN/CP_R81_ClusterXL_AdminGuide/Topics-CXLG/S...

[the_rock]

Thank you for that.

[Timothy_Hall]

Backing up what Chris said here, I even mentioned in my book that adding a second physical interface as a 2nd sync is not a good idea and to use a bond instead:

Click to Expand

If you elect to add a second sync network, bond the original physical interface with
another physical interface via the Gaia web interface (or clish) and declare the new
bonded aggregate interface as “1 st Sync” in the cluster object topology settings. DO
NOT simply add a new non-bonded interface and declare it as “2nd sync” in the cluster
topology, as this setup will severely degrade cluster performance. Check
netstat -ni statistics as well for the physical sync interfaces to ensure zero values
for RX-ERR and RX-OVR.

[the_rock]

I think I will buy your book @Timothy_Hall , one of my colleagues said he got it on Amazon and loved it :- ). Any discount code for checkmates peeps? haha

[Timothy_Hall]

Unfortunately I have no ability to create discount codes at Amazon for the hardcopy edition.

However discount codes for the PDF edition and the self-guided video series offerings do tend to pop up during CPX season every year so stay tuned.  

[the_rock]

Just bought it on amazon, pays to be prime member : )

[PhoneBoy]

The top of this SK suggests you should, except in a few unique cases, only use bonded sync interfaces if you want redundancy.
https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solut...

[Chris_Atkinson]

sk92804: Sync Redundancy in ClusterXL