32 votos

Windows Server 2008 R2 adaptador de red deja de funcionar, se requiere el reinicio

TL;DR versión: resulta que ese era un profundo Broadcom redes error en Windows Server 2008 R2. La sustitución con hardware de Intel fijo. No utilizamos hardware Broadcom. Nunca.

Hemos estado utilizando HAProxy junto con el latido del corazón de la Linux-HA de proyecto. Estamos usando dos linux instancias para proporcionar una conmutación por error. Cada servidor cuenta con su propia IP pública y una sola IP, que es compartido 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 entrada para los servidores de windows detrás de ellos y utilizamos ip_forwarding para enrutar el tráfico.

Estamos experimentando una ocasional interrupción de la red en uno de nuestros servidores de windows detrás de nuestro linux puertas de enlace. HAProxy detectará el servidor está fuera de línea que podemos comprobar mediante la interacción remota con el servidor que ha fallado e intentar hacer ping a la puerta de enlace:

Ping 69.59.196.211 con 32 bytes de datos:
Respuesta de 69.59.196.220: host de Destino inaccesible.

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

Interfaz: 69.59.196.220 --- 0xa
Dirección De Internet Dirección Física Tipo De
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ática
224.0.0.252 01-00-5e-00-00-fc estática
225.0.0.1 01-00-5e-00-00-01 estática

En nuestro linux puerta de enlace de casos arp -a muestra:

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

¿Por qué arp ocasionalmente conjunto de la entrada para este servidor que ha fallado como <incompleta>? Debemos definir nuestro entradas arp estática? Siempre he dejado arp sola desde que funciona el 99% del tiempo, pero en este caso parece estar fallando. Hay otros pasos de solución de problemas que podemos tomar ayudar a resolver este problema?

COSAS QUE HEMOS TRATADO

He añadido una entrada arp estática para la prueba en uno de los linux pasarelas que aún no ayuda.

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, el problema se soluciona temporalmente sin otros cambios en la red, pero en nuestra experiencia demuestra que este problema va a volver.

El intercambio de tarjetas de red y switches

Me di cuenta de que la luz de conexión en el puerto del conmutador para el error de windows server se ejecuta en 100 mb en lugar de 1 gb en la interfaz error. He movido el cable de varios otros puertos abiertos y el enlace indicado 100Mb para cada puerto que he probado. También me cambió el cable con el mismo resultado. He intentado cambiar las propiedades de la tarjeta de red en windows y el servidor encerrado y requiere un hard reset después de hacer clic en aplicar. Este servidor windows tiene dos interfaces de red físicas, así que he intercambiado los cables y la configuración de red de las dos interfaces para ver si el problema sigue a la interfaz. Si la interfaz pública vuelve a bajar sabremos que no es un problema con la tarjeta de red.

(También se intentó con otro interruptor que tenemos a la mano, no hay cambio)

El cambio de hardware de red del controlador de versiones

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

La sustitución de los cables de red

Como un último esfuerzo, hemos recordado otro cambio que se produjo fue la sustitución de todos los cables de conexión entre nuestros servidores / interruptor. Habíamos comprado dos juegos, uno verde de longitudes de 1ft - 3ft para las interfaces privadas y otro conjunto de cables rojos para las interfaces públicas. Cambiamos todos de la interfaz pública de los cables de conexión con una marca diferente y corrió nuestros servidores sin problema por una semana completa ... aaaaaand entonces el problema se repitió.

Deshabilitar checksum offload, quitar TProxy

También hemos intentado desactivar TCP/IP checksum offload en el controlador, no hay cambio. Ahora estamos sacando TProxy y mudarse a una más tradicional, x-forwarded-for de la red de acuerdo sin ningún tipo de fantasía dirección IP de la reescritura. Vamos a ver si eso ayuda.

Interruptor de la Virtualización de los proveedores de

En la posibilidad de que esto estaba relacionado con la tecnología Hyper-V de alguna manera (hacemos host Linux VMs), cambiamos a VMWare Server. Ningún cambio.

Interruptor de modelo de host

Hemos llegado al final de nuestra solución de problemas de la cuerda y ahora son formalmente que implican el soporte de Microsoft. Se recomienda cambiar el modelo de host:

