🌬️ 🥌 🚱 VXLAN en NSX-V - Base subyacente con problemas 🖋️ ♒️ 💍

Saludos, y primero una pequeña letra. A veces envidio a los colegas que trabajan de forma remota: es genial poder trabajar desde cualquier parte del mundo conectado a Internet, vacaciones en cualquier momento, responsabilidad por proyectos y plazos, y no estar en la oficina de 8 a 17. Mi posición y responsabilidades laborales prácticamente excluyen La posibilidad de una larga ausencia en el centro de datos. Sin embargo, ocasionalmente ocurren casos interesantes como el que se describe a continuación, y entiendo que hay pocas posiciones en las que exista tal margen para la expresión creativa de un solucionador de problemas interno.

Un pequeño descargo de responsabilidad: en el momento de escribir este artículo, el caso no se ha resuelto por completo, pero dada la rapidez de la respuesta de los proveedores, la solución completa puede tomar otros meses, y quiero compartir mis hallazgos en este momento. Espero, queridos lectores, me perdonen esta prisa. Pero suficiente agua, ¿qué pasa con el caso?

Primera introducción: hay una empresa (donde trabajo como ingeniero de redes) que aloja soluciones de cliente en la nube privada de VMWare. La mayoría de las nuevas soluciones se conectan a los segmentos de VXLAN que están controlados por NSX-V; en resumen, no evaluaré cuánto tiempo me dio esta solución. Incluso logré capacitar a mis colegas para configurar NSX ESG y se implementaron soluciones para clientes pequeños sin mi participación. Una nota importante es el plano de control con replicación unicast. Los hipervisores están conectados de forma redundante mediante dos interfaces a diferentes conmutadores físicos Juniper QFX5100 (ensamblados en el chasis virtual) y la ruta de la política de temporización basada en el puerto virtual de origen es completa.

Las soluciones de cliente son muy heterogéneas: desde Windows IIS, donde todos los componentes del servidor web se instalan en una máquina hasta los bastante grandes, por ejemplo, frentes web Apache con equilibrio de carga + LB MariaDB en Galera + globos de servidor sincronizados con GlusterFS. Casi todos los servidores deben ser monitoreados por separado, y no todos los componentes tienen direcciones públicas; si ha encontrado este problema y tiene una solución más elegante, con gusto lo asesoraré.
Mi solución de monitoreo consiste en "conectar" el firewall (Fortigate) a cada red interna del cliente (+ SNAT y, por supuesto, restricciones estrictas sobre el tipo de tráfico permitido) y monitorear las direcciones internas, de esta manera se logra una cierta unificación y simplificación del monitoreo. El monitoreo en sí proviene de un grupo de servidores PRTG. El esquema de monitoreo es algo como esto:

imagen

Si bien operamos solo con VLAN, todo era bastante habitual y predeciblemente funcionaba como un reloj. Después de la implementación, NSX-V y VXLAN se enfrentaron a la pregunta: ¿es posible continuar monitoreando a la antigua usanza? En el momento de esta pregunta, la solución más rápida era implementar el NSX ESG y conectar la interfaz troncal VXLAN a la red VTEP. Rápido entre comillas: dado que el uso de la GUI para configurar redes de clientes, las reglas de SNAT y firewall pueden y unifican la administración en una única interfaz de vSphere, pero en mi opinión es bastante engorroso y, entre otras cosas, limita el conjunto de herramientas para la resolución de problemas. Los que usaron el NSX ESG como un sustituto de un firewall "real", creo, estarían de acuerdo. Aunque, probablemente, tal solución sería más estable, después de todo, todo sucede en el marco de un proveedor.

Otra solución es usar NSX DLR en modo puente entre VLAN y VXLAN. Aquí, creo que todo está claro, la ventaja de usar VXLAN es cursi, porque en este caso, aún debe tirar de la VLAN a la instalación de monitoreo. Por cierto, en el proceso de resolver esta solución, me encontré con un problema cuando el puente DLR no envió paquetes a la máquina virtual con la que estaba en el mismo host. Lo sé, lo sé: en los libros y guías sobre NSX-V se dice explícitamente que se debe asignar un clúster separado para NSX Edge, pero esto está en los libros ... De todos modos, después de un par de meses con soporte no resolvimos el problema. En principio, entendí la lógica de la acción: el módulo principal del hipervisor responsable de la encapsulación de VXLAN no se activó si DLR y el servidor monitoreado estaban en el mismo host, ya que el tráfico no abandona el host y, lógicamente, debería estar conectado al segmento de VXLAN; la encapsulación no es necesaria.Con soporte, nos instalamos en la interfaz virtual vdrPort, que combina lógicamente enlaces ascendentes y también realiza puentes / encapsulamiento; allí se notó una falta de coincidencia en el tráfico entrante, lo que decidí resolver en el caso actual. Pero como se dijo, no terminé este caso hasta el final, ya que fue transferido a otro proyecto y la sucursal estaba inicialmente en un callejón sin salida y no había ningún deseo particular de desarrollarlo. Si no me equivoco, el problema se observó en las versiones NSX y 6.1.4 y 6.2.dado que fue transferido a otro proyecto y la sucursal estaba inicialmente en un callejón sin salida y no había un deseo particular de desarrollarlo. Si no me equivoco, el problema se observó en las versiones NSX y 6.1.4 y 6.2.dado que fue transferido a otro proyecto y la sucursal estaba inicialmente en un callejón sin salida y no había un deseo particular de desarrollarlo. Si no me equivoco, el problema se observó en las versiones NSX y 6.1.4 y 6.2.

