R77.30 sunddenly gone active/active

[DH_ND]

Hi Checkmates

We have several active/standby clusters running R77.30 in our environment. All of a sudden one of them is reporting to be active/active. Its been like this for a week or so now an we are not really seeing any major issues caused by this.

Been relatively new to Checkpoints im not sure where to go with this in regards to finding out what  caused this and how I can rectify it.

Where are the logs that may show when this happened and how?

cphaprob -a if

eth1 non sync(non secured)
eth3 sync(secured), multicast
eth2 non sync(non secured)
eth2 non sync(non secured)

Virtual cluster interfaces: 5

eth1 x.x.x.x 
eth2.1110 x.x.x.x 
eth2.1120 x.x.x.x 
vpnt1 x.x.x.x 
vpnt2 x.x.x.x 

cphaprob stat

Cluster Mode: Sync only (OPSEC) with IGMP Membership

Number Unique Address Firewall State (*)

1 (local) x.x.x.x Active
2 x.x.x.x Active

(*) FW-1 monitors only the sync operation and the security policy
Use OPSEC's monitoring tool to get the cluster status

cphaprob role

Number Role

1 (local) Master
2 Master

Thanks for any help.

[Chris_Atkinson]

Your cluster may currently be using VRRP rather than ClusterXL to determine the active/standby state (sk39676).

[mdjmcnally · Accepted solution]

Cluster Mode: Sync only (OPSEC) with IGMP Membership

That line tells me that using VRRP rather then ClusterXL to do this particular Cluster.

VRRP boxes in cphaprob stat output will show Active/Active.

As such I wouldn't believe that this is actually an issue.

If you use the command

show vrrp 

On the boxes and should report back a Master/Backup status instead.

[DH_ND]

Hi all 

Thanks for quick response. Yes they are using VRRP for HA.

Looking at the show vrrp command it does say that one is master for all monitored interfaces and the standby box states backup.

Its just strange that this was showing active/standby with cphaprob stat and is now showing active/active.. Strange. Luckily we are replacing these boxes with some 6500s and we will be using clusterXL as we have no real need to be using VRRP.

Just another quick question. If I need to make the standby a master an a certain interface how would I do that.

Thanks again

[mdjmcnally]

If an interface fails etc then would want the whole system to fail across to the Backup Unit.

Not really sure what you would get from that anyway

Traffic would go via the 1st Network and out of the 2nd Network which would still be Backup State.   This would work, however the reply traffic would then go back to the Active Unit still.

I'll be honest I haven't touched VRRP in years.    Was familiar more when using IP Appliances with IPSO but since Gaia then always moved to ClusterXL and if had issues with the MAC failing over then used the VMAC mode so that had a common MAC for the Cluster IP.

Only had to to do that with a couple of customers, only thing I could ever find was that BT involved as the ISP.

[DH_ND]

HI Mdjmcnally

Sorry meant to force the entire system over to the standby. I'm a little rusty on vrrp as well lol. These are old boxes and not really sure why they were setup this way in the first place. ClusterXL will be on the new boxses.

Thanks for the reply

[mdjmcnally]

I suspect that most likely that they replaced Nokia IP Appliances, which ran VRRP which is usually where come across people using Gaia VRRP.

However I can answer this one for you.

VRRP works on a Priority and Priorty Delta.

The Priority is the BOX priority and the Priority Delta is the change made to that by each Interface.

If you look in the Gaia Portal then look at the Virtual Router.

TYPICALLY people set a Priority with a difference of 10 between the two boxes, ie 100 and 95 with a Priority Delta of 10.

IF one of the Interfaces fails then this will subtract 10 from the Priority, so would drop the 100 to 90 which being lower then the 95 on the Second Unit would cause the system to failover.

So if you want to force a failover then look at the two units to see what the Priority is set too and adjust one of the units Priority, ie if the 1st is 100 and the 2nd 95 then make the 2nd a Priority of 105 which will then give that the higher priority and then cause the failover.

Then if want to move back then change the Priority back to 95.

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

Gives details on how to configure VRRP and goes through how it works as a nice refresher.

[DH_ND]

Hi Mdjmcnally

Thanks for the reply.

That makes sense.

I'll have a read through that document it will be a good refresher cheers.

Cheers

[Timothy_Hall]

For as long as I can remember, if you are using a third party clustering solution (i.e. not ClusterXL), the command cphaprob stat, the SmartView Monitor, and the SmartConsole Gateways & Servers tab have always shown a status of Active/Active along with the term "Sync Only".  This indicates that the only portion of ClusterXL in use with something like VRRP is the state sync functionality between the members.  Of course the true state of the VRRP cluster can be determined from the Gaia level.