Tip of the Week - Collecting Gaia OS configuration from a VSX Virtual System

[_Val_]

If you upgrade a VSX Cluster with CPUSE clean install, or do a clean install from scratch, you must do the "vsx_util reconfigure" procedure that doesn't reconfigures OS level configs: DNS, DHCP, Dynamic Routing, etc.

Do not despair, this SecureKnowledge article describes VS_Conf_Collector.sh script, which is designed to automatically collect OS config, so you could easily implement all required changes in a simple manner. Read the mentioned article for full details.

[Henrik_Noerr1]

While great that this is available, it seems to me like solving a problem with more complexity than needed.

vsx_util reconfigure should ofcourse include this information.

I am aware that this require more rewrite of code than Check Point is comftable with - but that these customizations locally on gateways is not included, is beyond me.

If you really think a custom script is needed, please include proxy arp, and add the script to the main installation and or jumbo and onwards, and then have it updated with the Autoupdater as needed.

/Henrik 

[_Val_]

Not sure I understand your point. As mentioned above, with clean install & vsx_util reconfigure, all OS changes you did on the original system must also be manually repeated on the new system. In some cases, there are quite complex configs, including all kinds of changes: DHCP relays, arp proxies, dynamic routing configs, etc. 

None of those are visible on the MGMT side, hence vsx_util reconfigure is useless. Also, saved Gaia configs are not directly applicable, because the interface and VS IDs can shift after the reconfigure. 

The mentioned script allows you one command to collect the data, and one another to put it back in order on the new VSX cluster. 

What do I miss in your argument?

[Henrik_Noerr1]

I am aware that it is not visible on the mgmt side (today) - hence I write: "I am aware that this require more rewrite of code than Check Point is comftable with"

regarding keeping it as a script, let me phrase my request as a question then.

Is it easier for the customer to find the script in the usercenter, check for new version, download and write the script to the gateway and run it or,

is it easier to run the script because it is already there and automatically updated.

/Henrik

[_Val_]

Thanks, @Henrik_Noerr1, it is much clearer now.

In terms of "make it simple and reliable", I am with you. It is much better to have such tools available on the system by default.

However, in this specific case, the mentioned script is working on all supported versions and even some of those out of support. I think you will agree that it is better than going into a manual configuration routine.

[henryd111]

In my opinion, this script is incorrectly specifying the virtual system number, because the set virtual-system command is set sequentially and VS doesn't have to be in that order.

I have 2 VS the last one is number 3 and the script says:

Exporting configuration for Virtual System 0
Exporting configuration for Virtual System 1
Exporting configuration for Virtual System 2

Virtual System 2 is last. Done.

[_Val_]

@henryd111 

Can you please post vsx stat -v here?

[henryd111]

vsx stat -v

[_Val_]

Ok, thanks. There is a cosmetic issue. ID 1 corresponds to vs0, ID 2 - vs1, ID - vs2

The script uses internal numeration starting from 0. 

[henryd111]

What about virtual device ID 3 ?

set virtual-system ID command in my opinion sets virtual device ID not virtual system number

[_Val_]

There is no VS3 in your environment. ID 1 a.k.a. vs0 is your physical environment, plus vs1 and vs2, with IDs 2 and 3.