Recientemente me he encontrado con problemas en los que direcciones MAC incorrectas llenan las tablas arp de algunas máquinas virtuales de Windows que se ejecutan en la nube de un proveedor de nube. Por ejemplo, si hago ping a 10.1.2.3, algunas máquinas virtuales de Windows muestran una dirección MAC diferente a la de la mayoría de las demás máquinas virtuales. El resultado es que estas pocas máquinas virtuales de Windows no pueden llegar a 10.1.2.3, pero el resto de máquinas virtuales (tanto Windows como Linux) sí pueden llegar a él.
Después de ejecutar Packet Captures, la fuente de las direcciones MAC incorrectas parece ser MS-NLB-PhysServer-XX_, que se incluye enLista publicada de Wirehark. Sin embargo, no estoy ejecutando ningún tipo de MS-NLB, por lo que resulta muy confuso cuál es esa fuente. Mi proveedor de nube dice que no proviene de ellos. Mis preguntas son:
- ¿Existe una buena manera de identificar el dispositivo de origen según su dirección MAC si no soy propietario de ese dispositivo? es decir, me pregunto si proviene de los balanceadores de carga de nuestro proveedor de nube.
- ¿Cuáles son las razones por las que este dispositivo de origen tendría direcciones MAC incorrectas que envía a otros dispositivos? es decir, ¿por qué tiene la dirección MAC incorrecta para 10.1.2.3 y otras interfaces de red recién creadas?
- ¿Cuáles son las razones por las que solo un subconjunto de máquinas virtuales obtiene direcciones MAC incorrectas de esta fuente y otras máquinas virtuales en la misma subred obtienen direcciones MAC buenas de otras fuentes?
Respuesta1
También nos encontramos con esto, está sucediendo en nuestros nodos EKS de Windows después de que se reinician. Tenemos nodos que se unen a un dominio para GMSA, lo que requiere un reinicio, por lo que estas instancias detectaron el problema de inmediato.
Abrí un ticket de soporte y la solución que me proporcionaron es ejecutar un script de apagado que ejecute lo siguiente
powershell.exe /c "get-hnsendpoint | remove-hnsendpoint"
exit
Se dijo que la salida era importante porque evita que el cierre se suspenda durante un período de tiempo.
Utilicé esta respuesta como base para automatizar este proceso:https://stackoverflow.com/a/47709154
Respuesta2
Si no posee el otro dispositivo, supongo que es porque está en una red completamente diferente, lo que significaría que no verá su dirección MAC, sino la del dispositivo más cercano a usted que enrutará el tráfico a ese otro dispositivo final. dispositivo.
Recuerde que la comunicación de un extremo a otro no ocurre en la capa de enlace de datos (es decir, la capa 2).
El escenario más probable aquí podría ser que su ruta esté configurada incorrectamente enalgunode sus máquinas virtuales y en el nivel del sistema operativo en lugar de la tabla de rutas de red de su proveedor de nube... o están en diferentes redes (¿tal vez la subred de AWS?) y tienen diferentes tablas de rutas.
Respuesta3
Añadiendo esto también como respuesta.
Varios proveedores de nube tienen unabastantevisión peculiar de las redes, y manejarlas de una manera que un profesional de redes encontraría simplemente escandalosa; sin embargo, así es como funcionan y tenemos que afrontarlo.
En Azure, las direcciones MAC simplemente no tienen ningún sentido; todas las entradas de la tabla ARP siempre apuntan a 12-34-56-78-9a-bc, porque todas las redes de Azure se manejan en la capa IP y ARP no existe ni funciona en absoluto; una máquina virtual de Azure no puede simplemente gritar "Tengo esta dirección IP" (también conocida como "ARP gratuito"), porque la plataforma Azure necesita saberlo para enrutar el tráfico a esa máquina virtual. La agrupación en clústeres de Azure funciona de una manera tan extraña que hay que colocar un equilibrador de carga muy inusual delante de su clúster.
Sinceramente, no sé cómo funciona esto en AWS, pero supongo que es igual de extraño, si no peor.