it-swarm.com.de

Der Windows Server 2008 R2-Netzwerkadapter funktioniert nicht mehr und muss neu gestartet werden

TL; DR-Version: Es stellte sich heraus, dass dies ein schwerwiegender Broadcom-Netzwerkfehler in Windows Server 2008 R2 war. Das Ersetzen durch Intel-Hardware hat das Problem behoben. Wir verwenden keine Broadcom-Hardware mehr. Immer.

Wir haben HAProxy zusammen mit Herzschlag aus dem Linux-HA-Projekt verwendet. Wir verwenden zwei Linux-Instanzen, um ein Failover bereitzustellen. Jeder Server verfügt über eine eigene öffentliche IP-Adresse und eine einzelne IP-Adresse, die von beiden über eine virtuelle Schnittstelle (eth1: 1) unter IP: 69.59.196.211 gemeinsam genutzt wird

Die virtuelle Schnittstelle (eth1: 1) IP 69.59.196.211 ist als Gateway für die dahinter liegenden Windows-Server konfiguriert, und wir verwenden ip_forwarding, um den Datenverkehr weiterzuleiten.

Auf einem unserer Windows-Server hinter unseren Linux-Gateways tritt gelegentlich ein Netzwerkausfall auf. HAProxy erkennt, dass der Server offline ist. Dies können wir überprüfen, indem wir ein Remoting auf den ausgefallenen Server durchführen und versuchen, das Gateway zu pingen:

 Ping 69.59.196.211 mit 32 Datenbytes: 
 Antwort von 69.59.196.220: Zielhost nicht erreichbar. 

Laufen arp -a auf diesem ausgefallenen Server zeigt an, dass kein Eintrag für die Gateway-Adresse (69.59.196.211) vorhanden ist:

 Schnittstelle: 69.59.196.220 --- 0xa 
 Typ der physischen Internetadresse 
 69.59.196.161 00-26-88-63-c7-80 dynamic 
 69.59 .196.210 00-15-5d-0a-3e-0e dynamisch 
 69.59.196.212 00-21-5e-4d-45-c9 dynamisch 
 69.59.196.213 00-15-5d-00- b2-0d dynamisch 
 69.59.196.215 00-21-5e-4d-61-1a dynamisch 
 69.59.196.217 00-21-5e-4d-2c-e8 dynamisch 
 69.59 .196.219 00-21-5e-4d-38-e5 dynamisch 
 69.59.196.221 00-15-5d-00-b2-0d dynamisch 
 69.59.196.222 00-15-5d-0a- 3e-09 dynamisch 
 69.59.196.223 ff-ff-ff-ff-ff-ff statisch 
 224.0.0.22 01-00-5e-00-00-16 statisch 
 224.0 .0.252 01-00-5e-00-00-fc statisch 
 225.0.0.1 01-00-5e-00-00-01 statisch 

Auf unseren Linux-Gateway-Instanzen arp -a zeigt an:

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

Warum sollte arp gelegentlich den Eintrag für diesen ausgefallenen Server als <unvollständig> festlegen? Sollten wir unsere arp-Einträge statisch definieren? Ich habe arp immer alleine gelassen, da es 99% der Zeit funktioniert, aber in diesem einen Fall scheint es zu scheitern. Gibt es zusätzliche Schritte zur Fehlerbehebung, mit denen wir dieses Problem beheben können?

DINGE WE HABEN VERSUCHT

Ich habe einen statischen Arp-Eintrag zum Testen auf einem der Linux-Gateways hinzugefügt, was immer noch nicht geholfen hat.

[email protected]:~# 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

[email protected]:~# arp -i eth1 -s 69.59.196.220 00:21:5e:4d:30:8d
[email protected]:~# 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

Durch einen Neustart des Windows-Webservers wird dieses Problem vorübergehend ohne weitere Änderungen am Netzwerk behoben. Unsere Erfahrung zeigt jedoch, dass dieses Problem erneut auftritt.

