commands not being accepted on command line cli gaia 77.20

[check3r]

I am runnning the following commands on a checkpoint device running in VSX mode.

I just want to change ip address of existing interface and also add some new static routes but the commands aren't being accepted.

xxx:0> set interface eth1.400 ipv4-address x.x.x.x mask-length 24
CLINFR0699 Invalid command.

same this happens set static-route command

Any reason why these commands aren't valid or am i missing something

Also when i look at the config of the devices these are the commands being used to configure interfaces and static routes

Thanks for any help

[_Val_ · Accepted solution]

Both routing and interface modification commands are not supported on a GW in VSX mode. Network and routes should only be modified from the VS object in the SmartConsole. That said, R77.20 has been out of support for ages now.

[check3r]

Thought as much - Better get that old manager running again ...

If i can't get the manager running, what other options do i have 

maybe setup new SIC with another smartdashboard running R77.20 and make route and interface changes for the VSXs via the objects.

thanks for the response

[the_rock]

That sounds like your only option...

[PhoneBoy]

If you can’t get your old management running (you have backups, right?), you’re going to have to build a new one from scratch.
Recovering the policy off the gateway is going to be a largely manual process. 
The following may be helpful in that:  https://community.checkpoint.com/t5/Management/Recover-policy-after-management-crash/m-p/135868#M289...
You can try to retrieve the files in $FWDIR/state off the gateway for each VS.

[Bob_Zimmerman]

Also of note: a new management server wouldn't have any of the VSs already defined. I don't think you can build a VSX firewall or cluster object in SmartConsole without successfully establishing SIC and provisioning it. If you reset SIC on the firewall and establish trust with a new management, the moment you build a VS object, it will provision the VSX box. The new provisioning data won't include any of the existing VSs, so they will all be deleted from the firewall.

This is guaranteed to involve an outage for all traffic which touches any VS on the VSX box.

The debugs I posted in this earlier thread might let you build the new VSX object without establishing SIC yet, but I don't think they do. They will definitely let you build and manipulate VSs once the VSX object exists.