La scheda di rete di Windows Server 2008 R2 smette di funzionare e richiede un riavvio forzato

TL; versione DR: si è scoperto che si trattava di un profondo bug di rete Broadcom in Windows Server 2008 R2. La sostituzione con hardware Intel l'ha risolto. Non utilizziamo più l'hardware Broadcom. Mai.

Abbiamo usato HAProxy insieme al battito cardiaco del progetto Linux-HA. Stiamo utilizzando due istanze di Linux per fornire un failover. Ogni server ha il proprio IP pubblico e un singolo IP condiviso tra i due tramite un'interfaccia virtuale (eth1: 1) su IP: 69.59.196.211

L'interfaccia virtuale (eth1: 1) IP 69.59.196.211 è configurata come gateway per i server Windows dietro di loro e usiamo ip_forwarding per instradare il traffico.

Stiamo vivendo un'interruzione di rete occasionale su uno dei nostri server Windows dietro i nostri gateway Linux. HAProxy rileverà che il server non è in linea, cosa che possiamo verificare remotando al server fallito e tentando di eseguire il ping del gateway:

Pinging 69.59.196.211 con 32 byte di dati:
Risposta del 69.59.196.220: Host di destinazione non raggiungibile.

L'esecuzione arp -asu questo server guasto indica che non esiste alcuna voce per l'indirizzo gateway (69.59.196.211):

Interfaccia: 69.59.196.220 --- 0xa
Indirizzo Internet Tipo di indirizzo fisico
69.59.196.161 00-26-88-63-c7-80 dinamico
69.59.196.210 00-15-5d-0a-3e-0e dinamico
69.59.196.212 00-21-5e-4d-45-c9 dinamico
69.59.196.213 00-15-5d-00-b2-0d dinamico
69.59.196.215 00-21-5e-4d-61-1a dinamico
69.59.196.217 00-21-5e-4d-2c-e8 dinamico
69.59.196.219 00-21-5e-4d-38-e5 dinamico
69.59.196.221 00-15-5d-00-b2-0d dinamico
69.59.196.222 00-15-5d-0a-3e-09 dinamico
69.59.196.223 ff-ff-ff-ff-ff-ff statico
224.0.0.22 01-00-5e-00-00-16 statico
224.0.0.252 01-00-5e-00-00-fc statico
225.0.0.1 01-00-5e-00-00-01 statico

Sul nostro gateway linux le istanze arp -amostrano:

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

Perché arp occasionalmente imposta la voce per questo server guasto su <incomplete>? Dovremmo definire staticamente le nostre voci arp? Ho sempre lasciato l'arp da solo poiché funziona il 99% delle volte, ma in questo caso sembra fallire. Ci sono ulteriori passaggi per la risoluzione dei problemi che possiamo prendere per aiutare a risolvere questo problema?

COSE CHE ABBIAMO PROVATO

Ho aggiunto una voce arp statica per i test su uno dei gateway Linux che ancora non ha aiutato.

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

Il riavvio del server Web Windows risolve temporaneamente questo problema senza altre modifiche alla rete, ma la nostra esperienza mostra che questo problema tornerà.

Scambio di schede di rete e switch

Ho notato che la spia di collegamento sulla porta dello switch per il server Windows non funzionante funzionava a 100 Mb anziché a 1 GB sull'interfaccia non riuscita. Ho spostato il cavo in diverse altre porte aperte e il collegamento indicava 100 Mb per ciascuna porta che ho provato. Ho anche scambiato il cavo con lo stesso risultato. Ho provato a modificare le proprietà della scheda di rete in Windows e il server si è bloccato e ho richiesto un hard reset dopo aver fatto clic su Applica. Questo server Windows ha due interfacce di rete fisiche, quindi ho scambiato i cavi e le impostazioni di rete sulle due interfacce per vedere se il problema segue l'interfaccia. Se l'interfaccia pubblica si interrompe, sapremo che non si tratta di un problema con la scheda di rete.