Netzwerkkarten und Switches austauschen

Ich habe festgestellt, dass die Verbindungsleuchte am Port des Switches für den ausgefallenen Windows-Server mit 100 MB anstelle von 1 GB auf der ausgefallenen Schnittstelle ausgeführt wurde. Ich habe das Kabel an mehrere andere offene Ports verlegt und die Verbindung zeigte 100 MB für jeden Port an, den ich ausprobiert habe. Ich habe auch das Kabel mit dem gleichen Ergebnis getauscht. Ich habe versucht, die Eigenschaften der Netzwerkkarte in Windows zu ändern, und der Server wurde gesperrt. Nach dem Klicken auf Übernehmen musste ein Hard-Reset durchgeführt werden. Dieser Windows-Server verfügt über zwei physische Netzwerkschnittstellen. Daher habe ich die Kabel und Netzwerkeinstellungen der beiden Schnittstellen ausgetauscht, um festzustellen, ob das Problem der Schnittstelle folgt. Wenn die öffentliche Schnittstelle wieder ausfällt, wissen wir, dass dies kein Problem mit der Netzwerkkarte ist.

(Wir haben auch einen anderen Schalter ausprobiert, keine Änderung)

Ändern der Netzwerkhardwaretreiberversionen

Wir hatten das gleiche Problem mit dem neuesten Broadcom-Treiber sowie dem integrierten Treiber, der in Windows Server 2008 R2 enthalten ist.

Netzwerkkabel ersetzen

Als letzten Versuch erinnerten wir uns an eine weitere Änderung, die darin bestand, alle Patchkabel zwischen unseren Servern/Switches auszutauschen. Wir hatten zwei Sets gekauft, ein grünes mit einer Länge von 1 bis 3 Fuß für die privaten Schnittstellen und ein weiteres rotes Kabel für die öffentlichen Schnittstellen. Wir haben alle Patchkabel der öffentlichen Schnittstelle gegen eine andere Marke ausgetauscht und unsere Server eine ganze Woche lang ohne Probleme betrieben ... aaaaaund dann trat das Problem erneut auf.

Prüfsummen-Offload deaktivieren, TProxy entfernen

Wir haben auch versucht, das Auslagern der TCP/IP-Prüfsumme im Treiber zu deaktivieren, keine Änderung. Wir ziehen jetzt TProxy heraus und wechseln zu einem traditionelleren x-forwarded-for Netzwerkanordnung ohne ausgefallenes Umschreiben der IP-Adresse. Wir werden sehen, ob das hilft.

Virtualisierungsanbieter wechseln

Da dies in irgendeiner Weise mit Hyper-V zu tun hatte (wir hosten Linux-VMs darauf), wechselten wir zu VMWare Server. Keine Änderung.

Host-Modell wechseln

Wir haben das Ende unserer Fehlerbehebung erreicht und beziehen jetzt offiziell den Microsoft-Support ein. Sie empfahlen, das Host-Modell zu ändern:

Wir haben das getan und auch einige unveröffentlichte Kernel-Hotfixes erhalten, die vermutlich in 2008 R2 SP1 integriert wurden. Keine Reparatur.

Ersetzen der Netzwerkkartenhardware

Letztendlich hat das Ersetzen der Broadcom-Netzwerkhardware durch Intel-Netzwerkhardware dieses Problem für uns behoben. Daher bin ich geneigt zu glauben, dass die Broadcom Windows Server 2008 R2-Treiber schuld sind!

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

32
Geoff Dalgas

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

Wenn für eine angeforderte Ziel-IP kein ARP-Cache-Eintrag vorhanden ist, generiert der Kernel mcast_solicit-ARP-Anforderungen, bis eine Antwort empfangen wird. Während dieses Erkennungszeitraums wird der ARP-Cache-Eintrag in einem unvollständigen Zustand aufgelistet. Wenn die Suche nach der angegebenen Anzahl von ARP-Anforderungen nicht erfolgreich ist, wird der ARP-Cache-Eintrag in einem fehlgeschlagenen Zustand aufgelistet. Wenn die Suche erfolgreich ist, gibt der Kernel die Antwort in den ARP-Cache ein und setzt die Bestätigungs- und Aktualisierungszeitgeber zurück.

