- CheckMates
- :
- Products
- :
- Quantum
- :
- Management
- :
- Re: changeover strategy
- 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
changeover strategy
Hello all,
I have got very helpful support from this forum , during my migration process from R77.30 to R80.10.
I have successfully migrated database server from R77.30 ( appliance) to R80.10 enviroment ( open server)
i have copied the configuration from the two gateways 4800 (R77.30) to two 5800 (R80.10).
1.Now i would like your advice on the best strategy to change over.
2. when you migrate the export do you also migrate the OS configuration or you will have to do save configuration and load configuration on the management server like what i did to the gateways..
3.what challenges have you encountered when migrating and the points i need to check on closely.
your advice is highly appreciated . i will be doing the changeover today in the evening.
thanks all in advance.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
You have to backup (or rather save Gaia configuration) and load it separately:
If you did not encounter any issues performing migrate export/import, you should be good to go.
Since these are new gateways, you'll have to change the appliance model and in the gateway's object properties, clear SIC on the management server and re-establish it with new gateways.
After SIC is established, If any of the interface names have changed, verify the topology of the gateways (Do not perform Get Interfaces with Topology, known to occasionally wreck havoc, but Get Interfaces by itself is pretty safe).
Once it is done, you should have no problem pushing the policy.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks very much Vladimir, the migration process was smooth .
ON THE MANAGER,
1.On the management i did migrate/ export as indicated by the SK above on the management server database .
NB I used a different IP address not the actual (IP of the current manager) and generated an evaluation licence , i plan to change the IP when i switch off the current manager and load the licences since they are attached to that IP ( advice me on that Process)
2. I checked on the topology of the current manager and its empty and on the new virtual server R80.10 its still empty ,could there be a problem ?
3. all the other configurations of cluster, isp, nat migrated.
4.the current manager is an appliance , the new manager is virtual , how do i transition ?
5. the other issue is replication of the new manager to the DR should i retain the same as it is .
6. i have not migrated logs from the log server which i tend to retain and to the server. any problem ? other logs are in the current manager.
ON THE GATEWAYS
1. I copied the show configuration from gateways to a notepad++ and pasted it on the new gateways , it copied well but had an issue with port 443 ( set ssl port 443) ( error being it should be changed from the console) and prompted me to either continue or not I removed it . was this right ?
2. I hope the gateway will get the policies from the manager once i install the policy the first time after SIC. could there be anything remaining on the two new gateways ? kindly advice.
3. There is a DR gateway( R77.30) which i didn't change and i will retain it what changes do i need to do in the new manager ?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
this is the extract of the ssl error
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Peter,
The default port is, normally, 443, so you may not have to change it.
If you can connect to your new manager via https://manager'sIP , without spacifying a port number after ":", leave it be.
The topology of the Management Server is only important if it is a multi-homed server with more than one NIC and is using some interesting routing logic, (this is possible, but unlikely in most implementations).
If your original's server topology was empty, leave it be for the new one.
Transition from Physical to Virtual does not represent a problem, so long as VM is properly provisioned and was installed from ISO, not from OVF, has ample CPUs and RAM allocated to it.
One caveat is the ability to interrupt boot to perform corrupted storage scan and fix: There is a post somewhere in CheckMates describing what parameters should be changed to allow that. This is a prophylactic measure and does not affect SMS' current functionality.
For the Gateways, copy/paste from Putty or any other SSH client should work fine. Hopefully you've performed "save configuration" and rebooted the appliance after performing it.
For the SMS (manager), you better-off doing it manually and only copy/paste portions of the Gaia config that remain the same. Example may be the SNMP settings, NTP, DNS etc..
If the IP and the name of the new Manager (SMS) are different from the old one:
You do not have to shutdown old manager or gateways, you can simply unplug the gateways and plug in new appliances.
In a more sophisticated environments, if you have the control over your switches, you can disable the ports those devices are connected to, and enable ports connected to the new appliances (after waiting for the ARP cache to expire (about 30 seconds default in Cisco switches).
For DR, if your old manager is still up, keep the DR gateway managed by the old manager, until you are sure that your primary implementation is completed successfully.
Once verified and you are ready to transition DR gateway to the new management, verify connectivity between them (i.e. SSH from new management to DR gateway).
Reset SIC on DR gateway and establish SIC to its object from new SMS.
Any reason you do not want to upgrade it to R80.10?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Vladimir,
I appreciate you advice, and comprehensive feedback.
On the new manager i had used a different IP for smooth migration without affecting the current processes but i will change it to the IP address of the current manager because the licence is attached to it but i have an evaluation licence for the current manager which i can use during transition period. hope this is what you meant ?
.
I found your plan very helpful to unplug the two old gateways ,plug the new gateways while using the evaluation license , then when everything is fine, i change the IP of the new manager to the IP of the old manager ,detach the evaluation licence and attach the licences . RIGHT ?
On the gateways yes i saved configuration and reboot.
on the topology of SMS , i will do the configurations manually.
VM is properly provisioned with enough storage,memory and CPUs. I installed it using ISO.
on the DR , i agree it will be ok if i leave it managed by the current manager , during the evaluation period . i intend to upgrade it later using CPUSE.
On replication of the manager whats the best approach ?
THANKS
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
You can re-assign license to the IP of the New SMS in your Check Point User Center after successful conversion.
When you are asking about replication of the manager, are you referring to Management HA or the replication of the VM?
If first:
Prepare fresh deployment of the secondary management server with new IP and the host name.
In your new environment, delete secondary management from all rules it is referenced in and then the object itself.
Save database and push the policy.
Create new management server object and establish SIC with it.
Sync the management servers.
Add this new object back into the rules it was previously removed from and push the policy.
If you need to have replica of the logs on your secondary management server, define it as the destination for logs in your gateway objects and push the policy again.
If you are referring to the replication of the VM, it is a different story altogether.
In this case, I would've configured your management VM differently:
1. Configure a routable (RFC 1918) /32 loopback address in Gaia and assign licenses to it in the User Center.
2. Add two more interfaces to the Management Server in Gaia, one that belongs to the network in Primary and one to the network in DR.
3. If you are using dynamic routing in your environment, advertise the loopback IP via OSPF, RIP or BGP via both ports.
4. If you are using static routing, establish static routes to the loopback address at both locations pointing to the IP of the physical interface of the SMS in corresponding network.
5. Configure secondary default route on the SMS in Gaia to point to the IP of the gateway in DR with lower priority (higher number):
6. Replicate this VM to DR site.
7. Power down VM in Primary
8. Power up VM in DR
9. Once you've confirmed that you can access the management server via its loopback interface in both sites and that you can reach your gateways from it and it from your gateways (SSH), power it down in DR and power up VM in Primary.
10. Establish SIC from this SMS to your gateways and push the policy.
11. Delete the replicated VM in DR.
12. Setup scheduled replication of the VM to DR.
*Note that in this case, your logs on the replicated SMS will be trailing by delta between last replication of VM and the time it is powered up.
**Note that you should take care not to have both VMs UP, especially when using dynamic routing.
Cheers,
Vladimir
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks Vladimir,
Its not management HA its replication , for the steps you have provided in Gaia and
for the Vm .
You have captured my enviroment very well and assisted accordingly .
I have also taken your precautions seriously.
IF you have SK or a site which can help during the process kindly share.
In case of any issue during change over i will let you know.
Regards.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Whether you migrate the OS configuration or recreate it manually is largely a horses for courses discussion.
If you are going the export/import OS config route, unless it is the exact same hardware, you will probably have to modify the exported configuration so when it is imported, it will make sense.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
On the gateways i used copy pasting of configurations, which was successful but i copied the configurations to a notepad and pasted the to the gateways using putty, is that the best practice ?
On the manager i used Migrate export and migrate import which was successful, the point am not clear on is if i migrated OS configurations of the MANAGER from the current appliance to the new virtual sever ? when i checked the topology on both it was empty. DO i perform copy/paste of show configurations of the MANAGER ?
The strategy i intend to use is shut down the current manager together with the gateways and put up the virtual manager together with the two new gateways together with the gateway at the DR. Could you have any best practice from your experience . Thanks.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks Vladimir,
Its not management HA its replication , for the steps you have provided in Gaia and
for the Vm .
You have captured my enviroment very well and assisted accordingly .
I have also taken your precautions seriously.
IF you have SK or a site which can help during the process kindly share.
In case of any issue during change over i will let you know.
Regards.