(Abbiamo anche provato un altro interruttore che abbiamo a portata di mano, nessun cambiamento)

Modifica delle versioni del driver hardware di rete

Abbiamo riscontrato lo stesso problema con l'ultimo driver Broadcom e con il driver integrato fornito in Windows Server 2008 R2.

Sostituzione dei cavi di rete

Come ultimo disperato tentativo, ci siamo ricordati di un altro cambiamento che è avvenuto nella sostituzione di tutti i cavi patch tra i nostri server / switch. Avevamo acquistato due set, uno verde di lunghezza 1ft - 3ft per le interfacce private e un altro set di cavi rossi per le interfacce pubbliche. Abbiamo sostituito tutti i cavi patch dell'interfaccia pubblica con un marchio diverso e abbiamo gestito i nostri server senza problemi per un'intera settimana ... aaaaae il problema si è ripresentato.

Disabilita il checksum offload, rimuovi TProxy

Abbiamo anche provato a disabilitare l'offload del checksum TCP / IP nel driver, nessuna modifica. Ora stiamo estraendo TProxy e ci spostiamo in una x-forwarded-fordisposizione di rete più tradizionale senza alcuna riscrittura sofisticata dell'indirizzo IP. Vedremo se questo aiuta.

Cambia provider di virtualizzazione

Per caso questo era in qualche modo correlato a Hyper-V (su di esso ospitiamo VM Linux), siamo passati a VMWare Server. Nessun cambiamento.

Cambia modello host

Abbiamo raggiunto la fine della nostra corda per la risoluzione dei problemi e ora stiamo formalmente coinvolgendo il supporto Microsoft. Hanno raccomandato di cambiare il modello host:

• http://en.wikipedia.org/wiki/Host_model
• http://technet.microsoft.com/en-us/magazine/2007.09.cableguy.aspx

Lo abbiamo fatto e abbiamo anche ottenuto alcuni hotfix del kernel non pubblicati che sono stati presumibilmente implementati in R2 SP1 2008. Nessuna correzione.

Sostituzione dell'hardware della scheda di rete

Alla fine, la sostituzione dell'hardware di rete Broadcom con l'hardware di rete Intel ha risolto questo problema per noi. Quindi sono propenso a pensare che i driver Broadcom Windows Server 2008 R2 siano in errore!

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

Da http://linux-ip.net/html/ether-arp.html :

Se non esiste alcuna voce cache ARP per un IP di destinazione richiesto, il kernel genererà richieste ARP mcast_solicit fino alla ricezione di una risposta. Durante questo periodo di rilevamento, la voce della cache ARP verrà elencata in uno stato incompleto. Se la ricerca non riesce dopo il numero specificato di richieste ARP, la voce della cache ARP verrà elencata in uno stato non riuscito. Se la ricerca ha esito positivo, il kernel inserisce la risposta nella cache ARP e reimposta i timer di conferma e aggiornamento.

Sembra che la tua casella gateway non risponda (o non risponda troppo lentamente) alle richieste ARP dalla tua casella gateway. Non che <incomplete>alla fine passare a <failed>? Quale hardware di rete hai tra il server e il gateway? È possibile che le richieste ARP di trasmissione vengano filtrate o bloccate da qualche parte tra i due host?

Significa che hai eseguito il ping dell'indirizzo, l'IP ha un record PTR (da cui il nome) ma non ha risposto nulla dalla macchina in questione. Quando vediamo questo è più comunemente dovuto a una subnet mask impostata in modo errato - o nel caso di IP associati a un'interfaccia di loopback che sono stati accidentalmente associati all'interfaccia eth.

Che cos'è 196.220? Qual è la sua relazione con 196.211? Suppongo che .220 sia uno degli host proxy HA. Quando esegui ifconfig -a & arp -a su di esso cosa mostra?

Come dice Max Clark, <incomplete> significa solo che 69.59.196.211 ha emesso una richiesta ARP per 69.59.196.220 e non ha ancora ricevuto una risposta. (In Windows-Land vedrai questo come un mapping ARP su "00-00-00-00-00-00" ... Mi sembra strano, BTW, che non vedi un tale mapping ARP su 69.59.196.220 per 69.59.196.211.)