Es sieht so aus, als ob Ihre Gateway-Box nicht (oder zu langsam) auf ARP-Anfragen von Ihrer Gateway-Box reagiert. Macht das <incomplete> wechsle schließlich zu <failed>? Welche Netzwerkhardware haben Sie zwischen dem Server und dem Gateway? Ist es möglich, dass Broadcast-ARP-Anforderungen irgendwo zwischen den beiden Hosts gefiltert oder blockiert werden?

7
user32399

Dies bedeutet, dass Sie die Adresse gepingt haben, die IP einen PTR-Eintrag (daher der Name) hat, aber von dem betreffenden Computer nichts geantwortet hat. Wenn wir dies sehen, liegt dies am häufigsten daran, dass eine Subnetzmaske falsch eingestellt ist - oder im Fall von IPs, die an eine Loopback-Schnittstelle gebunden sind, die stattdessen versehentlich an die eth-Schnittstelle gebunden wurden.

Was ist 196.220? Wie ist die Beziehung zu 196.211? Ich gehe davon aus, dass .220 einer der HA-Proxy-Hosts ist. Wenn Sie ifconfig -a & arp -a darauf ausführen, was wird angezeigt?

5
Max Clark

Wie Max Clark sagt, bedeutet <unvollständig> nur, dass 69.59.196.211 eine ARP-Anfrage für 69.59.196.220 gesendet hat und noch keine Antwort erhalten hat. (In Windows-Land wird dies als ARP-Zuordnung zu "00-00-00-00-00-00" angezeigt. Übrigens erscheint es mir seltsam, dass Sie eine solche ARP-Zuordnung nicht sehen 69.59.196.220 für 69.59.196.211.)

Ich mag es nicht, statische ARP-Einträge zu verwenden, da ARP meiner Erfahrung nach im Allgemeinen immer seine Arbeit erledigt hat.

Wenn ich es wäre, würde ich die entsprechende Ethernet-Schnittstelle auf dem "fehlerhaften" Windows-Computer (69.59.196.220) abhören, um zu beobachten, wie ARP für 69.59.196.211 ausgeführt wird, und um zu beobachten, wie/ob auf ARP-Anforderungen von 69.59 reagiert wird. 196.211. Ich würde auch in Betracht ziehen, nur für ARP auf dem Gateway-Computer zu schnüffeln (tcpdump -i interface-name arp) um zu sehen, wie der ARP-Verkehr von der Seite des Linux-Computers aus aussieht.

Ich weiß aus dem Blog , dass Sie ein Back-End-Netzwerk und ein Front-End-Netzwerk haben. Hat der "fehlerhafte" Windows-Server (69.59.196.220) während dieser Ausfälle Probleme mit der Kommunikation mit anderen Computern im Front-End-Netzwerk oder hat er nur Probleme mit der Kommunikation mit seinem Gateway? Ich bin gespannt, ob Sie über das Front-End- oder Back-End-Netzwerk an den fehlerhaften Computer gelangen, wenn Sie ihn auf frischer Tat ertappen.

Was tun Sie, um das Problem zu "beheben", wenn es auftritt?

Bearbeiten:

Aus Ihrem Update geht hervor, dass Sie den "fehlerhaften" Windows-Computer neu starten, um das Problem zu beheben. Können Sie vor dem nächsten Mal überprüfen, ob der Windows-Computer überhaupt auf seiner Front-End-Oberfläche "sprechen" kann? Holen Sie sich außerdem eine Kopie der Routing-Tabelle vom Windows-Computer (route print) auch während eines Ausfalls. (Ich versuche festzustellen, ob der Treiber NIC /) auf dem Windows-Computer im Grunde genommen verrückt wird.)

