Introducción
En este post vamos a revisar un caso práctico relacionado con L2VPN sobre una plataforma IaaS con VMware NSX.
El requerimiento era extender una red Layer 2 utilizando una solución L2VPN de terceros. Para funcionar correctamente, las VMs encargadas del túnel necesitaban permitir:
- Promiscuous Mode
- MAC Address Changes
- Forged Transmits
Cuando trabajamos con un portgroup tradicional podemos modificar estas políticas desde vSphere. Pero cuando la VM está conectada directamente a un segmento lógico de NSX, tenemos otra alternativa: aplicar estas opciones directamente sobre el DVPort de la VM desde ESXi Shell.
Vamos al procedimiento.
El escenario
La plataforma utiliza NSX para la segmentación lógica de las redes de organización.
La solución L2VPN de terceros necesitaba procesar tráfico con diferentes direcciones MAC, por lo que requería habilitar las políticas de seguridad Layer 2 mencionadas anteriormente.
La solución permitió levantar el túnel, pero durante las pruebas apareció un problema de red.
En los logs de ESXi se observó:
[vob.net.dvport.uplink.transition.down]
Uplink: vmnic3 is down.
0 uplinks up.
Failed criteria: 128Después del análisis se determinó que parte del tráfico estaba llegando nuevamente hacia la interfaz física del servidor, provocando un comportamiento de loop y afectando la conectividad de la NIC.
La solución implementada en ese momento fue aislar este tráfico mediante un portgroup específico. Además, las VMs involucradas debían mantenerse en el mismo host mediante reglas de afinidad.
En mi blog anterior te hablo más sobre este tema: https://tecno-experts.com/fransilvablog/vmware/troubleshooting-l2vpn-vmnic-flapping-y-failed-criteria-128-en-una-plataforma-iaas/
Pero existe otra situación que vale la pena revisar:
¿Qué hacemos si la VM está conectada directamente a un segmento lógico de NSX?
VM conectada a un segmento lógico de NSX
Broadcom documenta la posibilidad de modificar las políticas Layer 2 directamente sobre el DVPort correspondiente a una VM utilizando nsxdp-cli.
El procedimiento se realiza directamente sobre el host ESXi donde está ejecutándose la VM.
1. Identificar dónde está ejecutándose la VM
Desde vCenter identificamos el host ESXi donde se encuentra actualmente la VM.
Luego nos conectamos por SSH
2. Identificar el puerto de la VM
Ejecutamos:
nsxcli -c get portsLa salida mostrará información similar a:
PortNum Switch Client DVSPort
------- ------------ -------------- ------------------------------------
67108885 DvsPortset-0 VM-L2VPN.eth0 xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxxDebemos localizar nuestra VM.
Por ejemplo:
VM-L2VPN.eth0Y registrar principalmente:
DVSPort
DVSOtra opción documentada por Broadcom para identificar el puerto es:
net-stats -l | grep -i <NOMBRE_VM>Ejemplo:
net-stats -l | grep -i VM-L2VPN3. Revisar la configuración actual
Antes de cambiar cualquier parámetro debemos revisar cómo está configurado actualmente el puerto.
Ejecutamos:
nsxdp-cli vswitch l2sec get --dvport <DVPORT_UUID> -dvs <DVS_NAME>Por ejemplo:
nsxdp-cli vswitch l2sec get --dvport xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx -dvs NSX-VDSEn una configuración restrictiva podemos encontrar:
deny promiscuous
deny mac change
deny forged framesEste es nuestro precheck y también la referencia que utilizaremos en caso de necesitar rollback.
4. Habilitar las políticas requeridas
Para el escenario L2VPN de este caso necesitamos habilitar:
Promiscuous Mode
MAC Address Changes
Forged TransmitsEjecutamos:
nsxdp-cli vswitch l2sec set --dvport <DVPORT_UUID> -dvs <DVS_NAME> --mac-change --forge-src --promiscEjemplo:
nsxdp-cli vswitch l2sec set --dvport xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx -dvs NSX-VDS --mac-change --forge-src --promiscLos parámetros representan:
--promisc Promiscuous Mode
--mac-change MAC Address Changes
--forge-src Forged TransmitsSi la aplicación necesita únicamente una de estas opciones, no es obligatorio habilitar las tres.
Por ejemplo, únicamente Promiscuous Mode:
nsxdp-cli vswitch l2sec set --dvport <DVPORT_UUID> -dvs <DVS_NAME> --promisc5. Validar el cambio
Ejecutamos nuevamente:
nsxdp-cli vswitch l2sec get --dvport <DVPORT_UUID> -dvs <DVS_NAME>Para el escenario completo deberíamos visualizar:
allow promiscuous
allow mac change
allow forged framesCon esto podemos comenzar las pruebas de conectividad de la aplicación L2VPN.
6. Validar el puerto y el uplink
También podemos revisar cómo está conectado el puerto dentro del datapath de NSX:
nsxdp-cli vswitch instance listBuscamos nuestra VM:
Client PortID DVPortID MAC Uplink
VM-L2VPN.eth0 67108885 xxxxxxxx-... 00:50:56:xx:xx:xx vmnic1Importante: el cambio no es persistente
Este punto es crítico.
Broadcom indica que esta modificación realizada mediante nsxdp-cli sobre el puerto de la VM es no persistente.
Puede perderse después de:
vMotion
VM Power Cycle
Reinicio del host ESXiPor lo tanto, después de cualquiera de estos eventos debemos volver a validar:
nsxdp-cli vswitch l2sec get --dvport <DVPORT_UUID> -dvs <DVS_NAME>Si necesitamos una configuración permanente, debemos evaluar una configuración soportada desde NSX/vCenter o revisar el diseño de la solución.
¿Qué debemos tener en cuenta?
Habilitar Promiscuous Mode no debería convertirse en la solución automática para cualquier problema Layer 2.
Antes de aplicarlo debemos entender qué necesita realmente la aplicación.
En este caso concreto la solución L2VPN de terceros requería:
Promiscuous Mode
MAC Address Changes
Forged TransmitsPero cada aplicación puede tener requerimientos diferentes.
También debemos recordar que permitir estas políticas modifica la forma en que el switch virtual procesa las direcciones MAC y el tráfico recibido por la VM.
Por eso lo correcto es habilitarlas únicamente sobre el puerto que realmente las necesita.
Conclusión
Este caso deja algo bastante claro: cuando trabajamos con L2VPN, NSX y appliances de terceros, debemos entender exactamente cómo está circulando el tráfico Layer 2.
Si la VM está conectada directamente a un segmento lógico de NSX, podemos utilizar nsxdp-cli desde ESXi para modificar las políticas Layer 2 sobre su DVPort específico.
Eso sí: debemos considerar este procedimiento como un override no persistente y documentar cualquier dependencia relacionada con vMotion, reinicios o power cycles.
En networking virtual, muchas veces el problema no es simplemente que un paquete no llegue.
La clave está en entender por dónde está pasando.
Referencias
Broadcom KB 418915
Enabling Promiscuous Mode, MAC Address Change, Forged Transmits, and MAC Learning on a VM.
Broadcom KB 394260
Configuración de políticas de seguridad Layer 2 sobre puertos NSX mediante ESXi CLI.