Accidente de red de Linux: ¿los mejores pasos para descubrir la causa?

8

Uno de nuestros servidores Linux (CentOS) fue inalcanzable anoche.

No se pudo acceder al servidor de ninguna manera, excepto para la consola remota. Después de iniciar sesión con la consola remota, resultó que tampoco podía hacer ping a ningún host externo.

A simple service network restartresolvió el problema, pero todavía me pregunto qué pudo haber causado esto. Mis archivos de registro parecen indicar que no hay ningún error (a excepción de los diversos demonios que necesitan una conexión de red y fallaron después de la falla de la red).

¿Hay algún paso adicional que pueda tomar para averiguar la causa de este problema?

EDITAR : esto acaba de suceder nuevamente. El servidor no respondió por completo hasta que emití un reinicio del servicio de red. Cualquier consejo es bienvenido. ¿Podría esto ser causado por un componente de hardware defectuoso?

Según la solicitud de Madhatters, aquí hay algunos extractos del registro en ese momento (la red se bloqueó a las 20:13):

/ var / log / messages:

Dec  2 20:01:05 graviton kernel: Firewall: *TCP_IN Blocked* IN=eth0 OUT= MAC=<stripped> SRC=<stripped> DST=<stripped> LEN=40 TOS=0x00 PREC=0x00 TTL=101 ID=256 PROTO=TCP SPT=6000 DPT=3306 WINDOW=16384 RES=0x00 SYN URGP=0
Dec  2 20:01:05 graviton kernel: Firewall: *TCP_IN Blocked* IN=eth0 OUT= MAC=<stripped> SRC=<stripped> DST=<stripped> LEN=40 TOS=0x00 PREC=0x00 TTL=100 ID=256 PROTO=TCP SPT=6000 DPT=3306 WINDOW=16384 RES=0x00 SYN URGP=0
Dec  2 20:01:05 graviton kernel: Firewall: *TCP_IN Blocked* IN=eth0 OUT= MAC=<stripped> SRC=<stripped> DST=<stripped> LEN=40 TOS=0x00 PREC=0x00 TTL=101 ID=256 PROTO=TCP SPT=6000 DPT=3306 WINDOW=16384 RES=0x00 SYN URGP=0
Dec  2 20:13:34 graviton junglediskserver: Connection to gateway failed: xGatewayTransport - Connection to gateway failed.

Los primeros tres mensajes son respuestas simples a las reglas de iptables que configuré a través del firewall LFD. El último mensaje indica que JungleDisk, que uso para las copias de seguridad, ya no puede conectarse a la puerta de enlace. Aparte de esto, no hay mensajes interesantes en este momento.

EDIT 4 dic: según la solicitud de Mattdm, aquí está la salida de ethtool eth0:

