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.

Agregando un APC ATS AP7750 al Homelab.

A mis manos acaba de llegar un AP7750 (Gracias ebay) esta cosa pesa más de 10 libras!

Desde hace tiempo buscaba un equipo APC tipo PDU, bueno en realidad buscaba un PDU con puerto de monitoreo donde pudiera ver Amps o Watts consumidos. El ATS hace gran parte de lo que necesito y otras que no necesitaba.

Output Current: 4.0 Amps …. ouch!

 

Lo primero que he intentado es sacar métricas de este vejestorio. Lamentablemente estamos hablando de un equipo con más de 10 años de fabricación y que ya APC ha declarado EOL, en el área de SNMP solo soporta v1 y no sé si esta es la razón por la cual no me está mostrando los Amps en LibreNMS.

Lo interesante es que si hago un snmpwalk encuentro el OID con el valor de Amps consumidos, seguiré investigando ya que necesito saber el consumo en Amps que esta cosa llamada Homelab está usando.

Aquí una captura de la información generada en LibreNMS la cual no es muy útil aun.

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!