Extraña interrupción temporal de la red en Linux

Me enfrento a un problema muy molesto que noté dentro de una semana y para el que no puedo encontrar una respuesta: mi red de repente deja de responder, generalmente regresa exactamente 25 segundos después. Estaba usando el kernel 3.10.4 y ahora migré a 3.11-rc4 para ver si algo cambió, pero no, el comportamiento es el mismo. Y dado que es un problema difícil de detectar debido al hecho de que la navegación web habitual está en "ráfagas" y la interrupción es completamente aleatoria, realmente no puedo decir que este problema también estaba presente en un kernel anterior (siempre uso personalizado pero kernels sin parche de kernel.org, todos compilados por mí mismo)

No puedo decirle al núcleo es el culpable tampoco, pero puedo decir que no hay pistas sobre los registros del sistema (he comprobado tanto /var/log/syslogy /var/log/messagesy no hay nada inusual allí) y que el hardware no parece la culpa, para los espectáculos de problemas usando cualquiera de mis tarjetas de red:

lspci output:

02:00.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5751 Gigabit Ethernet PCI Express (rev 01)
04:00.0 Ethernet controller: 3Com Corporation 3c905B 100BaseTX [Cyclone] (rev 30)

y ya intenté intercambiar los puertos del conmutador de ethernet y todavía nadie más en el que trabajo tiene un problema excepto yo (aunque usamos máquinas similares, soy el único que usa Linux, así que tuve que tomar algunas bromas infames al respecto bueno ... jeje).

Subí a Wirehark en mi máquina y la dejé haciendo ping continuamente a nuestra puerta de enlace y a otra máquina en el mismo segmento de red. Luego, a la primera señal de mal funcionamiento de la red, lo verificaba y verificaba que la puerta de enlace dejara de responder pings, pero la otra máquina todavía estaba allí respondiendo normalmente. En otras ocasiones, la otra máquina deja de responder y la puerta de enlace está bien, y otras veces ambos dejan de responder. No sé qué más hacer, por lo que me gustaría obtener ayuda o consejos sobre cómo depurar esto, ya que los registros del sistema son completamente normales.

Tengo mi archivo de configuración del kernel y un archivo de captura de wireshark que muestra la situación. Puedo publicar aquí o en algún sitio de pastebin en caso de que a alguien le resulte útil entender el caso, solo háganme saber el nivel de detalle que debo usar (supongo que el nivel de paquete sin los datos en bruto sería suficiente).

Los síntomas son consistentes con un conflicto de dirección IP. Un conflicto de dirección IP surge cuando su máquina y alguna otra máquina en la misma red intentan usar la misma dirección IP .

En una red de enlace local, el direccionamiento se basa en direcciones MAC . Cada tarjeta Ethernet tiene su propia dirección MAC (salvo configuración incorrecta grave o malicia). Un enrutador que decida dónde enviar un paquete IP enviará una solicitud ARP para la dirección IP de destino en todos sus puertos. Ese mensaje a veces se conoce como "quién tiene": el enrutador está tratando de averiguar cuál de sus pares es responsable de esta dirección IP. Una vez que el enrutador recibe una respuesta que contiene una dirección MAC, puede construir y enviar una trama Ethernet (paquete Ethernet) que contiene el paquete IP a esa dirección MAC. Dado que este intercambio lleva un tiempo, el enrutador mantiene un caché de información ARP reciente. (Hay otros tipos de mensajes ARP, pero lo que he explicado aquí es suficiente para comprender el problema actual).

En pocas palabras, los enrutadores necesitan saber a qué dispositivo físico tienen cada dirección IP a la que envían paquetes IP. Entonces, ¿qué sucede cuando hay dos dispositivos que reclaman la misma dirección IP? El enrutador recibe una respuesta de uno de los dispositivos y, a partir de ese momento, decide que esta dirección IP pertenece a ese dispositivo, hasta que caduque la entrada de caché correspondiente. Después de que caduque la entrada de caché, el enrutador enviará una nueva solicitud ARP, y tal vez el otro dispositivo responderá más rápido esta vez. Esto explica por qué estas situaciones son inestables: un minuto el enrutador te está hablando a ti, al siguiente minuto está hablando con el otro tipo.

Si continuamente hace ping a alguien, el enrutador mantiene su dirección IP en su caché ARP casi todo el tiempo. Entonces, mientras hace ping, solo hay una pequeña ventana durante la cual el otro tipo puede reemplazarlo en el caché (después de que caduque su entrada de caché, antes de que llegue el próximo ping). Es por eso que observar el problema hace que desaparezca, lo que puede ser frustrante hasta que te des cuenta de cuál podría ser el problema.

En su caso, parece que su enrutador local mantiene las entradas en su caché durante 25 segundos. Cuando estás en el caché, eres bueno por 25 segundos. Luego, a veces viene el otro tipo, en momentos de aspecto aleatorio, y te quedas fuera por 25 segundos.

Cuando intenta contactar varias máquinas en el mismo enlace local, cada una tiene su propia tabla ARP, por lo que puede observar resultados inconsistentes, con una máquina que decide que posee la dirección IP y otra máquina que el otro tipo.

Los enrutadores de alta gama registran conflictos de direcciones IP, por lo que si cree que se encuentra con uno, solicite la ayuda del administrador del sistema. ¡Primero asegúrese de que no sea su máquina la que está tratando de usar una dirección IP que no debería usar!

Voy a sugerir que tenga 2 entradas de "servidor de nombres" /etc/resolv.conf, y la primera entrada se refiere a un servidor DNS que está inactivo o inaccesible o algo así periódicamente. El código de resolución en libc probará la primera dirección IP del servidor de nombres, obtendrá un tiempo de espera y luego probará la segunda dirección IP del servidor de nombres, que tiene éxito.

Para probar esto, puede reemplazar las direcciones IP del "servidor de nombres" /etc/resolv.confcon solo una, 8.8.8.8, que es el servidor DNS público de Google. Si no ocurre la interrupción, su servidor de nombres es el problema.