Tendo a non usare voci ARP statiche perché, in base alla mia esperienza, in genere ARP ha sempre svolto il proprio lavoro.

Se fossi in me, annuserei l'interfaccia Ethernet appropriata sulla macchina Windows "non riuscita" (69.59.196.220) per osservarla ARP per 69.59.196.211 e per osservare come / se risponde alle richieste ARP da 69.59. 196,211. Considererei anche di annusare la macchina gateway solo per ARP ( tcpdump -i interface-name arp) per vedere come appare il traffico ARP dal lato della macchina Linux.

So che dal blog hai una rete back-end e una rete front-end. Durante queste interruzioni, il server Windows "in errore" (69.59.196.220) ha qualche problema di comunicazione con altre macchine nella rete front-end o ha problemi a parlare con il suo gateway? Sono curioso di sapere se stai arrivando alla macchina guasta attraverso la rete front-end o back-end quando la stai intercettando.

Cosa stai facendo per "risolvere" il problema quando si verifica?

Modificare:

Dal tuo aggiornamento vedo che stai riavviando il computer Windows "non riuscito" per risolvere il problema. Prima di farlo la prossima volta, puoi verificare che il computer Windows sia in grado di "parlare" sulla sua interfaccia front-end? Inoltre, prendi una copia della tabella di routing dal computer Windows ( route print) anche durante un errore. (Sto cercando di accertare se la scheda NIC / driver sta andando in rovina sul computer Windows, in pratica.)

Questo documento mostra i diversi stati (tabella 2.1). Incompleto significherebbe che ha inviato una prima richiesta ARP (presumibilmente dopo uno stantio, un ritardo, un sondaggio) ma non ha ancora ricevuto una risposta.

Il motivo per cui l'ARP statico sul nodo haproxy non aiuta è che il tuo server web non riesce ancora a capire come tornare al gateway.

L'ARP statico sul server Web interrompe la capacità dei server Web di cambiare gateway in caso di errore di uno dei nodi haproxy: suppongo che l'interfaccia virtuale condivida lo stesso indirizzo MAC dell'eth1 del nodo haproxy, quindi è necessario codice a uno dei due gateway in ciascun server web.

Hai qualche tipo di software di sicurezza installato sul web server in errore? Ho trascorso una lunga notte con un server Windows 2008 su cui era installato Symantec Endpoint Security: installa un codice di filtro nello stack di rete che gli ha impedito di vedere i pacchetti ARP del gateway. La correzione per questo (come fornita da Microsoft) era rimuovere la voce di registro che caricava la DLL.

L'altra volta che si è verificato questo problema, la rimozione dell'intera scheda di rete da Gestione dispositivi e la reinstallazione sembravano aiutare.

Dato che hai impostato staticamente la tua voce arp, i tuoi server sanno dove trovare il gateway. Tuttavia, se lo switch non sa dove si trova il gateway, non inoltrerà i pacchetti.

Sembra che tu abbia un passaggio errato (o confuso) tra i tuoi HAproxy e i tuoi server web. Riavvialo.

O quello, oi tuoi server HAproxy non sono d'accordo su quale sia il controllo, ed entrambi rispondono alle ricerche arp per .211.

Sulla stessa linea, se il tuo switch è sovraccarico, i tuoi proxy HA potrebbero non essere in grado di comunicare tra loro abbastanza velocemente e stanno fallendo.

La prossima volta che si verifica questo problema, suggerirei di eseguire alcune acquisizioni di pacchetti sui due host in questione, per determinare quale traffico ARP sta osservando ciascuno di essi.

Molto probabilmente la tua macchina HAproxy avrà un po 'di sapore di tcpdump installato. Per la macchina Windows avrai bisogno di un'applicazione WinPCAP , come Wireshark o Microsoft Network Monitor .

