Troubleshooting comunicación entre NSX Controllers y Hosts ESXi
Hola, recientemente realicé un soporte en un cliente, en el que se tenían problemas de comunicación de los hosts ESXi y los controladores de NSX-V. Este ambiente en particular consta de NSX-V versión 6.4.6 y vSphere 6.7U3 y una arquitectura universal entre dos sitios. En donde se tienen dos NSX-V conectados entre si, teniendo como NSX primario al sitio A y como NSX secundario al sitio B.
El evento de desconexión del canal de comunicación del VTEP se da en el sitio B contra el NSX primario, es decir la comunicación de los hosts ESXi del sitio B con el Universal Control Cluster (UCC) del sitio A, el mismo que se ubica en el NSX primario.
Como se indica en la imagen, los hosts perdieron la comunicación con el UCC (controllers) de NSX del sitio A, alertados por el canal de comunicación en DOWN y Connection Refused
Inicialmente, todo indica que se trata de un problema de comunicación de red, pero la comunicación del NSX primario con el NSX secundario está intacta y no presenta problemas de conectividad, por lo tanto, descartamos la conectividad WAN entre ambos sitios.
Causa
Para identificar de mejor manera, ingresamos al host mediante SSH y verificamos los planos de control y de gestión que usa NSX para que el host haga las comunicaciones con el UCC.
Primero chequeamos que el servicio vSphield-Stateful-Firewall esta corriendo en el host, este servicio o cliente de bus de mensajes es usado por netcpa, ESGs y las VMs del control de DLR para comunicarse con NSX manager.
Ya que el servicio obtiene las direcciones IPs del NSX manager a través del vCenter Server y los servicios vpxa/hostd validamos si las direcciones IP de los Controladores NSX están correctas. Para esto NSX Manager envía archivos de configuración cuando hace la preparación de los hosts, esta información está en el archivo config-by-vsm.xml ubicado en la ruta etc/vmware/netcpad
La información que nos muestra nos indica las direcciones IP de los controladores que el host ESXi debe conectarse para el canal de comunicación de un DLR, a parte de información importante como el ID local que es usado para los "local egress". Lo cual nos indica que las configuraciones están correctas.
Continuando con la revisión, podemos validar el Panel del control del Host mediante el agente netcpad, con lo cual nos aseguramos que la comunicación con los controladores usando el archivo de configuración esta funcionando.
Ahora, validamos que el puerto 1234 que es usado para la conexión TCP entre el agente netcpad y los controladores este abierto. La validación se la realiza corriendo el comando
esxcli network ip connection list |grep 1234
Y de acuerdo a los resultados, podemos decir que existe un bloqueo en el handshake del protocolo TCP usando el puerto 1234. El estado SYN_SENT significa que el host envía una trama de sincronización SYN para establecer la conexión pero nunca llega o tiene respuesta. Cuando la trama se envía y se establece la conectividad TCP se tiene un estado de ESTABLISHED.
Solución
La solución es sencilla una vez identificando la causa de la pérdida de conectividad, al tener un enlace capa 3, es decir que se tiene un firewall de por medio, podemos realizar la apertura del puerto 1234 que esta bloqueado entre las redes de los controladores NSX del sitio A y la redes de los hosts / VTEPs del sitio B.
Abriendo el puerto 1234 podemos establecer la conectividad.
Así se pudo establecer la conectividad entre los hosts y los controladores, existen otros pasos de troubleshooting que podemos seguir aquí.
Finalmente, entendemos que existen varios componentes del plano de control de NSX manager que gestionan o realizan los canales de comunicación que debemos validar y buscar la causa raíz del problema. Entendiendo la arquitectura de la infraestructura y siguiendo los pasos por cada uno de los componentes hasta llegar al problema podemos solucionar los eventos presentados.
Tags: NSX , NSX-V, troubleshooting, Controllers, controlplane, NSXManager, VTEPs