This lab is focused to shows the steps followed during a cut over to migrate a SMART Center Server to a new infrastructure running P1.
The lab utilized is:
- Two Crossbeam Chassis running XOS 9.5.2
- A vsx cluster running in four apms using VSX R65 hfa20.
- The two chassis running in VRRP.
- Looking for a schema were the impact to the network were the less possible.
This plan was tested under a production enviroment and all works ok. But, is necesary before touch any production network have a valid coverage for Crossbeam technical support and Checkpoint.
Before the cutover:
- Obtain a photo from the affected chassis using "show tech-support".
- Obtain a license backup installed in the environment using SMART Update.
- Obtain a cpinfo from all the virtual firewall just in case if we have to open a case with checkpoint.
- Have a backup from the latest firewalls policies.
- Verify that all the licenses related with the P1 are correct.
- Obtain the latest local.arp file.
- Obtain the latest version for the /var/opt/fw.boot/modules/fwkern.conf and /etc/ppk.boot/boot/modules/simkern.conf files.
- Have migrated all the firewalls policies to P1.
Activities during the cutover:
- Installs the corresponding license to the P1 and the CMA.
- Obtain the routing table for every virtual firewall (sometimes after a chassis reboot these routes gets lost is a bug related with the XOS).
- Obtain a backup for the vap-group related to the vsx.
- In the backup chassis in every apm related with the vap-group we have to use the command "reset_gw" and this command brings to a initial state every vsx gateway.
- Using our P1 we have to take the necessary context related with our CMA using mdsenv
- We need to close all the dashboard instances to avoid any problem during the reconfiguration.
- Using vsx_util we have to reconfigure every apm related with the cluster.
- After the execution of the vsx_util we had to fill all the info related to the firewall, for example: "Enter VSX gateway/member object name to reconfigure:"
- We need to use the name of the object related with the cluster if you need to find this info use the dashboard in the cluster section.
- In this case the name of the object was: FW-VSX_Test_fw1.
- Once obtained a message similar to this, we have to reboot every apm affected using the command reboot or "reload vap-group
" 
- If for some reason the vsx_util doesn't work, you'll have to do some troubleshooting or call chackpoint in my case the troubleshooting was enough.
- Once the vap-group goes to active. We can observe it using “show ap-vap-mapping”.
- We can use our newer P1 SMART Dashboard in write mode and in every vsx cluster object we need to press ok in that screen to regenerate every virtual firewall.
- After this step is necessary remove the old licenses related with this vsx cluster using the SMART update in Provider-1
- After remove the old licenses we can continue adding the new licenses files.
- Using vim we have to regenerate the local.arp files in every apm affected by the reset_gw, in other words the backup chassis, the other one must be handling the traffic.
- We can proceed to install the rulebase in every virtual instance, don't forget remove the option "for gateway cluster..."
- After the policie installation we need to check the routes and compare to look if something have change. If something was changed, is necesary to do troubleshooting.
- Verify that arp entries in the local.arp file are working using fw ctl -vs vsid arp
- A very important point is compare the files /var/opt/fw.boot/modules/fwkern.conf y /etc/ppk.boot/boot/modules/simkern.conf, with the files taken before the cutover if something changes we have keep the original configuration.
- After all of this we can switch the traffic to this box using vrrp-relinquish-master.
- Using smartview tracker we can verify that the traffic is flowing.
- We can continue following all of this steps for the other chassis.
No hay comentarios:
Publicar un comentario