Nosotros lo hicimos, y también tenemos algunos inéditos revisiones del núcleo que eran presumiblemente rodó en 2008 R2 SP1. No hay ninguna solución.

Sustitución de hardware de tarjeta de red

En última instancia, la sustitución de la red Broadcom de hardware con Intel hardware de red fija este problema para nosotros. Así que me inclino a pensar que la Broadcom Windows Server 2008 R2 conductores tienen la culpa!

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

5voto

Max Clark Puntos 51

Esto significa que usted ping a 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 que esto es más comúnmente debido a una máscara de subred está configurado incorrectamente, o, en el caso de las direcciones ip asociadas a una interfaz de bucle invertido de que fueron accidentalmente vinculado a la eth de la interfaz de lugar.

¿Qué es 196.220? Cuál es su relación con 196.211? Estoy asumiendo que .220 es uno de los HA Proxy de los ejércitos. Al ejecutar ifconfig-a & arp-a en ella ¿qué muestra?

4voto

Evan Anderson Puntos 118832

Como Max dice Clark, el <incompleta> sólo significa que 69.59.196.211 ha formulado una solicitud de ARP para 69.59.196.220 y no ha recibido respuesta todavía. (En Windows-tierra verá esto como un ARP asignación a "00-00-00-00-00-00"... me parece extraño, por CIERTO, que no estamos viendo un ARP asignación en 69.59.196.220 para 69.59.196.211.)

Tiendo a no gusta usar ARP estática entradas porque, en mi experiencia, ARP, en general, ha hecho su trabajo todo el tiempo.

Si fuera yo, me gustaría oler el adecuado interfaz Ethernet en el "fracaso" de Windows de la máquina (69.59.196.220) para observar ARP ing para 69.59.196.211, y observar cómo / si es responder a solicitudes ARP de 69.59.196.211. También me gustaría considerar la posibilidad de oler en el equipo de puerta de enlace para ARP sólo (tcpdump -i interface-name arp) para ver lo que el tráfico ARP ve desde el lado de la máquina Linux.

Sé que, desde el blog, que tienes una red de back-end y front-end de la red. Durante estos cortes, ¿el "fracaso" de Windows server (69.59.196.220) tienen problemas para comunicarse con otras máquinas en el front-end de la red, o es que sólo tiene problemas para hablar a su puerta de enlace? Tengo curiosidad por ver si vas a venir a la máquina averiada a través del front-end o back-end de la red cuando usted está atrapando en la ley.

¿Qué están haciendo para "resolver" el problema cuando se produce?

Editar:

Veo en la actualización que se está reiniciando el "fracaso" de Windows de la máquina para resolver el problema. Antes de hacerlo la próxima vez, se puede verificar que la máquina de Windows es capaz de "hablar" en su front-end de la interfaz en todos los? También, agarra una copia de la tabla de enrutamiento de la máquina de Windows (route print) durante un error, es demasiado. (Estoy tratando de averiguar si el NIC / conductor va loco de la máquina de Windows, básicamente.)

2voto

Cade Roux Puntos 265

Este documento muestra los diferentes estados (tabla 2.1). Incompleta significaría que se ha enviado una primera solicitud de ARP (es de suponer que después de un rancio, el retraso de la sonda), pero aún no ha recibido una respuesta.

2voto

DarthNoodles Puntos 844

La razón por la ARP estática en el haproxy nodo no ayuda es que el servidor web todavía no puede averiguar cómo llegar de nuevo a la puerta de enlace.

ARP estática en el servidor web se rompe la capacidad de sus servidores web para cambiar de puerta de enlace cuando uno de los haproxy nodos error -- supongo que la interfaz virtual comparte la misma dirección MAC como el haproxy del nodo eth1, de manera que tendría que codificar a una de las dos puertas de enlace en cada servidor web.

¿Tiene usted algún tipo de software de seguridad instalado en el error de servidor web? Pasé una larga noche con un servidor de Windows 2008 que había Symantec Endpoint Security en él-se instala algunos de filtrado de código en la pila de red que le impide ver la puerta de entrada de paquetes ARP. La corrección para que (proporcionado por Microsoft), fue eliminar la entrada del registro que se ha cargado el archivo DLL.

La otra vez se ha producido este problema, la eliminación de toda adaptador de red desde el administrador de dispositivos y volver a instalar parecía 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: