For example, I am working on some support issues with a customer, and we do not intend to mess around our production system. We could build a physical lab, but having extra VSX 9090 just sitting there is too expensive. VMware seems to be a good option, but there are two blocking issues:
- you cannot create a VMware machine with more then 10 interfaces,
- it is impossible to restore VSX appliance to VM.
What to do then?
There is a way to run some simulations without physical VSX machines, using your MGMT only.
Usually if you are touching VSX objects, pressing OK button starts a provisioning script that runs on the Main CMA. This script is supposed to push configuration changes to your physical machines and all relevant VSX objects: virtual systems, routers and switches. If your physical machines are not available, the script will fail.
But you can bypass actual provisioning scripts being sent to VSX members by using some specific debug flags.
On the Main CMA run “fw debug fwm on” with the following flags:
These flags will suppress connectivity checks and scripts' execution on VSX, if the cluster members are not available.
It means you can re-create your MDS on VMware and then play with it before making any change on production. With this commands having VSX machines on VMware lab is not required.
I have to make some warnings before wraping this up.
- Remember, all provisioning happens on the Main CMA, so mind your Provider-1 context before executing these debug commands.
- Avoid using this technique on production environment unless advised by Check Point support to do so.
- Close any GUI clients before executing the commands. MDG can still be open, but having SmartDashboard or even GUIdbedit running while you are putting these debug flags affect the outcome.
We are masters of customized training. If you do not find your subject in our schedule, contact us anyway, we will tailor a training session specifically for you. You will not be disappointed.