Exportar reglas del Firewall Distribuido de NSX-T con vRNI

Muchas veces bien sea desde el lado de implementación o desde la operación, nos encontramos con el problema de no poder exportar las reglas del Firewall Distribuido de NSX-T en las versiones 3.0 y anteriores. Esta característica ha sido recientemente adicionada a la versión 3.1 (ver aquí), de manera que si tenemos una version anterior nos vemos obligados a recurrir a APIs para poder extraer la configuración de estas políticas y reglas.

Por suerte, por lo general cuando hablamos de Micro-Segmentación casi siempre tenemos a la mano la herramienta vRealize Network Insight con lo cual esta tarea se resume a una consulta y a un export.

PROCEDIMIENTO

En la caja de búsqueda de vRNI realice la siguiente consulta: NSX-T Firewall rule

En el filtro NSX Manager, seleccione el NSX Manager de interés. Si solo tiene un NSX Manager conectado a vRNI omita el paso.

clip_image001

Haga clic en More Option y después clic en Export as CSV.

clip_image002

Clic en Clear All para eliminar todas las propiedades y poder ajustar las que son de nuestro interés.

clip_image003

Clic en ADD PROPERTIES y agregue las siguientes propiedades:

Nota: Puede utilizar el buscador para encontrar las propiedades rapidamente.

  • Section Name
  • Rule ID
  • Configure Source
  • Configure Destination
  • Service
  • Port Range Display
  • Applied to
  • Action
  • Direction
clip_image004

Activamos el check Save changes to: Create a new template, para crea una plantilla con las nueve (9) propiedades seleccionadas.

Por ultimo, en el campo Name asignamos un nombre a la plantilla y hacemos clic en EXPORT.

Seleccionamos el destino y nombre para el archivo .csv y clic en Save.

clip_image005

La próxima vez que desee exportar nuevamente las reglas únicamente tendrá que seleccionar en Property Template la plantilla guardada y automáticamente se cargaran las propiedades asociadas.

clip_image006

Una vez hemos exportado la información simplemente lo importamos en Excel para poder visualizarla como filas y columnas

clip_image007
clip_image008
clip_image009

(Opcional) Una vez la tenemos en este formato, recomiendo crear una tabla dinámica para organizar mejor la información de forma similar a como la vemos en el Firewall Distribuido.

Para esto, active el Diseño de tabla dinámica clásica antes de seleccionar la información de las columnas.

clip_image010

Organice las filas en el siguiente orden y seleccione la opción No mostrar subtotales en el diseño de la tabla dinámica

  • Section Name
  • Rule ID
  • Configure Source
  • Configure Destination
  • Service
  • Port Range Display
  • Applied to
  • Action
  • Direction
clip_image011

Por ultimo, utilice la función buscar y remplazar para eliminar la palabra “default.” que antepone cada security group en la información exportada. De esta manera podrá visualizar mejor la información presentada.

clip_image012

Identificar el líder en un cluster de NSX-T Manager 3.x

Antes de explicar el sencillo procedimiento para identificar el líder en un clúster, recordemos que un clúster esta formado por un grupo de tres nodos NSX Manager para alta disponibilidad y escalabilidad y que cada NSX Manager appliance tiene incluido los roles de Policy, Manager y Controller.

Podemos construir un clúster de NSX-T Manager de las siguientes dos maneras.

NSX Management Cluster con Dirección IP Virtual

El NSX Management cluster garantiza la alta disponibilidad y es configurado de la siguiente forma:

  • Todos los manager deben estar en la misma subnet.
  • Un nodo Manager es elegido como líder.
  • La IP Virtual del Cluster es unida al manager líder.
  • El trafico NO es balanceado a través de los Managers mientras usa VIP.
  • La IP Virtual del cluster es usada para el trafico destinado a los nodos NSX Manager.
  • El trafico destinado a cualquier Nodo de Transporte usa la IP de management del nodo.
  • Una única dirección IP virtual es usada por los clientes de acceso API y GUI.
image

Cuando se envía una solicitud de usuario a la dirección IP virtual, el manager activo (el líder que tiene la dirección IP virtual adjunta) responde a la solicitud. Si el líder falla los dos managers restantes eligen un nuevo líder y este responderá a las solicitudes enviadas a esa dirección IP virtual.

Las solicitudes de equilibrio de carga y el tráfico no se equilibran entre los administradores mientras se usa VIP.

Si el nodo líder que posee VIP falla, se elige un nuevo líder que envía una solicitud GARP para tomar posesión de la VIP y entonces el nuevo nodo líder recibe todas las nuevas solicitudes de API y UI de los usuarios.

NSX Management Cluster con Load Balancer

Para este caso, un balanceador de carga es el encargado de proveer alta disponibilidad al cluster:

  • Todos los nodos son activos.
  • GUI y API son disponibles en todos los managers.
  • El trafico a la IP Virtual es balanceado a múltiples nodos manager.
  • Los nodos manager pueden estar en diferente subnet.
image

Una vez explicado lo anterior, podría surgir la pregunta -¿Para que querría saber quien es el líder? – pues bien, cuando tenemos un problema con la solución se hace indispensable saber cual de los nodos esta recibiendo las solicitudes de manera que podamos acceder a el a través de la linea de comandos para realizar el debido troubleshooting.

También es útil para la fase de pruebas post implementación (VMware verification workbook) en donde debemos testear la alta disponibilidad y garantizar el correcto funcionamiento del cluster.

PROCEDIMIENTO

1. Inicie sesión SSH hacia la IP Virtual del Cluster con el usuario admin y el password definido en la instalación . Sino tiene habilitado el servicio SSH puede hacer login desde la Consola de la VM en el vCenter.

2. Ejecute el comando get cluster status verbose y observaremos que para cada función del manager tenemos un líder seleccionado.

image

3. Ahora solo debemos buscar debajo de cada función del manager, el líder asociado para cada uno de los servicios de la misma.

En la siguiente grafica se muestra como líder del servicio api para la función HTTPS, al miembro con UUID terminado en 3d60144055b5 que corresponde al FQDN srvctrvmnsxp02.bivcloud.local.

image

Nota: Algunas funciones tendrán mas de un servicio, por lo que tendrán un líder asociado para cada uno.

image