Strana interruzione temporanea della rete in Linux

Sto affrontando un problema molto fastidioso che ho notato tra una settimana e per il quale non riesco a trovare una risposta: la mia rete smette improvvisamente di rispondere, di solito ritorna esattamente 25 secondi dopo. Stavo usando il kernel 3.10.4 e ora sono migrato a 3.11-rc4 per vedere se qualcosa è cambiato, ma no, il comportamento è lo stesso. E dal momento che è un problema difficile da individuare a causa del fatto che la navigazione normale è in "raffiche" e l'interruzione è completamente casuale, non posso davvero dire che questo problema era presente anche in un kernel precedente (uso sempre personalizzato ma kernel senza patch da kernel.org, tutti compilati da me stesso)

Non posso dire nemmeno che il kernel sia il colpevole, ma posso dire che non ci sono indizi sui log di sistema (ho controllato entrambi /var/log/sysloge /var/log/messagese non c'è nulla di insolito lì) e che l'hardware non sembra essere in errore, perché il problema mostra utilizzando una delle mie schede di rete:

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)

e ho già provato a scambiare le porte dello switch Ethernet e ancora nessun altro in cui lavoro ha un problema tranne me (anche se usiamo macchine simili, sono l'unico che usa Linux, quindi ho dovuto prendere alcune battute infami su di esso come bene ... hehe).

Ho funzionato su WireShark sulla mia macchina e l'ho lasciato ininterrottamente eseguendo il ping del nostro gateway e di un'altra macchina sullo stesso segmento di rete. Quindi, al primo segnale di malfunzionamento della rete, lo controllavo e verificavo che il gateway non rispondesse ai ping, ma l'altra macchina era ancora lì a rispondere normalmente. Altre volte è l'altra macchina che smette di rispondere e il gateway va bene, e altre volte entrambe smettono di rispondere. Non so cos'altro fare, quindi vorrei un aiuto o suggerimenti su come eseguire ulteriormente il debug, poiché i registri di sistema sono completamente normali.

Ho il mio file di configurazione del kernel e un file di acquisizione da WireShark che mostra la situazione. Posso pubblicare qui o in qualche sito pastebin nel caso qualcuno lo trovi utile per capire il caso, per favore fatemi sapere il livello di dettaglio che dovrei usare (suppongo che il livello del pacchetto senza i dati grezzi sarebbe sufficiente).

I sintomi sono coerenti con un conflitto di indirizzi IP. Un conflitto di indirizzi IP si verifica quando il tuo computer e altri computer sulla stessa rete stanno cercando di utilizzare lo stesso indirizzo IP .

Su una rete di collegamento locale, l'indirizzamento si basa su indirizzi MAC . Ogni scheda Ethernet ha il proprio indirizzo MAC (salvo errori di configurazione o malizia). Un router che decide dove inviare un pacchetto IP invierà una richiesta ARP per l'indirizzo IP di destinazione su tutte le sue porte. Quel messaggio è talvolta noto come "chi ha": il router sta cercando di scoprire quale dei suoi peer è responsabile di questo indirizzo IP. Una volta che il router riceve una risposta contenente un indirizzo MAC, può creare e inviare un frame Ethernet (pacchetto Ethernet) contenente il pacchetto IP a quell'indirizzo MAC. Poiché questo scambio richiede un po 'di tempo, il router conserva una cache di informazioni ARP recenti. (Esistono altri tipi di messaggi ARP, ma ciò che ho spiegato qui è sufficiente per comprendere il problema attuale.)

Quindi, in breve, i router devono sapere a quale dispositivo fisico ha ciascun indirizzo IP a cui stanno inviando pacchetti IP. Quindi cosa succede quando ci sono due dispositivi che rivendicano lo stesso indirizzo IP? Il router riceve una risposta da uno dei dispositivi e da quel momento in poi decide che questo indirizzo IP appartiene a quel dispositivo, fino alla scadenza della corrispondente voce della cache. Una volta scaduta la voce cache, il router invierà una nuova richiesta ARP e questa volta l'altro dispositivo risponderà più rapidamente. Questo spiega perché tali situazioni sono instabili: un minuto il router ti sta parlando, un minuto dopo sta parlando con l'altro ragazzo.

Se esegui continuamente il ping di qualcuno, il router mantiene praticamente sempre il tuo indirizzo IP nella sua cache ARP. Quindi, mentre esegui il ping, c'è solo una piccola finestra durante la quale l'altro può sostituirti nella cache (dopo la scadenza della voce della cache, prima che arrivi il ping successivo). Ecco perché l'osservazione del problema lo fa sparire, il che può essere frustrante fino a quando non ti rendi conto di quale potrebbe essere il problema.

Nel tuo caso, sembra che il tuo router locale mantenga le voci nella sua cache per 25 secondi. Quando sei nella cache, stai bene per 25 secondi. Poi a volte arriva l'altro ragazzo, in momenti dall'aspetto casuale, e te ne vai fuori per 25 secondi.

Quando si tenta di contattare più macchine sullo stesso collegamento locale, ognuna ha la propria tabella ARP, quindi è possibile osservare risultati incoerenti, con una macchina che decide di possedere l'indirizzo IP e un'altra macchina che decide che l'altro ragazzo lo fa.

I router di fascia alta registrano conflitti di indirizzi IP, quindi se pensi di trovarne uno, chiedi aiuto al tuo amministratore di sistema. Assicurati innanzitutto che non sia la tua macchina che sta cercando di utilizzare un indirizzo IP che non dovrebbe usare!

Sto per suggerire che hai 2 voci "nameserver" in /etc/resolv.conf, e la prima voce si riferisce a un server DNS che è inattivo o irraggiungibile o qualcosa di periodico. Il codice del resolver in libc proverà il primo indirizzo IP del nameserver, otterrà un timeout e quindi proverà il secondo indirizzo IP del nameserver, che avrà esito positivo.

Per verificarlo, è possibile sostituire gli indirizzi IP "nameserver" /etc/resolv.confcon un solo, 8.8.8.8, che è il server DNS pubblico di Google. Se l'interruzione non si verifica, il tuo nameserver è il problema.