topic Re: Force an Active GW to 'Down' status in Firewall and Security Management

Force an Active GW to 'Down' status

georgemal — Mon, 12 Oct 2020 09:50:59 GMT

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

Re: Force an Active GW to 'Down' status

_Val_ — Mon, 12 Oct 2020 12:29:58 GMT

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

Re: Force an Active GW to 'Down' status

Maarten_Sjouw — Mon, 12 Oct 2020 14:21:39 GMT

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.

Re: Force an Active GW to 'Down' status

georgemal — Wed, 14 Oct 2020 07:01:34 GMT

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

Re: Force an Active GW to 'Down' status

IT_Infra_Arval — Fri, 22 Apr 2022 07:59:01 GMT

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

Re: Force an Active GW to 'Down' status

_Val_ — Fri, 22 Apr 2022 09:01:33 GMT

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

Re: Force an Active GW to 'Down' status

IT_Infra_Arval — Fri, 22 Apr 2022 13:05:29 GMT

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

Re: Force an Active GW to 'Down' status

_Val_ — Fri, 22 Apr 2022 13:38:30 GMT

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

Re: Force an Active GW to 'Down' status

IT_Infra_Arval — Fri, 22 Apr 2022 15:17:28 GMT

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.

Re: Force an Active GW to 'Down' status

IT_Infra_Arval — Fri, 22 Apr 2022 15:34:24 GMT

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

Re: Force an Active GW to 'Down' status

_Val_ — Fri, 22 Apr 2022 16:27:56 GMT

do the same with "cphaprob list"

Re: Force an Active GW to 'Down' status

IT_Infra_Arval — Mon, 25 Apr 2022 05:58:58 GMT

Val,

That gives "there are no pnodes in problem state"

Best regards,

Re: Force an Active GW to 'Down' status

_Val_ — Mon, 25 Apr 2022 06:34:17 GMT

on both sides? very unlikely

Re: Force an Active GW to 'Down' status

_Val_ — Mon, 25 Apr 2022 06:34:44 GMT

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

Re: Force an Active GW to 'Down' status

IT_Infra_Arval — Mon, 25 Apr 2022 08:29:14 GMT

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.

Re: Force an Active GW to 'Down' status

_Val_ — Mon, 25 Apr 2022 11:23:27 GMT

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.

Re: Force an Active GW to 'Down' status

IT_Infra_Arval — Mon, 25 Apr 2022 12:08:50 GMT

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.

Re: Force an Active GW to 'Down' status

_Val_ — Mon, 25 Apr 2022 12:41:49 GMT

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.