Me enfrento a una situación muy extraña con algunas máquinas virtuales en mi configuración de vSphere y no puedo entender qué está pasando.
Originalmente, estoy trabajando con una 192.168.9.0/24red donde 192.168.9.254está el servidor DHCP, 192.168.9.43es la puerta de enlace, 192.168.9.82es mi estación de trabajo (recibió su IP del servidor DHCP) y 192.168.9.15es la de mi colega.
Esto funciona bien y cada máquina en esa red puede funcionar con las demás, todas son capaces de hacer ping entre sí y con el resto del mundo a través de la puerta de enlace.
Se instaló un clúster VSphere 6.5, con tres hosts que tienen direcciones estáticas y 192.168.9.1, respectivamente. Esas máquinas ejecutan ESXi versión 6.0.0, 3380124 y cada una tiene cuatro NIC conectadas a un par de conmutadores Dell N1524 apilados, dichos conmutadores están conectados a la red. En ese clúster, hay una red que está vinculada a cada NIC de host y, por lo tanto, las VM obtienen sus IP del DHCP. Esto también funciona bien, pero debido a que ha habido un aumento en el uso de VM, el rango de IP atendido por el servidor DHCP ahora está bastante saturado, hasta el punto de que algunos usuarios habituales no pueden obtener una dirección IP si llegan al tarde.192.168.9.2192.168.9.3192.168.9.0/24Production192.168.9.254
Para evitar esto, agregué un nuevo grupo de puertos en el vSwitch para cada host y les di a esos grupos de puertos el mismo nombre ( VLAN) y el mismo valor de VLAN, siendo 42.
Los conmutadores físicos de Dell se han reconfigurado para permitir esa VLAN junto con la predeterminada. uno en los puertos donde están conectadas las NIC de los hosts (modo troncal). Decidí que esta VLAN sería una 10.10.10.0/24red para que fuera fácilmente reconocible de la red normal y así le di al conmutador la 10.10.10.252IP estática en esa VLAN.
Luego, creé una máquina virtual de Windows 2012 que tiene dos interfaces, una en Production(192.168.9.110), otra en VLAN( 10.10.10.254) y activé la función RRAS para que esta máquina ahora actúe como puerta de enlace entre 10.10.10.0/24el resto del mundo y el resto del mundo.
Creé una segunda máquina virtual de Windows 2012 que solo tiene una interfaz, VLANcon la dirección estática 10.10.10.253y la nombré MDC. Activé los roles de Controlador de dominio, DHCP y DNS. DHCP ofrece arrendamientos en el 10.10.10.50 - 10.10.10.200rango, mientras que DNS simplemente reenvía al DNS desde la 192.168.9.0/24red.
Luego creé dos máquinas virtuales, una en el primer host, junto con MDC y Gateway, y otra en el tercer host, ambas conectadas a la VLANred. Como la conectividad parecía funcionar correctamente, decidí mover las máquinas virtuales existentes de la Temporarycarpeta a la VLANred, usando este comando PowerCLI:
Get-Folder Temporary | Get-VMs | Get-networkadapater | set-networkadapter -NetworkName VLAN
También aproveché para asegurarme de que todos los adaptadores de red estén vmxnet3con este comando.
Get-Folder Temporary | Get-VMs | Get-networkadapater | set-networkadapter -Type vmxnet3
Como la conectividad aún estaba bien, creé otro grupo de máquinas virtuales, también conectadas a la VLANred, ubicadas en los tres hosts, lo que da la siguiente topología:
Anfitrión 1
MDC ( 10.10.10.253)
Puerta de enlace ( 10.10.10.254– 192.168.9.110)
Máquina1_H1 ( 10.10.10.64)
Máquina2_H1 ( 10.10.10.57)
Anfitrión 2
Máquina3_H2 ( 10.10.10.65)
Anfitrión 3
Máquina4_H3 ( 10.10.10.50)
Máquina5_H3 ( 10.10.10.51)
Y aquí es donde estoy obteniendo resultados muy extraños en lo que respecta a la conectividad de red, tanto interna VLANcomo al conectarme al mundo exterior:
- MDC puede hacer ping a todos menos al conmutador (
10.10.10.252) - Gateway puede hacer ping a todos menos a Machine5_H3
- Machine1_H1 puede hacer ping a todos menos a Machine3_H2
- Machine2_H1 puede hacer ping a todos menos al interruptor (
10.10.10.252) - Machine3_H2 puede hacer ping a todos excepto al Host 1 y Machine1_H1
- Machine4_H3 puede hacer ping a todos excepto a
192.168.9.43,192.168.9.15ygoogle.fr(la resolución del nombre está bien) - Machine5_H3 puede hacer ping a todos excepto a
192.168.9.254(192.168.9.82mi propia estación de trabajo) y10.10.10.254 - Mi propia computadora (
192.168.9.82) puede hacer ping a todos menos a Machine5_H3 (10.10.10.51)
Me aseguré de que los firewalls estuvieran desactivados en todas las máquinas antes de realizar estas pruebas y también ejecuté arp -aMDC para ver si había un conflicto de direcciones MAC y no había duplicados. Todas las máquinas en la Temporarycarpeta también se apagaron por si acaso, pero no cambió nada en los resultados anteriores. Solo para estar seguro, utilicé este fragmento para forzar la generación de una nueva dirección MAC para esas máquinas:
foreach ($VM in (Get-Folder Temporary | Get-VM))
{
$NetworkAdapter = $VM | Get-NetworkAdapter
$NetworkAdapter | Set-NetworkAdapter -MacAddress 00:50:56:1a:ff:ff -Confirm:$false
$spec = New-Object VMware.Vim.VirtualMachineConfigSpec
$spec.deviceChange = New-Object VMware.Vim.VirtualDeviceConfigSpec[] (1)
$spec.deviceChange[0] = New-Object VMware.Vim.VirtualDeviceConfigSpec
$spec.deviceChange[0].operation = "edit"
$spec.deviceChange[0].device = $NetworkAdapter.ExtensionData
$spec.deviceChange[0].device.addressType = "generated"
$spec.deviceChange[0].device.macAddress = $null
$VM.ExtensionData.ReconfigVM_Task($spec)
}
Eso no cambió nada en la situación.
Luego instalé Wireshark en la puerta de enlace, comencé a monitorear el tráfico 10.10.10.254y pude ver cada tráfico en el que está implicada esa máquina. Por ejemplo, si 192.168.9.82Machine5_H3 ( ) hace ping a mi estación de trabajo ( 10.10.10.51), puedo ver la solicitud PING, luego la respuesta PING y, sin embargo, Machine5_H3 se queja de que no recibió ninguna respuesta. Si lo hago al revés, puedo ver la solicitud 192.168.9.82pero la puerta de enlace nunca recibe respuesta.
Por lo tanto, creo que algunos paquetes se caen en alguna parte, siendo mi principal sospechoso el conmutador ( 10.10.10.252), pero no estoy seguro de qué puedo hacer para confirmar esta teoría.
La agregación de enlaces se activó originalmente en la pila de conmutadores DELL, pero estaba dando problemas para conectar desde nuestras estaciones de trabajo a las máquinas virtuales que tienen IP en la 192.168.9.0/24red, por lo que la desactivamos.
Sin embargo, cambiar esta configuración en la pila de conmutadores no cambió nada en la situación anterior.
Debo haber hecho algo mal o haber omitido algunos detalles de configuración, pero no puedo entender qué es y agradecería cualquier sugerencia que me ayude a resolver lo que es un misterio para mí.
Respuesta1
Siguiendo el comentario de Zac67, verificamos la configuración de equipos de NIC en los tres hosts y descubrimos que los dos primeros usaban el parámetro "Ruta basada en hash de IP", mientras que el tercer host usaba "Ruta basada en el puerto virtual de origen".
Luego configuramos el tercer host con el mismo valor que los demás y leemos la advertencia asociada con la primera opción que dice "La agregación de enlaces debe configurarse en el conmutador físico".
Por lo tanto, volvimos al conmutador y reactivamos la agregación de enlaces para los puertos apropiados, pero hizo que toda la conectividad fuera inestable, las máquinas en la 192.168.9.0/24red se volvieron parcialmente inaccesibles y no cambió nada para aquellos en la 10.10.10.0/24red.
Así que decidimos ir en sentido contrario y deshabilitamos la agregación de enlaces en los conmutadores y utilizamos la opción "Ruta basada en el puerto virtual de origen" en los tres hosts.
Esto permitió recuperar el comportamiento normal de la 192.168.9.0/24red y una mejor conectividad de la 10.10.10.0/24red. Digo mejor porque algunas máquinas todavía eran inaccesibles, es decir, aquellas Host3que ni siquiera podían alcanzar el servidor DHCP para recuperar una IP.
Usando Wireshark para observar el tráfico, descubrimos que las transmisiones ARP a veces se filtraban, lo que explica por qué algunas máquinas no podían comunicarse entre sí pero aún así no nos da ninguna pista sobre una posible solución.
Después de haber estado estancado en esto durante un par de semanas sin ninguna esperanza de encontrar una respuesta, llamamos a los consultores que ayudaron a instalar la infraestructura en primer lugar y nos dijeron dos cosas:
- LACP no es compatible con VLAN
- La VLAN 42 estaba prohibida en uno de los puertos del switch.
Por lo tanto, asegurarse de que la configuración no utilizara LACP en absoluto y eliminar la restricción en el puerto permitió llegar a una situación de pleno funcionamiento.
Ahora, nos preguntamos cómo logramos prohibir la VLAN 42 en un solo puerto del conmutador.
En cuanto a la incompatibilidad de LACP y VLAN, nunca se nos ocurrió que esta podría ser la fuente de nuestros problemas, pero ahora que nos lo contaron, parece que es un problema bien conocido al apilar conmutadores DELL pero no pude encontrar ninguna respuesta definitiva. sobre el tema. Pero como funciona sin él, por mí todo está bien.