Default Rule NDP – VMware NSX.

Siguiendo con las pruebas de IPv6 en NSX, he notado que una vez tenemos el Manager corriendo y al menos un Controller, si vamos a Firewall -> General, tenemos tres reglas creadas por defecto. En mi caso me ha llamado la atención una llamada Default Rule NDP la cual tiene un Action = Allow.

 

 

Primero, que es NDP?

Es un protocolo usado en IPv6, este opera en el Network Layer (Capa 3 del modelo OSI). Una de las tareas importantes es que este protocolo es el encargado de encontrar (descubrir) otros nodos en el mismo segmento (link).

A mi entender esta es la razón del porque esta regla está en la parte de General cuando entramos a Firewall, la primera prueba que hice fue cambiar el Allow por Block y automáticamente la VM en el cluster que está preparado para NSX y al cual esta política le aplica dejo de alcanzar TODOS los demás host en el mismo link layer. Por ejemplo, si quisiera hacer lo mismo en IPv4 dentro de NSX tendría que crear una regla en la parte de Ethernet tal vez usando la MAC de la VM que no quiero que genere tráfico a ningún otro hosts.

Personalmente pienso que esto no debería ser una política creada por defecto y más bien una opción habilitada en el mismo servicio de Firewall, se puede dar el caso que por equivocación se coloque una regla que interfiera con la comunicación NDP más arriba de esta por defecto y automáticamente tendremos un mal día.

Capturando paquetes en ESXi para diagnosticar errores en flowAnalyzer.

He estado investigando por qué cuando se envían datos IPFIX desde un vDS en vSphere el proceso que supone que recibe estos paquetes simplemente muere y reinicia sus operaciones, nada de la información enviada por el vDS se registra en los Index de Kibana.

Sometí un ticket al desarrollador de flowAnalyzer y quien a su vez me solicito un PCAP de los datos generados, en Linux esto se consigue con tcpdump, en Windows con Wireshark pero en ESXi ¿?

Que tenemos a disposición en ESXi para crear un PCAP?

Tenemos pktcap-uw!

https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2051814

Entonces, para capturar este tráfico habilite IPFIX (NetFlow) nuevamente en sus respectivos lugares y luego ejecute:

pktcap-uw –uplink vmnic2 -o /vmfs/volumes/ADAPTEC-232GB-JBOD/vmnic2.pcap

nota: actualmente el ESXi donde estoy generando las pruebas tiene un vDS con dos uplink a diferentes Switches, uno de los swtiches está apagado y por esto solo estoy capturando datos en el vmnic2.

Esta es la configuración de IPFIX (NetFlow):

Aquí una captura de pktcap capturando tráfico:

Esperemos que la causa del problema este entre los paquetes capturados!

Enviando flow data desde vSphere vDS a flowAnalyzer.

Desde el punto de vista de los equipos de red físico estamos corriendo un PROBE y enviando esa información al COLLECTOR. Ahora le toca al ambiente virtual!

vSphere vDS (Distributed Switch) soporta la funcionalidad de NetFlow. Habilitando esta opción en nuestros vDS podremos ver información de red que posiblemente no paso por el PROBE que corre en el inter-vlan router o el router de borde. Por ejemplo, tráfico de una VM en 10.0.0.0/24 a otra VM en el mismo rango de red no llegara a los routers y por esto no lo veremos en en flowAnalyzer.

Así habilitamos Netflow en el vDS:

  1. habilitamos la funcionalidad en el vDS:

 

  1. habilitamos en cuales PortGroup queremos capturar trafico:

 

Inicialmente configure el probe para NetFlow 9, en la versión 5.1 en adelante soporta IPFIX. asi que cambie el puerto y pude ver el trafico llegando al colector.

Lamentablemente, el PROBE en vDS envía datos que el template en el colector no los tiene y esto hace que el proceso muera y reinicie, esto quiere decir que la información no llega al index de Kibana.

 

Investigare como puedo agregar los valores para inciar el proceso nuevamente. stay tunned!

NSX Controller – Instalación falla usando solo IPv6.

Siguiendo con la agenda de usar IPv6 en un entorno NSX, intente desplegar un controlador solo asignando dirección IPv6 al pool designado para este, lamentablemente el despliegue fallo y mis sospechas apuntan a que el Controller no pudo alcanzar el Manager en la dirección IPv6 asignada.

Al intentar desplegar nuevamente el Controller, esta vez usando una dirección IPv4 todo término como de esperarse.

Tendré que investigar más sobre el tema para determinar si es una limitante o fue un error en mi configuración.