El adaptador de red de Windows Server 2008 R2 deja de funcionar, requiere un reinicio completo

TL; Versión DR: Resulta que este fue un error profundo de red Broadcom en Windows Server 2008 R2. Reemplazar con hardware Intel lo arregló. Ya no usamos hardware Broadcom. Siempre.

Hemos estado usando HAProxy junto con heartbeat del proyecto Linux-HA. Estamos utilizando dos instancias de Linux para proporcionar una conmutación por error. Cada servidor tiene su propia IP pública y una única IP que se comparte entre los dos mediante una interfaz virtual (eth1: 1) en IP: 69.59.196.211

La interfaz virtual (eth1: 1) IP 69.59.196.211 se configura como la puerta de enlace para los servidores de Windows detrás de ellos y usamos ip_forwarding para enrutar el tráfico.

Estamos experimentando una interrupción ocasional de la red en uno de nuestros servidores de Windows detrás de nuestras puertas de enlace de Linux. HAProxy detectará que el servidor está fuera de línea, lo que podemos verificar mediante la conexión remota al servidor fallido e intentando hacer ping a la puerta de enlace:

Pinging 69.59.196.211 con 32 bytes de datos:
Respuesta del 69.59.196.220: host de destino inalcanzable.

La ejecución arp -aen este servidor fallido muestra que no hay entrada para la dirección de la puerta de enlace (69.59.196.211):

Interfaz: 69.59.196.220 --- 0xa
Dirección de Internet Tipo de dirección física
69.59.196.161 00-26-88-63-c7-80 dinámico
69.59.196.210 00-15-5d-0a-3e-0e dinámico
69.59.196.212 00-21-5e-4d-45-c9 dinámico
69.59.196.213 00-15-5d-00-b2-0d dinámico
69.59.196.215 00-21-5e-4d-61-1a dinámico
69.59.196.217 00-21-5e-4d-2c-e8 dinámico
69.59.196.219 00-21-5e-4d-38-e5 dinámico
69.59.196.221 00-15-5d-00-b2-0d dinámico
69.59.196.222 00-15-5d-0a-3e-09 dinámico
69.59.196.223 ff-ff-ff-ff-ff-ff estática
224.0.0.22 01-00-5e-00-00-16 estático
224.0.0.252 01-00-5e-00-00-fc estático
225.0.0.1 01-00-5e-00-00-01 estático

En nuestras instancias de puerta de enlace de Linux arp -amuestra:

peak-colo-196-220.peak.org (69.59.196.220) en <incomplete> en eth1
stackoverflow.com (69.59.196.212) en 00: 21: 5e: 4d: 45: c9 [éter] en eth1
peak-colo-196-215.peak.org (69.59.196.215) a las 00: 21: 5e: 4d: 61: 1a [éter] en eth1
peak-colo-196-219.peak.org (69.59.196.219) a las 00: 21: 5e: 4d: 38: e5 [éter] en eth1
peak-colo-196-222.peak.org (69.59.196.222) a las 00: 15: 5d: 0a: 3e: 09 [éter] en eth1
peak-colo-196-209.peak.org (69.59.196.209) a las 00: 26: 88: 63: c7: 80 [éter] en eth1
peak-colo-196-217.peak.org (69.59.196.217) a las 00: 21: 5e: 4d: 2c: e8 [éter] en eth1

¿Por qué arp configuraría ocasionalmente la entrada para este servidor fallido como <completo>? ¿Deberíamos definir nuestras entradas arp de forma estática? Siempre he dejado solo a arp, ya que funciona el 99% del tiempo, pero en este caso parece estar fallando. ¿Hay algún paso adicional de solución de problemas que podamos tomar para ayudar a resolver este problema?

COSAS QUE HEMOS PROBADO

Agregué una entrada arp estática para probar en una de las puertas de enlace de Linux que todavía no ayudaba.

root@haproxy2:~# arp -a
peak-colo-196-215.peak.org (69.59.196.215) at 00:21:5e:4d:61:1a [ether] on eth1
peak-colo-196-221.peak.org (69.59.196.221) at 00:15:5d:00:b2:0d [ether] on eth1
stackoverflow.com (69.59.196.212) at 00:21:5e:4d:45:c9 [ether] on eth1
peak-colo-196-219.peak.org (69.59.196.219) at 00:21:5e:4d:38:e5 [ether] on eth1
peak-colo-196-209.peak.org (69.59.196.209) at 00:26:88:63:c7:80 [ether] on eth1
peak-colo-196-217.peak.org (69.59.196.217) at 00:21:5e:4d:2c:e8 [ether] on eth1
peak-colo-196-220.peak.org (69.59.196.220) at 00:21:5e:4d:30:8d [ether] PERM on eth1

