- CheckMates
- :
- Products
- :
- Quantum
- :
- Security Gateways
- :
- rename VSX cluster member
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Mute
- Printer Friendly Page
Are you a member of CheckMates?
×- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
rename VSX cluster member
Hi Checkmates,
Our customer's wants to upgrade his environment from R77.30 to R80.20.
Problem is: he has a VSX cluster with cluster members named 'fw1' and 'fw2'. After importing the SMS database to a new R80.20 management server the Validations tab tells us that "more than one object named fw1 exists" (the other being a default service FW1).
Long story short: we have to rename VSX cluster member 'fw1' before we can consider upgrading. In my lab I experimented with vsx_util:
- vsx_util add_member to add a Dummy gateway
- vsx_util remove_member to remove fw1
but this can't be used: "A previous remove member operation did not complete for..." because there is no SIC with the Dummy gateway, which also prevents policy installs to the remaining VSX member.
TAC told us to use vsx_provisioning_tool (and to contact Professional Services 🤔), but after reading the documentation and testing some commands I don't see how that would work.
Anyone?
Ph.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
If I remember correctly you when you turn on the following VSX debugs it skips the provisioning process and allows you to make changes without communication:
#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
Make changes to VSX gateway
Disable debugs with #fw debug fwm off
Might try this in your lab to see if it will let you delete.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks Alejandro, I'll test it tomorrow!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I'm afraid this didn't solve it. Still getting:
"Previous remove member operation was not completed. Run 'vsx_util remove_member' again to resume operation."
I'll dive a bit deeper still maybe removing the whole cluster & recreating it will be the only solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Going to test further with TAC.
I'll post the solution here, maybe it will come in handy for someone else later on.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
We now created a procedure for the rename in lab:
- Add dummy node with "vsx_util add_member"
- Remove the original node with "vsx_util remove_member"
This will generate an error regarding SIC communicatio - Edit '$FWDIR/conf/objects_5_0.C', find the dummy gateway object and related child objects and change the status and SIC information
=> Change 'connection_state (uninitialized)' to 'connection_state (communicating)'
=> Change the ':sic_name ()' to a normal value ':sic_name ("CN=Test_tmp,O=gw-2c1401..962djh")' in our test
=> For the child object, in this test there’s only one VS named VG1, so the corresponding sic_name is ':sic_name ("CN=Test_tmp_VG1,O=gw-2c1401..962djh")' - Run 'vsx_util remove_member' again to remove the original node, this will generate another error (not being able to communicate with the dummy node)
- Reset or reïnstall the original node (in our lab we used 'reset_gw' in 'vsenv 0')
- Following sk101674, edit '$FWDIR/conf/objects_5_0.C'
=> find :operation_type (add_remove_member) and delete the blocks where the status is not OK [:status (OK)]
=> Save the file and exit
=> Remove the SmartConsole cache and restart the checkpoint services:
cd $FWDIR/conf/
rm CPMILinks*
cpstop
cpstart - Add the original node again under the new using 'vsx_util add_member', this should run ok now
- Restore the configuration on the renamed node using 'vsx_util reconfigure'
- Remove the dummy node using 'vsx_util remove_member'
- Verify in SmartDashboard
- Test policy push
We will keep this procedure as backup scenario for production, for production we will create a VM with with 10 nics and add this VM as a third node while reinstalling the original node.
Any feedback is welcome!
