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:
TDERROR_ALL_VSXM_DBG_SKIP_PING=INFO
TDERROR_ALL_VSXM_DBG_SKIP_INSTALL=INFO
TDERROR_ALL_VSXM_DBG_SKIP_PULL_SIC=INFO
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.
Hi Valerie, when you talk about "Main CMA", do you mean that there is one "Main Domain"? I realized that in a multi-domain environment, if you configure the VSX cluster in a domain, you don't have to do it (including establishing SIC) in the other (new) domains.
ReplyDeleteThank you for the article, you are right, VSX are too expensive to have them only for lab purposes, at least for the company that I work for, they are.
Main CMA is a special term in VSX world to define a special CMA which only handles physical VSX objects. Read the documentation, it is there.
DeleteConcerning VSX being expensive, it does not cost a dime to run them in a lab on open servers or on VMware, with trial licenses.
Dear Valeri,
ReplyDeleteMay I ask a question? We have build a VSX cluster via R76. Our virtual system is working with bridge mode. We found the network flow was very slow. But when we remove the vs, network speed was be normally. Could you ever see the same problem? Thanks for a lot.
Sorry, M, I am not aware of any performance issues with R76 VSX. What do you mean, network was very slow? How did you measure it?
DeleteDear Valeri,
DeleteI think it was about setting mistake. We found connect to web site was very slow. But when we remove the bridge firewall, their network was normally.
Hi Valeri.
ReplyDeleteCould you please confirm that this bypass is still working on Provider R76? I am trying this on our VMware copy of production Provider, but without success.
Yes it does. Try to type in the commands, do not copy/paste
DeleteThanks.
DeleteOne more question: Do you know if this is also working for vsx_util remove_member?
Theoretically yes. But before doing that just check you can double click on VS object and "push config" by pressing OK. That should not return an error. If it shows green OK, the debug bypass works.
Delete