In effetti, a pensarci bene, dato che il problema sembra specifico con ARP, potresti potenzialmente registrare continuamente tutto il traffico ARP sul computer HAproxy e sul computer Windows in questione, con un file di acquisizione a rotazione di 10 MB (per l'argomento). Dovrebbe essere abbastanza grande in modo tale che quando si rileva un errore, il file di acquisizione conterrà ancora il traffico ARP prima dell'errore. (Vale la pena sperimentare eseguendo l'acquisizione per circa un'ora per vedere quanti dati genera).

Sintassi di cattura di esempio per Linux tcpdump (nota, non ho una Linux box a portata di mano per testarlo; si prega di testare il comportamento di -C e -W prima dell'uso in produzione!):

tcpdump -C 10 -i eth1 -w /var/tmp/arp.cap -W 1 arp

Questo dovrebbe sperare di darti qualche indizio su cosa stia proprio fallendo. Alla scadenza di una voce ARP (e in base a questo articolo , le versioni più recenti di Windows sembrano invecchiare le voci "inattive" in modo molto aggressivo), mi aspetto che ciò accada:

1. L'host di origine invierà una richiesta ARP all'host di destinazione. Le richieste ARP vengono generalmente trasmesse, ma nel caso in cui un host stia aggiornando una voce esistente, l'ARP può essere inviato unicast.
2. L'host di destinazione risponderà con una risposta ARP. Il 99% delle volte sarà unicast, ma la RFC consente risposte broadcast. (Vedi anche la RFC per quanto riguarda il rilevamento delle collisioni di indirizzi IPv4 per maggiori dettagli).

Semplice come sembra, ci sono un sacco di altre cose che possono interferire con questo processo:

• La richiesta originale potrebbe non arrivare al target.
• La richiesta potrebbe arrivare all'obiettivo, ma la risposta potrebbe non raggiungere la fonte.
• Una sorta di meccanismo ad alta disponibilità potrebbe interferire con il comportamento "normale" di ARP:
  • Come funziona il failover tra i nodi HAProxy? Utilizza un indirizzo MAC condiviso o utilizza ARP gratuito per il failover di un indirizzo IP tra nodi?
  • Molti degli indirizzi MAC nelle tabelle ARP sopra iniziano con 00-15-5D, che è apparentemente registrato su Microsoft. Stai usando qualche forma di clustering o altri HA sul computer Windows in questione? Questi indirizzi MAC 00-15-5D sono gli stessi che vedi associati alle schede NIC hardware quando esegui un 'ipconfig / all' sul server Windows?

Cose da verificare se / quando questo accade di nuovo:

• Guarda le acquisizioni di pacchetti del traffico ARP; qualche parte della conversazione ovviamente non è avvenuta?
• Controllare le tabelle di bridge / CAM dell'interruttore; tutti gli indirizzi MAC in questione sono associati alle porte che ti aspetti?
• Gli altri host nella sottorete hanno voci ARP valide per gli indirizzi IP degli host Windows e HAProxy?
• Le voci ARP per lo stesso IP di destinazione su più macchine di origine diverse vengono risolte nello stesso indirizzo MAC? vale a dire accedere a un paio di altri host sulla sottorete e verificare che 196.211 si risolva nello stesso indirizzo MAC su entrambi.

Abbiamo avuto un problema simile con uno dei nostri terminal server 2008 R2 in cui tutto il traffico sulla NIC si fermava ma rimaneva connesso e i LED della NIC mostravano comunicazioni. Questo era un problema in corso che continuava a spuntare 2-3 volte a settimana, ma solo dopo circa 12-13 ore di operatività (il server viene riavviato di notte).

Ho scoperto che Seriousbit Netbalancer era la causa, dopo aver provato (per curiosità) a terminare il servizio NetbalancerService. Il traffico ha quindi iniziato a spostarsi attraverso l'interfaccia. Da allora ho disinstallato Netbalancer.

Ho avuto lo stesso problema con Asus Mainboard lan. È stato risolto installando un driver più recente dal sito Web realtek