4
Evan Anderson

Dieses Dokument zeigt die verschiedenen Zustände (Tabelle 2.1). Unvollständig würde bedeuten, dass eine erste ARP-Anfrage gesendet wurde (vermutlich nach einem veralteten, verzögerten Test), aber noch keine Antwort erhalten hat.

2
Cade Roux

Der Grund, warum das statische ARP auf dem Haproxy-Knoten nicht hilft, ist, dass Ihr Webserver immer noch nicht herausfinden kann, wie Sie zum Gateway zurückkehren können.

Statisches ARP auf dem Webserver beeinträchtigt die Fähigkeit Ihrer Webserver, Gateways zu wechseln, wenn einer der Haproxy-Knoten ausfällt. Ich vermute, dass die virtuelle Schnittstelle dieselbe MAC-Adresse wie das eth1 des Haproxy-Knotens hat, sodass Sie sich schwer tun müssen Code für eines der beiden Gateways in jedem Webserver.

Haben Sie irgendeine Art von Sicherheitssoftware auf dem fehlerhaften Webserver installiert? Ich habe eine lange Nacht mit einem Windows 2008-Server verbracht, auf dem Symantec Endpoint Security installiert war. Er installiert Filtercode im Netzwerkstapel, der verhindert, dass die ARP-Pakete des Gateways überhaupt angezeigt werden. Das Update dafür (wie von Microsoft bereitgestellt) bestand darin, den Registrierungseintrag zu entfernen, der die DLL geladen hat.

Das andere Mal, als dieses Problem auftrat, schien es hilfreich zu sein, den gesamten Netzwerkadapter aus dem Geräte-Manager zu entfernen und neu zu installieren.

2
jaredg

Da Sie Ihren Arp-Eintrag statisch festgelegt haben, sind Ihre Server wissen, wo sich das Gateway befindet. Wenn Ihr Switch jedoch nicht weiß, wo sich das Gateway befindet, werden Ihre Pakete nicht weitergeleitet.

Klingt so, als hätten Sie einen schlechten (oder verwirrten) Wechsel zwischen Ihrem HAproxy und Ihren Webservern. Starten Sie es neu.

Entweder das, oder Ihre HAproxy-Server sind sich nicht einig darüber, welcher die Kontrolle hat, und beide beantworten Arp-Lookups für .211.

Wenn Ihr Switch überlastet ist, können Ihre HAproxies möglicherweise nicht schnell genug miteinander kommunizieren und führen ein Failover durch.

2
Seth

Wenn dieses Problem das nächste Mal auftritt, würde ich vorschlagen, einige Paketerfassungen auf den beiden fraglichen Hosts auszuführen, um festzustellen, welchen ARP-Verkehr jeder von ihnen beobachtet.

Auf Ihrem HAproxy-Computer ist höchstwahrscheinlich tcpdump installiert. Für den Windows-Computer benötigen Sie entweder eine WinPCAP -Anwendung wie Wireshark oder Microsoft Network Monitor .

Wenn Sie darüber nachdenken, da das Problem speziell bei ARP zu liegen scheint, können Sie möglicherweise den gesamten ARP-Verkehr auf dem HAproxy-Computer und dem betreffenden Windows-Computer mit einer fortlaufenden Erfassungsdatei von (aus Gründen der Argumentation) 10 MB kontinuierlich aufzeichnen. Das sollte groß genug sein, damit die Erfassungsdatei zum Zeitpunkt des Erkennens eines Fehlers noch den ARP-Verkehr von vor dem Fehler enthält. (Es lohnt sich zu experimentieren, indem Sie die Erfassung etwa eine Stunde lang ausführen, um zu sehen, wie viele Daten generiert werden.).

Beispiel für eine Erfassungssyntax für Linux tcpdump (Hinweis: Ich habe keine Linux-Box zur Hand, um dies zu testen. Bitte testen Sie das Verhalten von -C und -W, bevor Sie es in der Produktion verwenden!):

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