(Por favor, no es que estas son las configuraciones que funcionan actualmente . Si las cosas vuelven a fallar, me aseguraré de publicar esto nuevamente si es necesario.

Settings for eth0:
        Supported ports: [ TP ]
        Supported link modes:   10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
                                1000baseT/Full
        Supports auto-negotiation: Yes
        Advertised link modes:  10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
                                1000baseT/Full
        Advertised auto-negotiation: Yes
        Speed: 1000Mb/s
        Duplex: Full
        Port: Twisted Pair
        PHYAD: 1
        Transceiver: internal
        Auto-negotiation: on
        Supports Wake-on: g
        Wake-on: d
        Link detected: yes

Según la solicitud de Joris, aquí también está la salida de route -n:

aron@graviton [~]# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
xx.xx.xx.58    0.0.0.0         255.255.255.255 UH    0      0        0 eth0
xx.xx.xx.42    0.0.0.0         255.255.255.255 UH    0      0        0 eth0
xx.xx.xx.43    0.0.0.0         255.255.255.255 UH    0      0        0 eth0
xx.xx.xx.41    0.0.0.0         255.255.255.255 UH    0      0        0 eth0
xx.xx.xx.46    0.0.0.0         255.255.255.255 UH    0      0        0 eth0
xx.xx.xx.47    0.0.0.0         255.255.255.255 UH    0      0        0 eth0
xx.xx.xx.44    0.0.0.0         255.255.255.255 UH    0      0        0 eth0
xx.xx.xx.45    0.0.0.0         255.255.255.255 UH    0      0        0 eth0
xx.xx.xx.50    0.0.0.0         255.255.255.255 UH    0      0        0 eth0
xx.xx.xx.51    0.0.0.0         255.255.255.255 UH    0      0        0 eth0
xx.xx.xx.48    0.0.0.0         255.255.255.255 UH    0      0        0 eth0
xx.xx.xx.49    0.0.0.0         255.255.255.255 UH    0      0        0 eth0
xx.xx.xx.54    0.0.0.0         255.255.255.255 UH    0      0        0 eth0
xx.xx.xx.52    0.0.0.0         255.255.255.255 UH    0      0        0 eth0
xx.xx.xx.53    0.0.0.0         255.255.255.255 UH    0      0        0 eth0
xx.xx.xx.0     0.0.0.0         255.255.255.192 U     0      0        0 eth0
xx.xx.xx.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0
169.254.0.0     0.0.0.0         255.255.0.0     U     0      0        0 eth0
0.0.0.0         xx.xx.xx.62    0.0.0.0         UG    0      0        0 eth0

La parte inferior xx.62 es mi puerta de enlace.

EDITAR 28 de diciembre: el problema volvió a ocurrir y tuve la oportunidad de comparar algunos de los resultados de las pruebas anteriores. Lo que descubrí es que arp -andevuelve una dirección MAC incompleta para mi puerta de enlace (que no está bajo mi control; el servidor está en un rack compartido):

Durante el fracaso:

? (xx.xx.xx.62) at <incomplete> on eth0

Después service network restart:

? (xx.xx.xx.62) at 00:00:0C:9F:F0:30 [ether] on eth0

¿Es algo que puedo solucionar o es hora de que me comunique con el centro de datos?

linux networking centos

— Aron Rotteveel
fuente

¿Alguna posibilidad de ver los registros de todo el tiempo, de qué se quejaron los demonios, etc.?

— MadHatter

Publicación editada para incluir una parte del registro en ese momento, aunque no hay mucho interesante para ver.

— Aron Rotteveel

1

¿Un servicio de reinicio de iptables soluciona el problema, o simplemente reinicia la red de servicio?

— JakeRobinson

4

cheque

dmesg | lesspara cualquier cosa relacionada con su alias nic (es decir, eht0) less /var/log/messagestambién

Si bien es raro que podría haber sido un conflicto de dirección IP, si esto ocurriera nuevamente, intente

arping -U <gateway ip> -I <nic alias> Sin embargo, verifique esto, ya que ha pasado mucho tiempo desde que usé arping y esto puede ser incorrecto.

Si tiene éxito, debe recuperar la conexión sin volver a cargar el servicio de red.

— Oneiroi
fuente

He revisado los registros, pero no puedo encontrar nada que indique un problema, aparte de los diversos errores de daemon mencionados que indican que la red se ha caído.

— Aron Rotteveel

3

¿Cómo obtiene su dirección IP en esta red (DHCP o estática)? Si vuelve a suceder, asegúrese de ejecutar ifconfigpara ver el estado de la interfaz mientras está en su estado no funcional. ¿Tiene una dirección? ¿Hay errores? Si corres ethtool, ¿hay un enlace? (¿Y se negocia con la velocidad y el dúplex correctos?)

— mattdm
fuente

La dirección IP es estática. Ejecuté ifconfig y la interfaz tiene una dirección válida, sin errores. No he corrido eththool.

— Aron Rotteveel

2

Ejecutar ethtool. :)

— mattdm

— Muy

Eso proporcionará una buena comparación: será interesante ver qué cambios hay cuando hay un problema.

— mattdm

2

