Virtual System migration between Domains ( managed by MDS )

[H4ppyM3]

Dear Community,

I’ve a MDS running with multiple domains on it controlling few VSX hardware’s.  I received a following requirement:

• Move VS  ‘x’ configured on VSX-1 managed by Domain-1 TO  Domain-2 ( which has virtual-systems from VSX-2 )

So basically I need to move a VS from one domain to other whit less as possible downtime. Which steps could you recommend ?

MDS: R80.30

VSX: R80.30

Thanks

[genisis__]

I don't think there is supported way of doing this, but my only thoughts would be to resic the VS to another DMS, but I've never tried this, additionally your probably more restricted in R80.30 as well, I would suggest this is upgraded to R81.x.

Certainly one for TAC, even Professional Services.  Would certainly be good to know if this is possible.

Clearly one way to achieve this is blow the VS away and recreate it via the new DMS, but I guess this is not what you want to do.

[H4ppyM3]

Thanks genisi_

This step I take as a last consideration: remove on first CMA then recreate on the second.

This is why I would like to first ask if there are any other way's to move them.

[genisis__]

totally understand and hence a really interesting scenario. Have you contacted TAC? 

There is a SK which may also be of interest: SK34098 "How to reset SIC on a VSX Gateway for a specific Virtual System", and I wonder if this would help.

Additionally the other challenge here is if you actually have a sandpit environment to even test this on.

[H4ppyM3]

TAC: Not yet. First wanted to try the community - as it's much faster then asking for help from TAC. lol 🙂

Unfortunately I don't have vsx in our lab 😞

[genisis__]

I feel your pain with TAC!

[Maarten_Sjouw]

You can use the vsx_provisioning_tool to export in CMA1 the current VS config (interfaces and routes) to a text file, adjust the textfile to what you need to have different and then use the provisioning tool again in CMA2 to create the VS again by using the file as input to the vsx_provisioning_tool.

There is a separate document on the Check Point site for the VSX Provisioning Tool.

I used it this week to migrate a VS from old hardware to new hardware. The migration was as simple as removing VLAN's on the trunk on the old hardware and adding them on the new hardware, for switches you create a copy of the switch with a dummy VLAN behind it on the old and the new  cluster.

This method was also used when we needed to migrate a customer from a VSX cluster to a Maestro VSX environment.

[genisis__]

I assume the VS name would need to be different?  I have used the provisioning tool to create a VS, when setup correctly most things can be done, but did get caught out with Anti-spoofing group with exclusions, the tools does not deal with that well (yes reported to TAC, and yes they did nothing about it).

Then of course comes the other question of exporting the policy and objects used by that VS in the old DMS and importing into another, existing DMS.

[Maarten_Sjouw]

When you create the VS you can add the option "auto_calculate_topo true" which should take carte of the anti-spoffing for you, then later you could, if you really need change it to manual.

You can try to open a SmartConsole to both CMA's and use copy paste, however that will not work when you do not have the exact same objects in both CMA's. 

Other option is to copy or move these rules to a single layer and set it to shared, now create a new policy and use this shared layer as the main layer. Then you can use the policy export tools (found somewhere here on CheckMates) and import that into the other CMA with the same tools.

[genisis__]

'auto_calculate_topo' was not suitable in our case, as we needed to excluded certain subnets or hosts. In this scenario you would create a object group  with exclusions and then assign this to the interface.  In Smartconsole this works fine, but using the provisioning tool it does not work.

TAC basically confirm this was currently not supported using the tool.

Additionally the scenario here really relates to to establishing the control connection from one CMA to another but not deleting the VS.

Hence I believe there two parts to this question:

Part1:

1 - Export policy and objects from DMS1

2 - Import policy and object to DMS2

Part2:

3 - Break the SIC connectivity between VS1 and DMS1

4 - Establish SIC connectivity between VS1 and DMS2

5 - Push policy.

I'm pretty sure Part1 can be done, but its Part2 that is the challenge.

CPKra - am I correct in the above challenge you are facing?

[H4ppyM3]

Thanks to all for taking part in conversation. 

@Genisis_

I can skip part 1 as the policy is not a problem to create a new one as it's very small so far.

Most challenging is to move the VS controll under the second domain. I'm not pretty sure if this will work what  you have described in "part-2".  

[_Val_]

There is no explicit manual SIC between a management domain and a virtual system. For part 2, p3 and p4 will be automatically carried when you 

1. Delete "old" VS on DMS1

2. Create "new VS on DMS2. 

The only one thing you need to take into account is, there will be a traffic cut before you re-create VS1 and push policy on it.

[H4ppyM3]

Hi Val,

I'm afraid that this is the only way.  I thought so too. Thanks for your confirmation

[_Val_]

Also, as @Maarten_Sjouw advised here already, vsx_provisioning is the most effective way to re-build a VS in a different domain.