Arresto anomalo della rete Linux: i migliori passi per scoprire la causa?

8

Uno dei nostri server Linux (CentOS) era irraggiungibile ieri sera.

Il server non era raggiungibile in alcun modo tranne che per la console remota. Dopo aver effettuato l'accesso con la console remota, non è stato possibile eseguire il ping di nessun host esterno.

Un semplice service network restartrisolto il problema, ma mi chiedo ancora cosa avrebbe potuto causare questo. I miei file di registro sembrano non indicare alcun errore (ad eccezione dei vari demoni che necessitano di una connessione di rete e falliscono dopo l'errore di rete).

È possibile eseguire ulteriori passaggi per scoprire la causa di questo problema?

EDIT : questo è appena successo di nuovo. Il server non ha risposto completamente finché non ho emesso un riavvio del servizio di rete. Qualsiasi consiglio è il benvenuto. Questo potrebbe essere causato da un componente hardware difettoso?

Come da richiesta di Madhatters, ecco alcuni estratti dal registro in quel momento (la rete si è schiantata alle 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.

I primi tre messaggi sono semplici risposte alle regole di iptables che ho impostato tramite il firewall LFD. L'ultimo messaggio indica che JungleDisk, che utilizzo per i backup, non può più connettersi al gateway. A parte questo, non ci sono messaggi interessanti in questo periodo.

MODIFICA 4 dic: come da richiesta di Mattdm, ecco l'output di ethtool eth0:

(Per favore, non che queste siano le impostazioni attualmente funzionanti . Se le cose dovessero andare di nuovo male, sarò sicuro di ripubblicare di nuovo se necessario.

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

Come da richiesta di Joris, ecco anche l'output di 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

Il xx.62 in basso è il mio gateway.

EDIT il 28 dicembre: il problema si è verificato di nuovo e ho avuto la possibilità di confrontare alcuni dei risultati dei test sopra. Quello che ho scoperto è che arp -anrestituisce un indirizzo MAC incompleto per il mio gateway (che non è sotto il mio controllo; il server si trova in un rack condiviso):

Durante il fallimento:

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

Dopo service network restart:

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

È qualcosa che posso risolvere o è tempo di contattare il data center?

linux networking centos

— Aron Rotteveel
fonte

Qualche possibilità di vedere i tronchi da quel momento, di cosa si lamentavano i demoni, ecc.?

— MadHatter il

Post modificato per includere una parte del registro in quel momento, anche se non c'è molto da vedere.

— Aron Rotteveel,

1

il riavvio di un servizio iptables risolve il problema o semplicemente il riavvio della rete di servizio?

— JakeRobinson l'

4

dai un'occhiata

dmesg | lessper tutto ciò che riguarda il tuo alias nic (cioè eht0) less /var/log/messagesaswell

Anche se raro potrebbe essere stato un conflitto di indirizzi IP, se ciò dovesse verificarsi di nuovo, prova

arping -U <gateway ip> -I <nic alias> Controlla questo, dato che è da molto tempo che non uso l'arping e questo potrebbe non essere corretto.

In caso di successo, è necessario ripristinare la connessione senza ricaricare il servizio di rete.

— Oneiroi
fonte

Ho controllato i log ma non riesco a trovare nulla che indichi un problema, a parte i vari errori demoni citati che indicano che la rete è appena caduta.

— Aron Rotteveel,

3

Come stai ottenendo il tuo indirizzo IP su questa rete (DHCP o statico)? Se succede di nuovo, assicurati di eseguire ifconfigper esaminare lo stato dell'interfaccia mentre è nel suo stato non funzionale. Ha un indirizzo? Ci sono errori? Se corri ethtool, c'è un link? (Ed è negoziato alla giusta velocità e duplex?)

— mattdm
fonte

L'indirizzo IP è statico. Ho eseguito ifconfig e l'interfaccia ha un indirizzo valido, nessun errore. Non ho corso eththool.

— Aron Rotteveel,

2

Corri ethtool. :)

— mattdm,

Bene, pubblicato :)

— Aron Rotteveel il

Questo darà un buon confronto - sarà interessante vedere cosa cambia quando c'è un problema.

— Mattdm,

2

Sulla base dei problemi riscontrati, sarei molto sospettoso di un conflitto di indirizzi IP. Il riavvio della rete invierebbe un ARP gratuito che riprenderebbe quell'IP, il che chiarirebbe le cose.

Mi piacerebbe installare arpwatch su un altro host nello stesso dominio di broadcast (stessa rete) e vedere se tutte le altre macchine stanno rispondendo alle richieste ARP per l'IP del server. In tal caso, scopri quale macchina (possibilmente utilizzando le tabelle degli indirizzi MAC dai tuoi switch per scoprire a quale porta è collegata) e impostalo su un altro indirizzo statico o DHCP.

— Jeff McJunkin
fonte

Se questo errore dovesse ripetersi, eseguirò anche un "arp -an"; in base a ciò che mostra per l'indirizzo gateway, aiuta a definire il prossimo passaggio per la risoluzione dei problemi.

— BMDan,

Eseguito un arp -an. Sembra che il mio gateway stia restituendo un ARP incompleto, ma non sono sicuro di cosa fare dopo.

— Aron Rotteveel,

1

Forse il pool di connessioni TCP si riempie? Qualcosa sta aprendo un numero sempre maggiore di connessioni, forse provando netstat(provare diverse opzioni, ad esempio -i per vedere le interfacce) darebbe informazioni sulla connessione aperta.

Se le connessioni effettive (e iptables / route / qualunque: configurazione you_are_using) siano ok, il problema potrebbe essere ad esempio nella configurazione dell'interfaccia di rete.

La tua ifconfig -aproduzione è sana? Tale output direbbe se si dispone di alcuni dispositivi di rete che non dovrebbero essere presenti, ad esempio i dispositivi virtuali, che causano il malfunzionamento dei pacchetti.

Questa tabella di routing che hai incollato sembra davvero strana. Funziona quando è così e cambia dopo che la connessione smette di funzionare? Se sì, qualcosa sta causando la modifica della tabella di routing, forse qualcosa correlato a iptables.

Infine, cosa specifica CentOS: hai NetworkManager in uso? È abilitato per impostazione predefinita in CentOS per qualche motivo, anche nelle macchine virtuali che non hanno X, rendendo questa connessione raddoppiata, instradando le modifiche e altre cose possibili. Suggerisco di spegnerlo a meno che tu non sappia di averne bisogno (come, avere connessioni che si accendono e si spengono).

— SMAR
fonte

1

Questo problema è stato risolto molto tempo fa: il problema era apparentemente legato all'hardware.

Una nuova scheda di rete ha risolto il problema.

— Aron Rotteveel
fonte

0

Da dove provi? All'interno della sottorete o al di fuori di essa? Quanti percorsi hai? La selezione automatica del gateway può fare cose apparentemente imprevedibili.

— Joris
fonte

Sto testando la connettività semplicemente eseguendo il ping di alcuni siti Web dal server e eseguendo il ping dall'esterno al server. Cosa intendi per numero di percorsi? Numero di rotte verso cosa?

— Aron Rotteveel,

2

mostra l'output di route -n? Quante rotte predefinite ci sono?

— Joris,

Grazie per la risposta. Inserito l'output nella domanda.

— Aron Rotteveel,

0

Non uso RedHat o CentOS, ma provo a guardare qualunque script venga chiamato quando si esegue un. service network restart. Dal momento che la rete torna alla normalità quando si verifica qualcosa in quello script, potrebbe essere utile ridurla.

— LawrenceC
fonte

-1

Hhhmm.

Forse una modifica accidentale a iptables? Può spiegare sia perché non era raggiungibile sia perché non c'è nulla di strano nei registri (probabilmente non registri iptables. Vero?)

— Nikolaidis Fotis
fonte

1

A service network restartnon cancella iptables.

— Oneiroi,

1

A seconda della configurazione, potrebbe ricostruire iptables. Non ho mai detto che il riavvio della rete li cancella. Se per alcuni motivi iptables fosse cambiato, il riavvio della rete potrebbe ripararli.

— Nikolaidis Fotis,