En la parte 10 vimos como configurar NAT. Esta parte 11 veremos la herramienta Traceflow incluida en NSX-T. Esta parte será la ultima de esta serie, en algún momento había que cerrarla, no quiere decir que dejemos de hablar de NSX-T no os preocupéis 🙂
Pues vamos al lio, Traceflow nos ayuda a inspeccionar la ruta de un paquete que viaja desde un puerto lógico a uno o varios puertos lógicos, la app que aloja la VM jamás vera el trafico de Traceflow.
Traceflow solo esta soportado en la capa Overlay.
En el apartado «Plan & Troubleshoot» en contraremos Traceflow.


Como podemos ver, podemos elegir el tipo de trafico a examinar (Unicast/Broadcast/Multicast).

El protocolo.

En el source podemos elegir VM o Port/Interface.

Si elegimos Port/Interface, podemos elegir a que esta enganchado.

En este ejemplo elegimos VIF y veremos todos los puertos de nuestras VM del laboratorio.

Mediante la selección de puertos vamos a comprobar el ICMP entre nuestra VM de APP y nuestra VM de WEB.

Traceflow nos mostrara el recorrido de ese paquete ICMP desde el origen al destino con todos los elementos que entran en juego.

Si pinchamos en cada objeto nos mostrara su info, por ejemplo el ESXi origen.

VM origen.

Segmento origen.

T1 que se encarga de conmutar entre el segmento APP y WEB.

Y lo mismo con los elementos destino.
Nos mostrara un resumen de cual ha sido el flujo, se inyecta en el ESXi 5, se checkea el distributed firewall del host para ver si puede o no salir, como esta permitido se reenvía al segmento APP de ahí pasa al T1 para ser enviado al segmento WEB, se reenvía de forma física por los TEP desde el ESXi 5 al 4 se comprueba el distributed firewall en ESXi 4 y al estar permitido llega a la VM destino.


Veamos un caso de trafico no permitido, una VM WEB intentando tráfico SMTP a una VM DB.

Vemos que el tráfico se dropea al hacer match con una regla del distributed firewall del ESXi 4 que en este caso es el origen.

Si recordamos en la parte 7 creamos las reglas necesarias para que desde WEB a DB solo se permitiera el ssh, con lo que nuestra prueba a macheado con la regla 2027 que hace un deny de todo el trafico de WEB a DB y solo se permite el ssh en la regla 2028.

Y hasta aquí la pequeña demostración de lo que podemos hacer con Traceflow, me parece una herramienta muy interesante para troubleshooting en NSX-T, obviamente no tiene la potencia de vRealize Network Insight pero la tenemos disponible sin mas en NSX-T.
Con este post vamos a cerrar esta serie, espero de verdad que os halla sido útil y podamos haber aportado algo con ella. Gracias por leernos.
Comparte si te gusta 🙂