Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
georgemal
Explorer

Force an Active GW to 'Down' status

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

0 Kudos
17 Replies
_Val_
Admin
Admin

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

0 Kudos
Maarten_Sjouw
Champion
Champion

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.

 

Regards, Maarten
0 Kudos
IT_Infra_Arval
Explorer

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**

0 Kudos
_Val_
Admin
Admin

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

IT_Infra_Arval
Explorer

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

 

0 Kudos
_Val_
Admin
Admin

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

0 Kudos
IT_Infra_Arval
Explorer

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.

 

0 Kudos
IT_Infra_Arval
Explorer

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

0 Kudos
_Val_
Admin
Admin

do the same with "cphaprob list"

0 Kudos
IT_Infra_Arval
Explorer

Val,

 

That gives "there are no pnodes in problem state"

 

Best regards,

 

0 Kudos
_Val_
Admin
Admin

on both sides? very unlikely

0 Kudos
_Val_
Admin
Admin

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

0 Kudos
IT_Infra_Arval
Explorer

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.

0 Kudos
_Val_
Admin
Admin

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. 

0 Kudos
IT_Infra_Arval
Explorer

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.

0 Kudos
_Val_
Admin
Admin

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. 

0 Kudos
georgemal
Explorer

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

0 Kudos

Leaderboard

Epsum factorial non deposit quid pro quo hic escorol.

Upcoming Events

    CheckMates Events