This is a professional blog of Check Point Certified Master Architect (CCMA). It does not represent position of my current employer.
Wednesday, May 8, 2013
VSX provisioning bypass trick does not seem to work on R75.40VS MGMT
WRONG, THIS WORKS. PLEASE SEE MY NEXT POST
I am doing lab trials for all kind of management and enforcement side upgrades for my customers, especially for ones usen VSX and MDM. As part of the MGMT sanity checklist, there are VSX provisioning checks to be sure there is no corruption of VSX objects and topology scripts.
Before R75.40VS there was a way to bypass actual connections to VSX clusters in case you are checking MGMT side only.
To do so, once would put the following set of debug commands in the Main CMA context on MDS machine:
fw debug fwm on TDERROR_ALL_VSXM_DBG_SKIP_PING=INFO
fw debug fwm on TDERROR_ALL_VSXM_DBG_SKIP_INSTALL=INFO
fw debug fwm on TDERROR_ALL_VSXM_DBG_SKIP_PULL_SIC=INFO
Once done, you could simulate topology changes for Virtual Systems to be sure scripts are properly handled. MGMT would generate a script without trying to connect to VSX cluster members and/or executing it on VSX cluster members.
Well, not anymore. With R75.40VS this trick is no longer working. It is even more interesting, just because it seems Check Point specialists are not aware of that. I have asked around and even opened a support call to get an answer.
I will keep you posted about the outcome.
Subscribe to: Post Comments (Atom)
We've just checked this on R75.40VS mgmt, and this doesn't happen here.
We didn't make any major changes to the mgmt code in R75.40VS, so it'll be very surprising if we did break it.
This is probably something specific to your env. Please contact me at my CHKP email so we can discuss this further.
Are you sure? This does not work for me. I will re-check. I am having a support request open, could you please talk to Shahar Solomon about this?ReplyDelete
And tell him what? That we couldn't reproduce this? This won't help your cause...ReplyDelete
So, Valeri, from your testing environment, a debug with fw debug fwm on TDERROR_ALL_ALL=5 would be helpful. Set this before you run the other debug commands. That may provide some insight if, first, the debug commands are actually being accepted by fwm, and second, what it does after that, assuming that fwm appears to set itself to the proper debug topics. That said, I've been doing a lot with R75.40VS lately as well, and have not run into this either. I'm not saying this isn't an issue, since obviously it's happening in your environment. But it does appear to require some specific thing or things to trigger it.ReplyDelete
Support could not reproduce this either. I am going to re-check what's wrongDelete
This comment has been removed by the author.ReplyDelete
It works. It was some kind of a glitchDelete