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

32

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:

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/

Geoff Dalgas
fuente
También es de destacar: también utilizamos TProxy (proxy transparente) para enviar la IP real del tráfico que ingresa a través de HAProxy. blog.loadbalancer.org/…
Jeff Atwood
LUnix ... heh heh ... hld.c64.org/poldi/lunix/lunix.html
Evan Anderson el
2
Nunca confíe en la configuración automática en un entorno de producción. Establezca la velocidad a lo que debería ser y coloque un monitor para asegurarse.
Daniel C. Sobral
3
@Daniel Sobral: Tengo que estar muy en desacuerdo contigo. En 2003 supongo que podría ver eso. Con hardware moderno, la velocidad del puerto de configuración rígida y el dúplex son una receta para obtener desajustes de velocidad / dúplex. La negociación automática en equipos Ethernet modernos funciona bien.
Evan Anderson
1
Estoy con @Daniel Sobral, muchas veces he tenido fallas en la red causadas por negociaciones de mala velocidad en el peor momento, por lo que en los sistemas de producción voy con configuraciones estáticas. Cuando eso sucede, ¿qué dice el estado del enlace en el conmutador? Se gestiona, ¿verdad? ¿Qué dice el sistema de Windows? Apostaría a que la red falla a nivel de enlace, y eso es lo que está causando que esos ARP estén incompletos (fallado o esperando recibir ARP quién ha recibido). Un hardware / controlador defectuoso podría ser una causa. Veamos cómo va después del intercambio.
Pablo Alsina

Respuestas:

7

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?


fuente
5

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?

Max Clark
fuente
Sin embargo, si sucede de manera intermitente, eso tiende a hacerme pensar que no se trata de una máscara de subred configurada incorrectamente (lo cual, es cierto, a menudo es la causa de que las máquinas no respondan a las solicitudes de ARP).
Evan Anderson
La publicación me parece bastante clara. La dirección IP .211 es una IP virtual compartida por las instancias de HAProxy. La dirección IP .220 se asigna a una máquina Windows que, periódicamente, pierde su capacidad de comunicarse con la dirección IP .211 (como se puede ver en la línea "Interfaz:" de la salida ARP citada en la publicación).
Evan Anderson
196.220 es la ip del servidor de Windows fallido - 196.211 es la ip virtual para las interfaces haproxy.
Geoff Dalgas
4

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).

Evan Anderson
fuente
Cuando se produce este problema, podemos reiniciar el servidor web fallido (196.220) y funcionará; nuestra experiencia ha demostrado que en 24 horas volverá a fallar.
Geoff Dalgas
1
Sería interesante saber si el servidor pudo hablar, en absoluto, sobre la NIC conectada al segmento con la máquina .211 (que, según entiendo por su actualización, ahora se intercambia con el segmento de fondo). Mi instinto dice que "bonkers NIC" va a ser la causa raíz de esto, pero ya veremos ...
Evan Anderson
1
Cuando esto sucede, la máquina definitivamente no puede hablar en el NIC front-end (público) en absoluto . El NIC de back-end (privado) no se ve afectado. Siempre he sentido que el conductor de la NIC se estaba volviendo loco, pero la pregunta es "¿por qué"? (también: esto sucede con el último controlador de Broadcom, así como con el controlador Wink28 R2 predeterminado) Voy a verificar los registros de eventos después de que se reinicie, lo que lleva más de 10 minutos, ya que finalmente tiene que apagar la pantalla azul como parte del apagado. Los eliminé de antemano.
Jeff Atwood
ahora estamos involucrando el soporte de Microsoft ya que sinceramente creemos que este es un problema a nivel del sistema operativo. Hemos hecho todos los problemas posibles que hemos podido y hemos descartado ... bueno, todo.
Jeff Atwood
Zow Me encantaría saber cómo resulta.
Evan Anderson el
2

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.

Cade Roux
fuente
2

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.

jaredg
fuente
2

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.

Seth
fuente
1

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.
Murali Suriar
fuente
definitivamente estamos mirando capturas de paquetes ahora
Jeff Atwood
desafortunadamente, las capturas de paquetes no nos mostraron nada obvio, y la máquina en la que capturamos tiene un tráfico de red sensible ... por lo que no podemos dárselo a los expertos para que lo vean.
Jeff Atwood
@Jeff: ¿podría proporcionar capturas que muestren solo el tráfico ARP? Me interesaría ver el comportamiento ARP si nada más.
Murali Suriar
seguimos las instrucciones del soporte de MSFT sobre los datos que desean capturar; les tomó algunas semanas, pero finalmente encontraron una revisión de red privada del núcleo para nosotros.
Jeff Atwood
0

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.

Chris E
fuente
0

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

M-Razavi
fuente