Dies sollte Ihnen hoffentlich einen Hinweis darauf geben, was genau fehlschlägt. Wenn ein ARP-Eintrag abläuft (und laut dieser Artikel scheinen neuere Windows-Versionen "inaktive" Einträge sehr aggressiv zu altern), würde ich Folgendes erwarten:

  1. Der Quellhost sendet eine ARP-Anfrage an den Zielhost. ARP-Anforderungen werden im Allgemeinen gesendet, aber wenn ein Host einen vorhandenen Eintrag aktualisiert, kann der ARP Unicast gesendet werden.
  2. Der Zielhost antwortet mit einer ARP-Antwort. In 99% der Fälle ist dies Unicast, aber das RFC erlaubt Broadcast-Antworten. (Weitere Informationen finden Sie im RFC zu IPv4-Adresskollisionserkennung .).

So einfach es klingt, es gibt eine Reihe anderer Dinge, die diesen Prozess stören können:

  • Die ursprüngliche Anforderung erreicht möglicherweise nicht das Ziel.
  • Die Anforderung erreicht möglicherweise das Ziel, aber die Antwort erreicht möglicherweise nicht die Quelle.
  • Ein Hochverfügbarkeitsmechanismus kann das "normale" Verhalten von ARP beeinträchtigen:
    • Wie funktioniert das Failover zwischen den HAProxy-Knoten? Verwendet es eine gemeinsam genutzte MAC-Adresse oder verwendet es unentgeltliches ARP, um eine IP-Adresse zwischen Knoten zu versagen?
    • Viele der MAC-Adressen in den obigen ARP-Tabellen beginnen mit 00-15-5D, das anscheinend bei Microsoft registriert ist. Verwenden Sie irgendeine Form von Clustering oder anderen HA auf dem betreffenden Windows-Computer? Sind diese 00-15-5D-MAC-Adressen dieselben, die Sie mit den Hardware-NICs verknüpft sehen, wenn Sie auf dem Windows-Server eine 'ipconfig/all' ausführen?

Dinge zu überprüfen, ob/wann dies wieder passiert:

  • Sehen Sie sich die Paketerfassungen des ARP-Verkehrs an. Hat ein Teil des Gesprächs offensichtlich nicht stattgefunden?
  • Überprüfen Sie die Bridging-/CAM-Tabellen des Switch. Ordnen sich alle fraglichen MAC-Adressen den Ports zu, die Sie erwarten?
  • Haben andere Hosts im Subnetz gültige ARP-Einträge für die IP-Adressen der Windows- und HAProxy-Hosts?
  • Werden ARP-Einträge für dieselbe Ziel-IP auf mehreren verschiedenen Quellcomputern in dieselbe MAC-Adresse aufgelöst? Melden Sie sich bei einigen anderen Hosts im Subnetz an und stellen Sie sicher, dass 196.211 auf beiden in dieselbe MAC-Adresse aufgelöst wird.
1
Murali Suriar

Ich hatte das gleiche Problem mit Asus Mainboard LAN. Es wurde behoben, indem ein neuester Treiber von der Website realtek installiert wurde

0
M-Razavi

Wir hatten ein ähnliches Problem mit einem unserer 2008 R2-Terminalserver, bei dem der gesamte Datenverkehr auf der NIC gestoppt wurde, aber in Verbindung blieb) und auf den NIC LEDs) die Kommunikation angezeigt wurde Dies war ein fortlaufendes Problem, das 2-3 Mal pro Woche auftrat, jedoch erst nach etwa 12-13 Stunden Betriebszeit (Server wird jede Nacht neu gestartet).

Ich fand, dass Seriousbit Netbalancer die Ursache war, nachdem ich (aus Neugier) versucht hatte, den NetbalancerService-Dienst zu beenden. Der Verkehr begann sich dann über die Schnittstelle zu bewegen. Ich habe seitdem Netbalancer deinstalliert.

0
Chris E