Alto uso de CPU por disco duro en Imperva

Hola a todos, bueno este sencillo documento nos ayudara a tener en cuenta algunos factores que hay que revisar si nuestro deployment con imperva si tiene una alta utilización de CPU.

Nuevamente las condiciones de esta instalación son las siguientes:

1. La instalación de imperva se encuentra sobre un chassis Crossbeam corriendo XOS 9.5.2.
2. La versión de nuestro imperva es la SecureSphere Gateway 8.0.0.
3. Solo funciona en modo pasivo(sniffing).
4. No se realiza ninguna operación de bloqueo en el tráfico.
5. No se hace ninguna serialización de trafico en el chasis de crossbeam.

Muchas veces nos enfocamos en ver los procesos y sus consumos de cpu usando la herramienta top, pero descuidamos varias métricas, como que imperva hace un uso intensivo del disco duro en operaciones de Lectura y Escritura, las cuales también consumen procesamiento.

Si este es el caso, el diagnostico es muy sencillo, primero que nada tenemos que verificar que tanto esta escribiendo y leyendo de nuestro disco duro, con un comando simple.

Por ejemplo:

imperva_1 (FW-LAB-HD): ~# iostat -d -x 5 3

Ahora bien veamos un poco la imagen, en lo que nos tendremos que fijar es en la columna de %util, la cual indica el porcentaje de procesamiento que nos están consumiendo las operaciones de Lectura y Escritura.

Ahora veamos las operaciones de r/s, tenemos un alto número de operaciones de lectura, para ser más precisos 42.78 operaciones por segundo.

Ahora bien ya que hemos encontrado que las operaciones a Disco Duro están consumiendo una parte importante de nuestro procesador,  la mejor manera que he visto para evitar este uso intensivo es hacer un tunning en imperva, de los eventos mas repetitivos que puedan ser descartados y no escritos en el disco duro.

Si realmente este problema de disco duro se presenta en tu ambiente, lo mejor es validar de lo que auditas que realmente es importante o abrir un ticket de soporte con imperva y que te ayuden a definir como bajar el uso de procesador que usa el disco duro.

How to migrate SMART Center Server running vsx to Provider-1

Hello everyone, due a new project related with a migration between a SMART Center to P1 and i haven't found any good info. I had to create a lab to recreate this environment.

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:

1. Two Crossbeam Chassis running XOS 9.5.2
2. A vsx cluster running in four apms using VSX R65 hfa20.
3. The two chassis running in VRRP.
4. 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:

1. Obtain a photo from the affected chassis using "show tech-support".
2. Obtain a license backup installed in the environment using SMART Update.
3. Obtain a cpinfo from all the virtual firewall just in case if we have to open a case with checkpoint.
4. Have a backup from the latest firewalls policies.
5. Verify that all the licenses related with the P1 are correct.
6. Obtain the latest local.arp file.
7. Obtain the latest version for the /var/opt/fw.boot/modules/fwkern.conf and /etc/ppk.boot/boot/modules/simkern.conf files.
8. Have migrated all the firewalls policies to P1.

Activities during the cutover:

1. Installs the corresponding license to the P1 and the CMA.
2. Obtain the routing table for every virtual firewall (sometimes after a chassis reboot these routes gets lost is a bug related with the XOS).
3. Obtain a backup for the vap-group related to the vsx.
4. 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.
5. Using our P1 we have to take the necessary context related with our CMA using mdsenv
6. We need to close all the dashboard instances to avoid any problem during the reconfiguration.
7. Using vsx_util we have to reconfigure every apm related with the cluster.
8. 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:"
9. 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.
10. 
11. In this case the name of the object was: FW-VSX_Test_fw1.
12. Once obtained a message similar to this, we have to reboot every apm affected using the command reboot or "reload vap-group "
13. 
14. 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.
15. Once the vap-group goes to active. We can observe it using “show ap-vap-mapping”.
16. 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.
17. 
18. 
19. After this step is necessary remove the old licenses related with this vsx cluster using the SMART update in Provider-1
20. After remove the old licenses we can continue adding the new licenses files.
21. 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.
22. We can proceed to install the rulebase in every virtual instance, don't forget remove the option "for gateway cluster..."
23. 
24. 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.
25. Verify that arp entries in the local.arp file are working using fw ctl -vs vsid arp
26. 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.
27. After all of this we can switch the traffic to this box using vrrp-relinquish-master.
28. Using smartview tracker we can verify that the traffic is flowing.
29. We can continue following all of this steps for the other chassis.

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.