Plan de migración de SMART Center a Provider-1

Hola a todos, debido a que surgió un proyecto de migración aP1 y no había encontrado información relevante con respecto a este tema, decidíhacer un laboratorio relacionado a esta actividad y compartir el plan demigración con ustedes.

En este lab se reflejan los pasos utilizados para migrar unSMART Center Server usando VSX a un ambiente de provider-1.

El esquema utilizado es el siguiente:

1. Doschasis Crossbeam corriendo XOS 9.5.2
2. Uncluster con 4 apms corriendo VSX R65 HFA_20
3. Losdos chasis en VRRP
4. Unesquema donde no se tenga impacto en la red, afectando primero el chasis debackup y mediante vrrp probar una vez que se migro a P1 que todo trabajecorrectamente.

Este plan ya fue probado en ambientes de producción y todotrabaja correctamente, solo antes de realizar cualquier movimiento es necesariocontar con contrato de soporte con Checkpoint y Crossbeam.

Antes del cambio:

1. Obtenerla foto de los chasis afectados mediante un “show tech-support”.
2. Obteneruna copia de las licencias cargadas en el ambiente, usando el SMART Update.
3. Obtenerun cpinfo de toda la plataforma, para tener una foto del ambiente por si senecesita abrir un caso con Checkpoint.
4. Tenerla versión de las políticas firewall más recientes.
5. Verificaren el P1 que las licencias que se tienen son correctas.
6. Obtenerla última versión del archivo local.arp de todos los firewalls.
7. Tenerla última versión de cada APM de los archivos /var/opt/fw.boot/modules/fwkern.confy /etc/ppk.boot/boot/modules/simkern.conf
8. Tenermigradas las políticas al Provider-1 antes de la ventana de mantenimiento.

Actividades durante la ventana:

1. Instalarla licencia correspondiente al P1 y al CMA a utilizar.
2. Obtenerla tabla de ruteo de los firewalls virtuales (Hay veces que al reiniciar loschasis estas se pierden esto es un bug del XOS).
3. Obtenerdel vap-group un backup mediante archive-vap-group.
4. Nuevamenteen el chasis del backup en cada apm relacionada con el vap-group, usaremos elcomando reset_gw y regresamos nuestro VSX Gateway a un estado inicial, con estoperderemos comunicación con el SMART Center.
5. Entramosa nuestro Provider-1 dentro de la CMA creada para contener a esta consolausando el comando mdsenv .
6. Cerramostodas las instancias de SMART Dashboard.
7. Usamosla herramienta vsx_util reconfigure, para re configurar las apms.
8. Llenamoslos datos usando la cuenta que administra esta consola por ejemplo un usuariofwadmin.
9. Unavez que nos pregunte lo siguiente: “EnterVSX gateway/member object name to reconfigure:"
10. Ponemosel nombre del objeto a configurar, en este caso lo podemos obtener en eldashboard en las propiedades del cluster.
11. 
12. Enmi caso el objeto referenciando al clúster de VSX es el siguiente:FW-VSX_Test_fw1.
13. Unavez que obtenemos un mensaje como este podemos reiniciar la apm mediante elcomando reboot o usando el comando “reload vap-group ”.
14. 
15. Sipor algún motivo no funciono el reconfigure, pues tendrás que hacertroubleshooting o hablar a Checkpoint, en mi caso con el troubleshooting fuesuficiente.
16. Unavez que el vap-group vaya a Active usando, observamos a este vap-group medianteel comando “show ap-vap-mapping.
17. Entramosa nuestra nueva consola mediante el dashboard en modo escritura y en cadaobjeto relacionado al cluster de VSX presionamos el botón de OK, para que lasconfiguraciones del VFW, sean enviadas a las instancias de VSX correspondiente.
18. 
19. 
20. Removemoslas viejas licencias debido a que nuestra CMA cuenta con una dirección ipdiferente al SMART Center Server.
21. Instalamoslas nuevas licencias regeneradas con la nueva ip.
22. Generamosnuevamente nuestro archivo local.arp por cada instancia de firewall virtual, sies que usamos este archivo.
23. Unavez hecho esto podemos instalar políticas en nuestros firewalls virtualesusando la consola de P1, no olvidemos deshabilitar la siguiente opción.
24. 
25. Despuesde la instalación, verificamos que las rutas sigan igual en cada contexto, solopor si acaso si algo cambio es necesario hacer troubleshooting por el bugcomentado arriba.
26. Verificarque el arp se esté propagando mediante “fw ctl –vs vsid arp”.
27. Unpunto muy importante es verificar que los archivos /var/opt/fw.boot/modules/fwkern.conf y /etc/ppk.boot/boot/modules/simkern.conf,tengan el mismo contenido que antes de hacer la ventana, si no es así esnecesario ajustarlos y reiniciar nuevamente el vap-group.
28. Switcheamosel tráfico a este chasis administrado por el equipo P1 mediante un “vrrp-relinquish-master”,si queremos que este comando funcione correctamente es necesario tener elchasis 100% saludable en la configuración de VRRP.
29. Usandoel SMART View tracker verificamos que el tráfico nuevo fluya sobre este chasis.
30. Realizamosel mismo set de operaciones en el otro equipo.

Migrar R65 con VSX a Provider-1 R71

Bueno, este fin de semana me toco la tarea de importar unas políticas de Checkpoint en un SMART Center Server, migrarlas a un esquema de Provider-1, les cuento mis experiencias:

1. La consola original que contenía las políticas estaba en R65 con el plugin de VSX.
2. Este set de políticas iban destinadas a un Provider-1, corriendo R71.40.
3. Importe las políticas  a una VM corriendo R65 HFA 70 y después hice el upgrade a R70. mediante ISO.
4. Esta misma VM la subí nuevamente de R70 a R71.10. y exporte las políticas.

Después de este paso es cuando empezaron los inconvenientes al importar la configuración a P1, ya que siempre aparecía el siguiente error.

Un poco confundido me di cuenta que tenía que crear un archivo en raíz de la siguiente manera antes de exportar los upgrade_export:

touch /AllowVsxMigration

Una vez que parecía que todo iba a funcionar, nuevamente me mandaba un error, ya saben cómo es a veces checkpoint. El cual enviaba el siguiente error.

Revisando los logs el problema parecía ser relacionado a que no encontraba el plugin de vsx, por lo cual me puse a investigar eso. Esto fue mi error realmente ya que lo único que tenía que hacer era descargar los migration_tools para la versión de R71.40 y realizar un upgrade_export usando estas herramientas, después de esto el lab empezó a funcionar.

Bueno como recomendación si van a migrar a versiones mas recientes de Checkpoint siempre usen los migration_tools y lean el release notes de la versión que será el target para la migración.