Force an Active GW to 'Down' status

[georgemal]

Hello guys,

I was reading sk101690 (How to reset a VSX Gateway) and there is the pre-requisite below:

"On VSX cluster member, the member state must be 'Down' or 'Standby' before starting the VSX reset procedure."

For the Standby member (for all Virtual systems) this is OK, but how to force the Active GW to be in 'Down' state?

Should i just use the command clusterXL_admin down on the Active? I guess i cannot force the Active to the 'Standby' status, since it will be the only GW on the cluster after resetting the Standby one.

I am interested for doing sth similar on Gaia R80.10 (VSLS).

Thank you in advance for your ideas!

Best regards,
George

[_Val_]

When you push your Physical Active to Down as the SK describes, your Standby becomes Active Attention and starts passing traffic. Depending on your cluster settings, cancelling down status you just forced may result in one of the following actions (physical clusters only):
1. Your cluster member A goes to Standby, while the cluster member B (Previously Standby) remains Active till the next failover

2. You cluster member A resumes Active and, member B goes back to Standby. 

In case of VSX, forced down status for VS0 does not affect the rest of the VSs, as described in sk95133

[Maarten_Sjouw]

When you need to make sure you have 1 member active in a VSLS environment you can als use 'vsx_util vsls' on the management server to make all VS's actives on one member.

This will not change the cluster state but will make sure a VS will only be active on a certain member.

[IT_Infra_Arval]

Maarten,

If I use the make all VSes active on 1 member is it correct that on the other member the VSes show as DOWN instead of STANDBY? That is how cphaprob stat shows them (ACTIVE and DOWN, not ACTIVE!)

Best regards,

**bleep**

[_Val_]

Not under normal operational conditions, only if you push them down with admin command

[IT_Infra_Arval]

Val,

Thanks for your response.  I'll wait what TAC makes of it. For now I even worry to push a ruleset since I have no idea if this will further break things. I have my active virtual systems running but no standby's.

No need to sign my name since it will be beeped again I guess

[_Val_]

what do you see from "cphaprob stat" on per vs?

[IT_Infra_Arval]

Val,

On the active member both vs's are ACTIVE (not ACTIVE!) and on the standby unit DOWN. FWD process is running in all context.

[IT_Infra_Arval]

Virtual Devices Status on each Cluster Member
=============================================

ID | Weight| NLHTNFW01 | NLGRNFW01
| | | [local]
-------+-------+-----------+-----------
2 | 10 | ACTIVE | DOWN
3 | 10 | ACTIVE | DOWN
---------------+-----------+-----------
Active | 2 | 0
Weight | 20 | 0
Weight (%) | 100 | 0

[_Val_]

do the same with "cphaprob list"

[IT_Infra_Arval]

Val,

That gives "there are no pnodes in problem state"

Best regards,

[_Val_]

on both sides? very unlikely

[_Val_]

also, does it show policy installed on those which are down?

[IT_Infra_Arval]

Val,

No pnodes in problem state on both sides. How do I check if the policy is installed?

I don't want to push a policy (what I would normally do first ) because of the unexpected result of the update. I don't know if it break some more.

[_Val_]

How do you mean, update? Did you upgrade your VSX cluster? What did you update? If that was an upgrade, policy push is required at the end.

To see the policy status, run "fw stat". I also sincerely advise some formal Check Point courses to take, to gain a better understanding of the technology. 

[IT_Infra_Arval]

Val,

I installed JHF an the openssl patch on the vsx cluster. We were on an older JHF that does not support the patch.

I first installed the JHF and patch on the unit where both virtual systems were in standby, waited 2 days to see if all kept working, moved the virtual systems with vsx_util vsls to the other node, waited another 2 days and finally installed the JHF and patch on the other unit.

fw stat shows the vsx policy installed on both. I am missing a bond on the node where the virtual systems did run before I started installing (now the system where they are supposed to be standby).

Your continuing help is highly appreciated.

[_Val_]

I would check what policy is running, and would push a new version of the policy anyway to each of the VSs. 

Missing bond should show in the pnotes, if it is a cluster monitored interface. Get a service window, push policies, and, if not cleared, rebook both physical GWs. 

Also, please send me your SR number to vloukine@checkpoint.com, I will take a look, just in case. 

[georgemal]

Thank you guys for your answers.

In my case i would like to try resetting both GWs, (at first the Standby one and then the Active)  and it is ok not to have any active GW all the time until i will completely reconfigure them.

So, my question has to do with the most convenient way that i can follow in order to reset the Active GW, since it needs to be in 'Down' or 'Standby' state first.  During the time i will reset the 'Active' GW, there will be no Standby one since it will have been reset already.

I hope i clarified better my case.

Best regards,

George