Y aquí, ¡bingo! Fortinet annonsiruet soporte nativo VXLAN . Y no solo punto a punto o VXLAN-over-IPSec, no un puente VLAN-VXLAN basado en software, comenzaron a implementar todo esto desde la versión 5.4 (y es presentado por otros proveedores)), pero soporte real para el plano de control de unidifusión. Al implementar la solución, me encontré con otro problema: los servidores revisados periódicamente "desaparecían" o aparecían en el monitoreo, aunque la máquina virtual en sí misma todavía estaba viva. Resultó que olvidé habilitar Ping en la interfaz VXLAN. En el proceso de reequilibrar los clústeres, las máquinas virtuales se movieron y vMotion terminó con Ping para indicar el nuevo host ESXI al que se movió la máquina. Mi estupidez, pero este problema una vez más minó la credibilidad del apoyo se produjo, en este caso Fortinet. No digo que todos los casos relacionados con VXLAN comiencen con la pregunta "¿dónde está el conmutador de software VLAN-VXLAN en su configuración?" Esta vez me aconsejaron cambiar la MTU, esto es para Ping, que es de 32 bytes. Luego "juegue" con tcp-send-mss y tcp-reciben-mss en la política - para VXLAN,que está encapsulado en UDP. Fuf, lo siento, está hirviendo. En general, resolví este problema por mi cuenta.

Después de revertir con éxito el tráfico de prueba, se decidió implementar esta solución. Y en la producción resultó que después de un día o dos, todo lo que se monitorea a través de VXLAN se cae gradualmente por completo. La desactivación / activación de la interfaz ayudó, pero solo temporalmente. Consciente de la desaceleración del soporte, comencé a resolver problemas por mi parte; al final, mi empresa, mi red es mi responsabilidad.

Debajo del spoiler está el curso de la resolución de problemas. ¿Quién está cansado de las letras y la jactancia? Salte y vaya al postanálisis.

Solución de problemas

, — !

, , . . , Fortigate 5.6+, «diagnose debug flow» — . . , , RFC1918, . VXLAN ...15, ...254, VTEP.

VXLAN- . overlay ARP OVSDB, underlay ARP CAM. Fortigate VXLAN FDB OVSDB. :

 fortigate (root) #diag sys vxlan fdb list vxlan-LS
mac=00:50:56:8f:3f:5a state=0x0002 flags=0x00 remote_ip=...47 port=4789 vni=5008 ifindex=7

— MAC VTEP ...47. ESXI , , MAC , VTEP . CAM/ARP — ESXI :

fortigate (root) #get sys arp | grep ...47
...47 0 00:50:56:65:f6:2c dmz

— ? Juniper' — , — VLAN VTEP . DLR-, VDR — ESXI , VMWare. MAC «97:6e» , vmnic1 — , VTEP ...47 "--dir 2":

pktcap-uw --uplink vmnic1 --vni 5008  --mac 90:6c:ac:a9:97:6e --dir 2 -o /tmp/monitor.pcap

— ARP . ARP . , ...15 — ICMP ? , . , ( teaming policy), vNIC , , :

pktcap-uw --uplink vmnic4 --vni 5008  --mac 90:6c:ac:a9:97:6e --dir 2 -o /tmp/monitor.pcap

, . . — — VDR, . , , , . «» Ethernet underlay. - MAC VTEP IP. , , — , . ARP , . Ethernet :

fortigate (root) #get sys arp | grep ...47
...47 0 00:50:56:65:f6:2c dmz
fortigate (root) #get sys arp | grep ...42
...42 0 00:50:56:6a:78:86 dmz

Entonces, ¿qué tenemos al final? Después de la migración de la máquina virtual, el fortigate intenta enviar tráfico a VTEP desde el VXLAN FDB (correcto), pero usa el MAC DST incorrecto y se espera que el tráfico sea eliminado por la interfaz del hipervisor receptor. Además, en uno de cada cuatro casos, este MAC pertenecía al hipervisor original, desde el cual comenzó la migración de la máquina.

Ayer recibí una carta del soporte técnico de Fortinet; en mi caso, abrieron el error 615586. No sé cómo alegrarme o llorar: por un lado, el problema no está en la configuración, por otro, la solución vendrá solo con la actualización del firmware, en el mejor de los casos, el siguiente. Las preguntas frecuentes también calientan otro error que descubrí el mes pasado, aunque en ese momento en la interfaz gráfica de usuario de HTML5 vSphere. Bueno, el departamento de control de calidad local de los proveedores es directo ...

Me aventuraré a sugerir lo siguiente:

1: el plano de control de multidifusión probablemente no se verá afectado por el problema descrito; después de todo, las direcciones MAC de VTEP se obtienen de la dirección IP del grupo al que está suscrita la interfaz.

2 - muy probablemente el problema de fortics en las sesiones de descarga en el procesador de red (aproximadamente análogo a CEF) - si cada paquete se pasa a través de la CPU, se usarán tablas que contengan la información correcta, al menos visualmente. A favor de esta suposición es lo que ayuda a cerrar / abrir la interfaz o esperar un tiempo, más de 5 minutos.

3: cambiar la política de formación de equipos, por ejemplo, a una conmutación por error explícita o introducir el LAG no resolverá el problema, ya que se observó el MAC atascado en el hipervisor original en paquetes encapsulados.

A la luz de esto, puedo compartir lo que descubrí recientemente en un blog.donde en uno de los artículos se afirmaba que los firewalls y los métodos de transferencia de datos almacenados en caché son muletas. Bueno, no tengo tanta experiencia en TI como para decir lo mismo, y no estoy de acuerdo con todas las declaraciones de los artículos del blog de inmediato. Sin embargo, algo me dice que hay algo de verdad en las palabras de Ivan.

¡Gracias por su atención! Estaré encantado de responder preguntas y escuchar críticas constructivas.

VXLAN en NSX-V - Base subyacente con problemas

More articles: