Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
Xterminator
Participant
Jump to solution

Migration of a physical remote management server and gateways to a local one with VSX

Greetings everyone, and good day.

I am planning to migrate a remote management server, with 2 gateways in a VRRP cluster running version R80.20, to a local existing infrastructure, in order for it to be centralized. This infrastructure was migrated previously from an R75.47 version, and has different VLANS and routing.

The local infrastructure is running R80.10 with a few VSX clusters and the relative virtual systems. There is also a dedicated log server running also R80.10.

I have an idea on how to perform this migration, but I am looking for corrections and/or validation of the steps I planned, in order to do this properly. I hope this also helps somebody else in my situation.

1 - Upgrade of the local management server to R80.20:
  a. Snapshot of the management server (SK108902)
  b. Upgrade of the CPUSE package to the latest release (SK92449)
  c. Upgrade of the management server to R80.20 through CPUSE (SK92449)
  d. Test policy installation
  e. Installation of the latest jumbo hotfix package for R80.20 (SK137592)
  f. Repeat steps A through E for the dedicated log server

2 - Migrate objects and policy package to the local management server:

  a. Export the remote management server objects through "migrate export" utility (Youtube)
  b. Import the remote objects to the local management server through "migrate import" utility (Youtube)
  c. Export the remote policy package from the remote management server through these tools
  d. Import the remote policy package to the local management server
  e. Verify correct import

3 - Creation of a new VSX gateway on the local server

  a. Create a new virtual machine or appliance acting as VSX gateway
  b. Create new cluster containing the 2 virtual systems (The IP for the local VSs should be the same as the remote ones)

4 - Integration of the remote gateways in the local infrastructure

  a. Reset the SIC of the remote BACKUP gateway and create a new PSK via cpconfig
  b. Turn off the local interfaces on the underlying switch except for the management
  c. Create SIC on the local management server
  d. Policy installation

(Begin disservice)

  e. CPSTOP on the ACTIVE gateway
  f. Turn on local interfaces on the switch for the gateway connected to the local management

(Stop disservice)

  g. Repeat steps A-D for the remaining gateway

 

I'd be most appreciative for any inputs or thoughts you might have on this approach.

 

Thanks in advance for your help.

 

0 Kudos
1 Solution

Accepted Solutions
Xterminator
Participant

Hello,

To update the thread and share with the group, we've performed the following. We've decided not to use the physical gateways but to create a new Virtual System within VSX:

1 - Upgrade of the management server and log server to R80.30 (same procedure mentioned in the original question, but to R80.30 version)

2 - Clean-up of some unused rules and objects (based on hit-count and Object explorer). Verification of VLANs and VPN communities. For the latter, it is recommended to involve any third-party providers and eventually reset the PSK if not already available.

3 - Test the import script on a separate (test) management server, in order to verify any potential conflicts and issues (optional, but really recommended).

4 - Create new VS with the original VIP address of the 2 physical nodes, and import the policies/ruleset with the Checkpoint script. Verification of the imported objects and rules

5 - Switchover of the appliance

Thanks and Regards

View solution in original post

0 Kudos
1 Reply
Xterminator
Participant

Hello,

To update the thread and share with the group, we've performed the following. We've decided not to use the physical gateways but to create a new Virtual System within VSX:

1 - Upgrade of the management server and log server to R80.30 (same procedure mentioned in the original question, but to R80.30 version)

2 - Clean-up of some unused rules and objects (based on hit-count and Object explorer). Verification of VLANs and VPN communities. For the latter, it is recommended to involve any third-party providers and eventually reset the PSK if not already available.

3 - Test the import script on a separate (test) management server, in order to verify any potential conflicts and issues (optional, but really recommended).

4 - Create new VS with the original VIP address of the 2 physical nodes, and import the policies/ruleset with the Checkpoint script. Verification of the imported objects and rules

5 - Switchover of the appliance

Thanks and Regards

0 Kudos

Leaderboard

Epsum factorial non deposit quid pro quo hic escorol.

Upcoming Events

    CheckMates Events