Windows 2008 ignora le richieste ARP gratuite


38

Di recente abbiamo riscontrato un problema dopo un failover del nostro router in cui i nostri box Windows 2008 non hanno iniziato a parlare con il router principale dopo il failback.

Quando abbiamo fatto qualche scavo avevano ancora la voce ARP dal router secondario. Secondo il Blog TechNet, questo è un progetto:

Innanzitutto, Windows Vista o Windows Server 2008 non aggiorneranno la cache Neighbor se viene ricevuta una trasmissione ARP a meno che non faccia parte di una richiesta ARP di trasmissione per il destinatario . Ciò significa che quando un ARP gratuito viene inviato su una rete con Windows Vista e Widows Server 2008, questi sistemi non aggiorneranno la cache con informazioni errate in caso di conflitto di indirizzi IP.

In secondo luogo, sembra che la cache di vicinato di Windows (arp-cache) sia aggiornata solo se la macchina non può più parlare con la macchina che si trova attualmente nella sua cache. Non invia richieste ARP occasionali per assicurarsi che la cache non sia obsoleta. Sebbene questo non sia un problema durante il failover iniziale, durante il failback quando entrambe le caselle sono attive, Windows continua a parlare con la casella secondaria.

Esiste un modo per forzare Windows 2008 ad accettare richieste ARP gratuite?


Risposte:


8

Dopo il test sembra che l' hotfix 2582281 risolva il problema. È possibile ottenere l'aggiornamento rapido senza dover pagare il supporto utilizzando la relativa pagina di richiesta di aggiornamento rapido .

Ho eseguito un test di questo utilizzando arpingWindows 2008 R2 senza patch. Ho aggiunto un IP secondario, 64.34.119.80, a una macchina con lo stesso segmento L2 di rete. Ho quindi emesso il seguente comando da una macchina diversa la rete ( sudo arping -U 64.34.119.80 -I bond0 -c1). Subito dopo, ho eseguito il ping 64.34.119.80 dalla finestra di Windows dopo averlo visto ricevere l'arp in WireShark. Ho quindi applicato l'aggiornamento rapido e ripetuto il test.

Inoltre, sembra che il comando arping non debba usare un indirizzo MAC unicast ma piuttosto il MAC broadcast perché questo è l'unico tipo di GARP ignorato dai miei test.

Prima della patch:

inserisci qui la descrizione dell'immagine

In questa acquisizione di wirehark, il ping dopo la richiesta GARP non viene inviato alla destinazione MAC da cui proviene il GARP, quindi puoi vedere che GARP viene ignorato.

Dopo la patch:

inserisci qui la descrizione dell'immagine

In questo test, dopo la patch, la richiesta GARP sembra essere onorata quando il ping viene inviato all'indirizzo MAC da cui proviene GARP.

Quindi da questi test sembra che l'aggiornamento rapido 2582281 risolva il problema delle trasmissioni GARP che venivano ignorate.


4

Durante la ricerca del mio problema TCPIP proprio ora, mi sono imbattuto in questo hotfix molto interessante:

http://support.microsoft.com/kb/2582281

Causa:

Questo problema si verifica perché lo stack TCP / IP del server delle applicazioni ignora erroneamente richieste ARP (Address Resolution Protocol) gratuite.

Questo suona molto simile a quello in cui ti imbatti. Ed è anche un nuovissimo aggiornamento rapido, rilasciato il 22/07/2011, quindi non esisteva quando l'hai incontrato per la prima volta.


Sembra che questo KB sia svanito?
Kyle Brandt,

@KyleBrandt Era lì, e ora non c'è più. Mi chiedo se il problema sia ora coperto da un service pack / aggiornamento altrove, possibilmente questo: support.microsoft.com/kb/2578103
sysadmin1138

3

Prova netsh interface ipv4 set interface x basereachable=ydove x è l'indice dell'interfaccia e y è il timeout ARP in millisecondi che desideri. Ricordati di farlo dal prompt dei comandi con privilegi di amministratore!


2
Ciò in realtà regola solo il tempo che intercorre tra il momento in cui la cache vicina ritiene che la voce sia obsoleta rispetto a quella raggiungibile. Se entrambe le caselle HA sono attive al momento del failback, Windows non lo vedrà mai come obsoleto e re-arp.
Zypher,

1
Non penso che ci sia un modo per forzare Windows ad accettare ARP gratuiti. In effetti, per questo motivo ho dovuto ridurre i tempi di base per raggiungere il failover / failback in uno scenario diverso.

3

Quale protocollo di ridondanza di primo hop stai usando?

Sono consapevole che questo non risponde direttamente alla tua domanda, tuttavia VRRP (e il suo antenato proprietario, HSRP) utilizzano un indirizzo MAC condiviso che viene capovolto su una nuova porta dello switch quando il router principale cambia. Ciò elude completamente la necessità di un ARP gratuito.


1

Prereqs
1. WinPCAP 4.0.1 (versione 4.1.2 non funziona)
- http://www.winpcap.org/archive/4.0.1-WinPcap.exe (versione Windows)
2. Wireshark 1.6.7
3. IPv6 disabilitato sull'interfaccia di rete, a causa delle restrizioni di arping
4. arping
- http://mathieu.carbou.free.fr/pub/arping/2.06/arping.zip (Windows Binary)

Esecuzione
1. Ottieni il nome dell'interfaccia
- "E: \ Programmi \ Wireshark \ tshark.exe "-D
- Dai dettagli dell'interfaccia di Wireshark
2. Eseguire l'arping, per inviare una richiesta gratuita ARP
- arping.exe -A -i \ Device \ NPF_ {4399F778-AF25-4B6D-AFFB-A1F2C7DFA667} 10.20.30.50 -c 3 -S 10.20.30.50
Dove 10.20.30.50 è l'indirizzo IP che si desidera annunciare alla rete (router)


-4

L'ho trovato sul link da http://blog.serverfault.com/post/windows-2008-and-broken-arp/ .

Se avessi chiesto su StackOverflow potresti aver avuto una soluzione molto più veloce.

Annusa i pacchetti GARP ed esegui arp -s inet_addr eth_addr.

Non farlo se esiste la possibilità più remota di ottenere una macchina ostile sulla LAN.


Non è davvero una soluzione. È una soluzione alternativa che funziona su una macchina. Il comportamento è ancora rotto. Tutto ciò che sta facendo è modificare manualmente l'indirizzo nella tabella arp, senza correggere la causa principale del comportamento.
Zypher,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.