Según los problemas encontrados, sospecho mucho de un conflicto de dirección IP. Reiniciar la red enviaría un ARP gratuito que se haría cargo de esa IP nuevamente, lo que aclararía las cosas.

Instalaría arpwatch en otro host en el mismo dominio de difusión (misma red) y vería si otras máquinas están respondiendo a las solicitudes ARP para la IP de su servidor. Si es así, averigüe qué máquina (posiblemente usando tablas de direcciones MAC de sus conmutadores para averiguar a qué puerto está conectado) y configúrelo en otra dirección estática o DHCP.

— Jeff McJunkin
fuente

Si este error ocurre nuevamente, también ejecutaría un "arp -an"; según lo que eso muestra para la dirección de la puerta de enlace, ayuda a definir su próximo paso de solución de problemas.

— BMDan

Ejecuté un arp -an. Parece que mi puerta de enlace está devolviendo un ARP incompleto, pero no estoy seguro de qué hacer a continuación.

— Aron Rotteveel

1

¿Quizás el grupo de conexiones TCP se llena? Algo está abriendo más y más conexiones, tal vez intentar netstat(probar diferentes opciones, por ejemplo -i para ver las interfaces) daría una idea sobre la conexión abierta.

Si las conexiones reales (e iptables / routes / whatever: you_are_using configuration) están bien, el problema podría estar, por ejemplo, en la configuración de la interfaz de red.

¿Su ifconfig -aproducción es sensata? Esa salida indicaría si tiene algunos dispositivos de red que no deberían estar presentes, por ejemplo, dispositivos virtuales, que está causando que los paquetes se vuelvan locos.

Esta tabla de enrutamiento que ha pegado se ve realmente extraña. ¿Funciona cuando es así y cambia después de que la conexión deja de funcionar? En caso afirmativo, algo está causando el cambio de la tabla de enrutamiento, tal vez algo relacionado con iptables.

Finalmente, algo específico de CentOS: ¿tiene NetworkManager en uso? Está habilitado de forma predeterminada en CentOS por alguna razón, incluso en máquinas virtuales que no tienen X, lo que hace que esta conexión se duplique, los cambios de enrutamiento y otras cosas posibles. Sugiero apagarlo a menos que sepa que lo necesita (como tener conexiones que se encienden y apagan).

— Smar
fuente

1

Este problema se resolvió hace bastante tiempo: aparentemente estaba relacionado con el hardware.

Una nueva NIC ha resuelto el problema.

— Aron Rotteveel
fuente

0

¿De dónde estás probando? ¿Dentro de la subred o fuera de ella? ¿Cuántas rutas tienes? La selección de puerta de enlace automática puede hacer cosas aparentemente impredecibles.

— Joris
fuente

Estoy probando la conectividad simplemente haciendo ping a algunos sitios web desde el servidor y haciendo ping desde el exterior al servidor. ¿Qué quieres decir con el número de rutas? ¿Número de rutas a qué?

— Aron Rotteveel

2

muestra la salida de la ruta -n? ¿Cuántas rutas predeterminadas hay?

— Joris

Gracias por la respuesta. Publicado el resultado en la pregunta.

— Aron Rotteveel

0

No uso RedHat o CentOS, pero intente mirar el script que se llama cuando lo hace. service network restart. Dado que su red vuelve a la normalidad cuando ocurre algo en ese script, puede ayudar a reducirlo.

— LawrenceC
fuente

-1

Hhhmm

Tal vez un cambio accidental a iptables? Puede explicar tanto por qué no fue accesible como por qué no hay nada extraño en los registros (probablemente no registres iptables. ¿Verdad?)

— Nikolaidis Fotis
fuente

1

A service network restartno borra iptables.

— Oneiroi

1

Dependiendo de su configuración, puede reconstruir iptables. Nunca mencioné que el reinicio de la red los borra. Si por alguna razón se cambiaron iptables, el reinicio de la red podría repararlos.

— Nikolaidis Fotis