root@haproxy2:~# arp -i eth1 -s 69.59.196.220 00:21:5e:4d:30:8d
root@haproxy2:~# ping 69.59.196.220
PING 69.59.196.220 (69.59.196.220) 56(84) bytes of data.
--- 69.59.196.220 ping statistics ---
7 packets transmitted, 0 received, 100% packet loss, time 6006ms

Reiniciar el servidor web de Windows resuelve este problema temporalmente sin otros cambios en la red, pero nuestra experiencia muestra que este problema volverá.

Intercambio de tarjetas de red y conmutadores

Noté que la luz de enlace en el puerto del conmutador para el servidor de Windows fallido se ejecutaba a 100 Mb en lugar de 1 Gb en la interfaz fallida. Moví el cable a varios otros puertos abiertos y el enlace indicaba 100Mb para cada puerto que probé. También cambié el cable con el mismo resultado. Intenté cambiar las propiedades de la tarjeta de red en Windows y el servidor se bloqueó y requirió un restablecimiento completo después de hacer clic en Aplicar. Este servidor de Windows tiene dos interfaces de red físicas, por lo que he cambiado los cables y la configuración de red en las dos interfaces para ver si el problema sigue a la interfaz. Si la interfaz pública vuelve a fallar, sabremos que no es un problema con la tarjeta de red.

(También probamos otro interruptor que tenemos a mano, sin cambios)

Cambio de versiones del controlador de hardware de red

Hemos tenido el mismo problema con el último controlador Broadcom, así como con el controlador incorporado que se incluye en Windows Server 2008 R2.

Sustitución de cables de red

Como último esfuerzo, recordamos que otro cambio que ocurrió fue el reemplazo de todos los cables de conexión entre nuestros servidores / conmutadores. Habíamos comprado dos juegos, uno verde de longitudes de 1 a 3 pies para las interfaces privadas y otro conjunto de cables rojos para las interfaces públicas. Intercambiamos todos los cables de conexión de interfaz pública con una marca diferente y ejecutamos nuestros servidores sin problemas durante una semana completa ... aaaaa y luego el problema se repitió.

Deshabilitar la descarga de suma de comprobación, eliminar TProxy

También intentamos deshabilitar la descarga de suma de comprobación TCP / IP en el controlador, sin cambios. Ahora estamos sacando TProxy y pasándonos a una x-forwarded-fordisposición de red más tradicional sin ninguna reescritura de direcciones IP sofisticada. Veremos si eso ayuda.

Cambiar proveedores de virtualización

En caso de que esto estuviera relacionado con Hyper-V de alguna manera (alojamos máquinas virtuales Linux en él), cambiamos a VMWare Server. Ningún cambio.

Cambiar modelo de host

Hemos llegado al final de nuestra cuerda de solución de problemas y ahora estamos involucrando formalmente el soporte de Microsoft. Recomendaron cambiar el modelo de host:

• http://en.wikipedia.org/wiki/Host_model
• http://technet.microsoft.com/en-us/magazine/2007.09.cableguy.aspx

Lo hicimos y también obtuvimos algunas revisiones de kernel no publicadas que presumiblemente se incluyeron en 2008 R2 SP1. Sin arreglo.

Sustitución del hardware de la tarjeta de red

Finalmente, el reemplazo del hardware de red Broadcom con el hardware de red Intel solucionó este problema para nosotros. ¡Entonces me inclino a pensar que los controladores Broadcom Windows Server 2008 R2 tienen la culpa!

http://blog.serverfault.com/post/broadcom-die-mutha/

De http://linux-ip.net/html/ether-arp.html :

Si no existe una entrada de caché ARP para una IP de destino solicitada, el núcleo generará solicitudes ARP mcast_solicit hasta que reciba una respuesta. Durante este período de descubrimiento, la entrada de caché ARP se mostrará en un estado incompleto. Si la búsqueda no tiene éxito después del número especificado de solicitudes ARP, la entrada de caché ARP aparecerá en un estado fallido. Si la búsqueda tiene éxito, el kernel ingresa la respuesta en el caché ARP y restablece los temporizadores de confirmación y actualización.

Parece que su caja de puerta de enlace no responde (o responde muy lentamente) a las solicitudes ARP de su caja de puerta de enlace. ¿Eso <incomplete>finalmente cambia a <failed>? ¿Qué hardware de red tiene entre el servidor y la puerta de enlace? ¿Es posible transmitir solicitudes ARP que se están filtrando o bloqueando en algún lugar entre los dos hosts?

Significa que pinchó la dirección, la IP tiene un registro PTR (de ahí el nombre) pero nada respondió de la máquina en cuestión. Cuando vemos esto, se debe más comúnmente a una máscara de subred configurada incorrectamente, o en el caso de IP vinculadas a una interfaz de bucle invertido que se vincularon accidentalmente a la interfaz eth.

¿Qué es 196.220? ¿Cuál es su relación con 196.211? Supongo que .220 es uno de los hosts proxy HA. Cuando ejecuta ifconfig -a & arp -a en él, ¿qué muestra?

Como dice Max Clark, el <incompleto> solo significa que 69.59.196.211 ha presentado una solicitud ARP para 69.59.196.220 y aún no ha recibido una respuesta. (En Windows-land, verá esto como un mapeo ARP a "00-00-00-00-00-00" ... Me parece extraño, por cierto, que no esté viendo un mapeo ARP en 69.59.196.220 para 69.59.196.211.)

Tiendo a no gustarme usar entradas ARP estáticas porque, en mi experiencia, ARP generalmente ha hecho su trabajo todo el tiempo.

Si fuera yo, olfatearía la interfaz Ethernet adecuada en la máquina Windows "defectuosa" (69.59.196.220) para observarla ARP'ing para 69.59.196.211, y para observar cómo / si responde a las solicitudes ARP de 69.59. 196.211. También consideraría rastrear en la máquina de puerta de enlace solo para ARP ( tcpdump -i interface-name arp) para ver cómo se ve el tráfico ARP desde el lado de la máquina Linux.

Sé, por el blog , que tienes una red back-end y una red front-end. Durante estas interrupciones, ¿el servidor de Windows "defectuoso" (69.59.196.220) tiene problemas para comunicarse con otras máquinas en la red front-end, o simplemente tiene problemas para comunicarse con su puerta de enlace? Tengo curiosidad si vienes a la máquina que falla a través de la red front-end o back-end cuando la estás captando en el acto.

¿Qué estás haciendo para "resolver" el problema cuando ocurre?

Editar:

Veo por su actualización que está reiniciando la máquina de Windows "que falla" para resolver el problema. Antes de hacerlo la próxima vez, ¿puede verificar que la máquina Windows pueda "hablar" en su interfaz frontal? Además, tome una copia de la tabla de enrutamiento de la máquina Windows ( route print) durante una falla, también. (Estoy tratando de determinar si la NIC / controlador se está volviendo loco en la máquina Windows, básicamente).

Este documento muestra los diferentes estados (tabla 2.1). Incompleto significaría que ha enviado una primera solicitud de ARP (presumiblemente después de un retraso, una sonda, una sonda) pero aún no ha recibido una respuesta.

La razón por la que el ARP estático en el nodo haproxy no ayuda es que su servidor web todavía no puede encontrar la manera de volver a la puerta de enlace.

El ARP estático en el servidor web interrumpe la capacidad de sus servidores web para cambiar puertas de enlace cuando falla uno de los nodos haproxy. Supongo que la interfaz virtual comparte la misma dirección MAC que el eth1 del nodo haproxy, por lo que tendrá que código para una de las dos puertas de enlace en cada servidor web.

¿Tiene algún tipo de software de seguridad instalado en el servidor web que falla? Pasé una larga noche con un servidor de Windows 2008 que tenía Symantec Endpoint Security: instala un código de filtrado en la pila de red que le impedía ver los paquetes ARP de la puerta de enlace. La solución para eso (según lo provisto por Microsoft) fue eliminar la entrada del registro que cargó la DLL.

La otra vez que ocurrió este problema, la eliminación de todo el adaptador de red del administrador de dispositivos y la reinstalación parecían ayudar.

Como ha configurado estáticamente su entrada arp, sus servidores saben dónde encontrar la puerta de enlace. Sin embargo, si su conmutador no sabe dónde está la puerta de enlace, no reenviará sus paquetes.

Parece que tiene un cambio malo (o confuso) entre sus HAproxy y sus servidores web. Reiniciarlo.

O eso, o sus servidores HAproxy no están de acuerdo sobre cuál está en control, y ambos responden búsquedas arp para .211.

En la misma línea, si su conmutador está sobrecargado, es posible que sus HAproxies no puedan comunicarse entre sí lo suficientemente rápido y se estén fallando.

La próxima vez que ocurra este problema, sugeriría ejecutar algunas capturas de paquetes en los dos hosts en cuestión, para determinar qué tráfico ARP está observando cada uno de ellos.

Es muy probable que su máquina HAproxy tenga algún sabor de tcpdump instalado. Para la máquina Windows, necesitará una aplicación WinPCAP , como Wireshark o Microsoft Network Monitor .

De hecho, al pensar en ello, ya que el problema parece estar específicamente relacionado con ARP, es posible que pueda registrar continuamente todo el tráfico ARP en la máquina HAproxy y la máquina Windows en cuestión, con un archivo de captura de 10 MB (por el argumento). Eso debería ser lo suficientemente grande como para que cuando detecte una falla, el archivo de captura aún contendrá el tráfico ARP de antes de la falla. (Vale la pena experimentar ejecutando la captura durante aproximadamente una hora, para ver cuántos datos genera).

Ejemplo de sintaxis de captura para tcpdump de Linux (tenga en cuenta que no tengo una caja de Linux a mano para probar esto; ¡pruebe el comportamiento de -C y -W antes de usarlo en producción!):

tcpdump -C 10 -i eth1 -w /var/tmp/arp.cap -W 1 arp

Con suerte, esto debería darle alguna indicación de lo que está fallando precisamente. Cuando una entrada ARP caduca (y de acuerdo con este artículo , las versiones más nuevas de Windows parecen expirar las entradas 'inactivas' muy agresivamente), esperaría que suceda lo siguiente:

1. El host de origen enviará una solicitud ARP al host de destino. Las solicitudes ARP generalmente se transmiten, pero en el caso de que un host esté actualizando una entrada existente, el ARP puede enviarse unicast.
2. El host de destino responderá con una respuesta ARP. El 99% del tiempo esto será unidifusión, pero el RFC permite respuestas de difusión. (Consulte también el RFC sobre la detección de colisión de direcciones IPv4 para obtener más detalles).

Por simple que parezca, hay muchas otras cosas que pueden interferir con este proceso:

• Es posible que la solicitud original no llegue al destino.
• La solicitud puede estar llegando al objetivo, pero la respuesta puede no estar llegando a la fuente.
• Algún tipo de mecanismo de alta disponibilidad puede estar interfiriendo con el comportamiento 'normal' de ARP:
  • ¿Cómo funciona la conmutación por error entre los nodos HAProxy? ¿Utiliza una dirección MAC compartida o utiliza ARP gratuito para fallar una dirección IP entre nodos?
  • Muchas de las direcciones MAC en las tablas ARP anteriores comienzan con 00-15-5D, que aparentemente está registrado en Microsoft. ¿Está utilizando alguna forma de agrupación u otra HA en la máquina Windows en cuestión? ¿Son estas direcciones MAC 00-15-5D las mismas que ves asociadas con las NIC de hardware cuando haces una 'ipconfig / all' en el servidor de Windows?

Cosas para verificar si / cuando esto vuelva a suceder:

• Mire las capturas de paquetes del tráfico ARP; ¿Alguna parte de la conversación obviamente no ha ocurrido?
• Verifique las tablas puente / CAM del conmutador; ¿todas las direcciones MAC en cuestión se asignan a los puertos que espera que hagan?
• ¿Los otros hosts en la subred tienen entradas ARP válidas para las direcciones IP de los hosts Windows y HAProxy?
• ¿Las entradas ARP para la misma IP de destino en varias máquinas de origen diferentes se resuelven en la misma dirección MAC? es decir, inicie sesión en un par de otros hosts en la subred y verifique que 196.211 se resuelva en la misma dirección MAC en ambos.

Tuvimos un problema similar con uno de nuestros servidores de terminal 2008 R2 donde todo el tráfico en la NIC se detendría pero permanecería conectado, y los LED de la NIC mostrarían comunicaciones. Este era un problema continuo que seguía apareciendo 2-3 veces por semana, pero solo después de alrededor de 12-13 horas de tiempo de actividad (el servidor se reinicia todas las noches).

Encontré que Seriousbit Netbalancer era la causa, después de que intenté (por curiosidad) terminar el servicio NetbalancerService. Luego, el tráfico comenzó a moverse a través de la interfaz. Desde entonces desinstalé Netbalancer.

Tuve el mismo problema con Asus Mainboard lan. Se solucionó instalando un controlador más reciente del sitio web de realtek