32 votos

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

Versión TL;DR: Resulta que se trataba de un profundo error de red de Broadcom en Windows Server 2008 R2. La sustitución por hardware Intel lo solucionó. Ya no utilizamos el hardware de Broadcom. Nunca.

Hemos estado utilizando HAProxy junto con latido del corazón 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 usando una interfaz virtual (eth1:1) en la IP: 69.59.196.211

La interfaz virtual (eth1:1) IP 69.59.196.211 está configurada como la puerta de enlace para los servidores 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 Windows detrás de nuestras pasarelas linux. HAProxy detecta que el servidor está fuera de línea, lo que podemos verificar mediante la conexión remota con el servidor que ha fallado e intentando hacer un ping a la puerta de enlace:

Pinging 69.59.196.211 with 32 bytes of data:
Reply from 69.59.196.220: Destination host unreachable.

Ejecutar arp -a en este servidor fallido muestra que no hay ninguna entrada para la dirección de la puerta de enlace (69.59.196.211):

Interface: 69.59.196.220 --- 0xa
Internet Address      Physical Address      Type
69.59.196.161         00-26-88-63-c7-80     dynamic
69.59.196.210         00-15-5d-0a-3e-0e     dynamic
69.59.196.212         00-21-5e-4d-45-c9     dynamic
69.59.196.213         00-15-5d-00-b2-0d     dynamic
69.59.196.215         00-21-5e-4d-61-1a     dynamic
69.59.196.217         00-21-5e-4d-2c-e8     dynamic
69.59.196.219         00-21-5e-4d-38-e5     dynamic
69.59.196.221         00-15-5d-00-b2-0d     dynamic
69.59.196.222         00-15-5d-0a-3e-09     dynamic
69.59.196.223         ff-ff-ff-ff-ff-ff     static
224.0.0.22            01-00-5e-00-00-16     static
224.0.0.252           01-00-5e-00-00-fc     static
225.0.0.1             01-00-5e-00-00-01     static

En nuestras instancias de la pasarela linux arp -a espectáculos:

peak-colo-196-220.peak.org (69.59.196.220) at <incomplete> on eth1
stackoverflow.com (69.59.196.212) at 00:21:5e:4d:45:c9 \[ether\] on eth1
peak-colo-196-215.peak.org (69.59.196.215) at 00:21:5e:4d:61:1a \[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-222.peak.org (69.59.196.222) at 00:15:5d:0a:3e:09 \[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

¿Por qué arp ocasionalmente establece la entrada para este servidor fallido como <incompleto>? ¿Deberíamos definir nuestras entradas arp de forma estática? Siempre he dejado arp solo ya que funciona el 99% de las veces, pero en este caso parece estar fallando. ¿Hay algún otro paso para solucionar este problema?

COSAS QUE HEMOS PROBADO

Añadí una entrada arp estática para probar en una de las puertas de enlace de linux que todavía no ayudó.

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 demuestra que este problema volverá a aparecer.

Intercambio de tarjetas de red y conmutadores

Me di cuenta de que la luz de enlace en el puerto del conmutador para el servidor Windows fallado estaba funcionando a 100Mb en lugar de 1Gb en la interfaz fallada. 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. Traté de cambiar las propiedades de la tarjeta de red en Windows y el servidor se bloqueó y requirió un reinicio duro después de hacer clic en aplicar. Este servidor de Windows tiene dos interfaces de red físicas, así que he intercambiado los cables y la configuración de red en las dos interfaces para ver si el problema sigue la interfaz. Si la interfaz pública se cae de nuevo, sabremos que no es un problema con la tarjeta de red.

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

Cambio de versiones de los controladores de hardware de red

Hemos tenido el mismo problema con el último controlador de Broadcom, así como con el controlador integrado que viene en Windows Server 2008 R2.

Sustitución de cables de red

Como último esfuerzo recordamos que otro cambio que se produjo fue la sustitución de todos los cables de conexión entre nuestros servidores / switch. Habíamos comprado dos conjuntos, uno verde de longitudes de 1 pie a 3 pies para las interfaces privadas y otro conjunto de cables rojos para las interfaces públicas. Cambiamos todos los cables de conexión de la interfaz pública por otros de otra marca y nuestros servidores funcionaron sin problemas durante toda una semana... y entonces el problema volvió a aparecer.

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

También hemos probado a desactivar la descarga de sumas de comprobación TCP/IP en el controlador, pero no ha habido ningún cambio. Ahora estamos retirando TProxy y pasando a un sistema más tradicional. x-forwarded-for disposición de la red sin necesidad de reescribir las direcciones IP. Veremos si eso ayuda.

Cambiar los proveedores de virtualización

Por si acaso esto estuviera relacionado con Hyper-V de alguna manera (alojamos máquinas virtuales de Linux en él), cambiamos a VMWare Server. No hay cambios.

Modelo de host de conmutación

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

Lo hicimos, y también obtuvimos algunos hotfixes del kernel no publicados que presumiblemente se incluyeron en el SP1 de 2008 R2. No hay solución.

Sustitución del hardware de la tarjeta de red

Finalmente, la sustitución del hardware de red Broadcom por el hardware de red Intel solucionó el problema. Así que me inclino a pensar que los controladores Broadcom de Windows Server 2008 R2 son los culpables.

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

0 votos

También hay que tener en cuenta que utilizamos TProxy (proxy transparente) para devolver la IP real del tráfico que entra a través de HAProxy. blog.loadbalancer.org/

0 votos

2 votos

Nunca confíes en la configuración automática en un entorno de producción. Ajusta la velocidad a lo que debe ser, y pon un monitor para estar seguro.

7voto

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

Si no existe ninguna entrada en la caché ARP para una IP de destino solicitada, el núcleo generará peticiones ARP mcast_solicit hasta recibir una respuesta. Durante este periodo de descubrimiento, la entrada de la caché ARP aparecerá en un estado incompleto. Si la búsqueda no tiene éxito después del número especificado de peticiones ARP, la entrada de la caché ARP aparecerá en un estado fallido. Si la búsqueda tiene éxito, el kernel introduce la respuesta en la caché ARP y reinicia los temporizadores de confirmación y actualización.

Parece que su caja de puerta de enlace no responde (o responde muy lentamente) a las peticiones ARP de su caja de puerta de enlace. ¿Es así? <incomplete> finalmente cambiar a <failed> ? ¿Qué hardware de red tiene entre el servidor y la pasarela? ¿Es posible que las peticiones ARP de difusión estén siendo filtradas o bloqueadas en algún lugar entre los dos hosts?

5voto

Max Clark Puntos 51

Significa que has hecho un ping a la dirección, la IP tiene un registro PTR (de ahí el nombre) pero no ha respondido nada de la máquina en cuestión. Cuando vemos esto es más comúnmente debido a una máscara de subred que se establece de forma incorrecta - o en el caso de las IPs vinculadas a una interfaz loopback que fueron accidentalmente vinculadas a la interfaz eth en su lugar.

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

0 votos

Sin embargo, si ocurre de forma intermitente, eso me hace pensar que no se trata de una máscara de subred mal configurada (que, hay que reconocerlo, suele ser la causa de que las máquinas no respondan a las peticiones ARP).

0 votos

El post me parece bastante claro. La dirección IP .211 es una IP virtual compartida por las instancias de HAProxy. La dirección IP .220 está asignada a una máquina Windows que, periódicamente, pierde su capacidad de comunicación con la dirección IP .211 (como puede verse en la línea "Interface:" de la salida ARP citada en el post).

0 votos

196.220 es la ip del servidor Windows que ha fallado - 196.211 es la ip virtual de las interfaces haproxy.

4voto

Evan Anderson Puntos 118832

Como dice Max Clark, el <incomplete> sólo significa que 69.59.196.211 ha emitido una petición ARP para 69.59.196.220 y no ha recibido respuesta todavía. (En la tierra de Windows verás esto como un mapeo ARP a "00-00-00-00-00-00"... Me parece extraño, por cierto, que no veas tal mapeo ARP en 69.59.196.220 para 69.59.196.211).

No me gusta 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 apropiada en la máquina Windows "que falla" (69.59.196.220) para observar que hace ARP para 69.59.196.211, y para observar cómo / si responde a las peticiones ARP de 69.59.196.211. También consideraría la posibilidad de husmear en la máquina de la puerta de enlace sólo 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.

Lo sé, por el blog que tienes una red back-end y una red front-end. Durante estos cortes, ¿tiene el servidor Windows "que falla" (69.59.196.220) algún problema de comunicación con otras máquinas en la red frontal, o sólo tiene problemas para hablar con su puerta de enlace? Tengo curiosidad por saber si la máquina que falla llega a través de la red de front-end o de back-end cuando la pillas en el acto.

¿Qué hace para "resolver" el problema cuando se produce?

Editar:

Veo en tu actualización que estás reiniciando la máquina Windows que "falla" para resolver el problema. Antes de hacer eso la próxima vez, ¿puedes verificar que la máquina Windows es capaz de "hablar" en su interfaz frontal? Además, coge una copia de la tabla de enrutamiento de la máquina Windows ( route print ) durante un fallo, también. (Estoy tratando de averiguar si el NIC / controlador se está volviendo loco en la máquina de Windows, básicamente).

0 votos

Cuando se produce este problema podemos reiniciar el servidor web que ha fallado (196.220) y funcionará - nuestra experiencia ha demostrado que en 24 horas volverá a fallar.

1 votos

Sería interesante saber si el servidor pudo hablar, en absoluto, en la NIC conectada al segmento con la máquina .211 (que, según entiendo por su actualización, está ahora intercambiada con el segmento del back-end). Mi instinto me dice que el "NIC loco" va a ser la causa root en este caso, pero ya veremos...

1 votos

Cuando esto sucede, la máquina definitivamente no puede hablar en el extremo frontal (público) NIC en absoluto . El NIC del back end (privado) no se ve afectado. Siempre he pensado que era el controlador de la NIC el que se volvía loco, pero la pregunta es "¿por qué?" (también: esto ocurre con el último controlador de broadcom así como con el controlador predeterminado de Wink28 R2) Voy a comprobar los registros de eventos después de que se reinicie, lo que lleva más de 10 minutos ya que tiene que hacer un bluescreen como parte del apagado primero. Los he limpiado de antemano.

2voto

Cade Roux Puntos 265

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

2voto

DarthNoodles Puntos 844

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 averiguar cómo volver a la puerta de enlace.

El ARP estático en el servidor web rompe la capacidad de sus servidores web para cambiar las puertas de enlace cuando uno de los nodos haproxy falló - Supongo que la interfaz virtual comparte la misma dirección MAC que el eth1 del nodo haproxy, por lo que tendría que codificar duro a 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 en él - instala algún código de filtrado en la pila de red que le impidió ver los paquetes ARP de la puerta de enlace en absoluto. La solución (proporcionada por Microsoft) era eliminar la entrada del registro que cargaba la DLL.

La otra vez que ocurrió este problema, eliminar todo el adaptador de red del administrador de dispositivos y volver a instalarlo pareció ayudar.

EnMiMaquinaFunciona.com

EnMiMaquinaFunciona es una comunidad de administradores de sistemas en la que puedes resolver tus problemas y dudas.
Puedes consultar las preguntas de otros sysadmin, hacer tus propias preguntas o resolver las de los demás.

Powered by:

X