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

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

Wir haben HAProxy zusammen mit Heartbeat 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 über eine virtuelle Schnittstelle (eth1: 1) unter IP: 69.59.196.211 von beiden geteilt wird

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

Es kommt gelegentlich zu einem Netzwerkausfall auf einem unserer Windows-Server hinter unseren Linux-Gateways. HAProxy erkennt, dass der Server offline ist. Dies können wir überprüfen, indem wir eine Remoteverbindung zum ausgefallenen Server herstellen und versuchen, das Gateway per Ping zu erreichen:

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

Die Ausführung arp -aauf diesem ausgefallenen Server zeigt, dass für die Gateway-Adresse (69.59.196.211) kein Eintrag vorhanden ist :

Schnittstelle: 69.59.196.220 --- 0xa
Internetadresse Typ der physischen Adresse
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 dynamic
69.59.196.215 00-21-5e-4d-61-1a dynamisch
69.59.196.217 00-21-5e-4d-2c-e8 dynamic
69.59.196.219 00-21-5e-4d-38-e5 dynamic
69.59.196.221 00-15-5d-00-b2-0d dynamic
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 -azeigt:

peak-colo-196-220.peak.org (69.59.196.220) bei <incomplete> auf eth1
stackoverflow.com (69.59.196.212) um 00: 21: 5e: 4d: 45: c9 [ether] auf eth1
peak-colo-196-215.peak.org (69.59.196.215) um 00: 21: 5e: 4d: 61: 1a [ether] 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) at 00: 26: 88: 63: c7: 80 [ether] on eth1
peak-colo-196-217.peak.org (69.59.196.217) um 00: 21: 5e: 4d: 2c: e8 [ether] auf eth1

Warum hat arp den Eintrag für diesen ausgefallenen Server gelegentlich als <unvollständig> festgelegt? Sollen 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, DIE WIR VERSUCHT HABEN

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

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

Ein Neustart des Windows-Webservers behebt dieses Problem vorübergehend, ohne dass Änderungen am Netzwerk vorgenommen werden. Unsere Erfahrung zeigt jedoch, dass dieses Problem erneut auftritt.

Austausch von Netzwerkkarten und Switches

Ich bemerkte, dass die Verbindungsleuchte am Port des Switches für den ausgefallenen Windows-Server auf der ausgefallenen Schnittstelle mit 100 MB anstelle von 1 GB lief. Ich habe das Kabel auf mehrere andere offene Ports verschoben, und der Link zeigte 100 MB für jeden Port an, den ich ausprobiert habe. Mit dem gleichen Ergebnis habe ich auch das Kabel getauscht. Ich habe versucht, die Eigenschaften der Netzwerkkarte in Windows zu ändern, und der Server wurde gesperrt. Nach dem Klicken auf Übernehmen war ein Hard-Reset erforderlich. Dieser Windows-Server verfügt über zwei physische Netzwerkschnittstellen. Daher habe ich die Kabel und Netzwerkeinstellungen der beiden Schnittstellen vertauscht, um festzustellen, ob das Problem auf die Schnittstelle zurückzuführen ist. Wenn die öffentliche Schnittstelle wieder ausfällt, wissen wir, dass es kein Problem mit der Netzwerkkarte gibt.

(Wir haben auch versucht, einen anderen Schalter zur Hand zu haben, keine Änderung)

Ändern der Netzwerkhardwaretreiberversionen

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

Netzwerkkabel ersetzen

Als letzte Anstrengung haben wir uns daran erinnert, dass eine weitere Änderung darin bestand, alle Patchkabel zwischen unseren Servern / Switches auszutauschen. Wir hatten zwei Sets gekauft, eines mit einer Länge von 1 - 3 Fuß für die privaten Schnittstellen und ein weiteres Set mit roten Kabeln für die öffentlichen Schnittstellen. Wir haben alle öffentlichen Schnittstellen-Patchkabel gegen andere Marken ausgetauscht und unsere Server eine Woche lang ohne Probleme betrieben ... und dann trat das Problem erneut auf.

Deaktivieren Sie die Prüfsummenverschiebung und entfernen Sie TProxy

Wir haben auch versucht, das TCP / IP-Prüfsummen-Offload im Treiber zu deaktivieren, keine Änderung. Wir ziehen jetzt TProxy heraus und gehen zu einer traditionelleren x-forwarded-forNetzwerkanordnung über, ohne dass die IP-Adresse neu geschrieben werden muss. Mal sehen, ob das hilft.

Wechseln Sie den Virtualisierungsanbieter

Da dies auf irgendeine Weise mit Hyper-V zu tun hatte (wir hosten Linux-VMs darauf), sind wir auf VMWare Server umgestiegen. Keine Änderung.

Host-Modell wechseln

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

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

Wir haben das getan und wir haben auch einige unveröffentlichte Kernel-Hotfixes bekommen, die vermutlich in 2008 R2 SP1 eingeführt wurden. Keine Reparatur.

Ersetzen der Netzwerkkartenhardware

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

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

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 eingeht. Während dieses Erkennungszeitraums wird der ARP-Cache-Eintrag unvollständig aufgelistet. Wenn die Suche nach der angegebenen Anzahl von ARP-Anforderungen nicht erfolgreich ist, wird der ARP-Cache-Eintrag in einem fehlgeschlagenen Status 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 würde Ihre Gateway-Box nicht (oder zu langsam) auf ARP-Anfragen von Ihrer Gateway-Box antworten. Schaltet das <incomplete>irgendwann um <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?

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

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

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. Für mich ist es übrigens merkwürdig, dass Sie keine solche ARP-Zuordnung 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 die ganze Zeit seine Arbeit geleistet hat.

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

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

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

Bearbeiten:

Ich sehe aus Ihrem Update, 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 in der Lage ist, über die Front-End-Oberfläche zu kommunizieren? Nehmen Sie auch route printwährend eines Fehlers eine Kopie der Routingtabelle vom Windows-Computer ( ). (Ich versuche festzustellen, ob die Netzwerkkarte / der Treiber auf dem Windows-Computer fehlerhaft funktioniert.)

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

Der Grund, warum der statische ARP auf dem Haproxy-Knoten nicht hilft, ist, dass Ihr Webserver immer noch nicht herausfindet, wie er zum Gateway zurückkehren kann.

Statisches ARP auf dem Webserver unterbricht 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 eth1 des Haproxy-Knotens hat, sodass Sie es schwer haben würden Code zu einem der beiden Gateways in jedem Webserver.

Ist auf dem ausfallenden Webserver eine Sicherheits-Software installiert? Ich habe eine lange Nacht mit einem Windows 2008-Server verbracht, auf dem Symantec Endpoint Security installiert ist. Er installiert einen Filtercode im Netzwerkstapel, der verhindert, dass die ARP-Pakete des Gateways überhaupt angezeigt werden. Das Update dafür (wie von Microsoft bereitgestellt) war das Entfernen des Registrierungseintrags, der die DLL geladen hat.

Das andere Mal, als dieses Problem auftrat, schien das Entfernen des gesamten Netzwerkadapters aus dem Geräte-Manager und die Neuinstallation zu helfen.

Da Sie Ihren Arp-Eintrag statisch festgelegt haben, wissen Ihre Server , 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. Starte es neu.

Entweder das, oder Ihre HAproxy-Server sind sich nicht einig, welcher die Kontrolle hat, und beide beantworten die Arp-Suche nach .211.

Wenn Ihr Switch überlastet ist, können Ihre HAproxies möglicherweise nicht schnell genug miteinander kommunizieren und es kommt zu einem Failover.

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

Auf Ihrem HAproxy-Computer ist höchstwahrscheinlich ein Teil von 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, könnte das Problem anscheinend spezifisch bei ARP liegen, und Sie könnten möglicherweise den gesamten ARP-Verkehr auf dem HAproxy-Computer und dem betreffenden Windows-Computer mit einer fortlaufenden Erfassungsdatei von (aus Gründen des Arguments) 10 MB kontinuierlich aufzeichnen. Diese sollte groß genug sein, damit die Erfassungsdatei zum Zeitpunkt der Feststellung eines Fehlers weiterhin den ARP-Verkehr enthält, der vor dem Fehler aufgetreten ist. (Es lohnt sich zu experimentieren, indem Sie das Capture etwa eine Stunde lang ausführen, um zu sehen, wie viele Daten es generiert.)

Beispiel-Capture-Syntax für Linux tcpdump (Hinweis: Ich habe keine Linux-Box zum Testen parat. Bitte testen Sie das Verhalten von -C und -W, bevor Sie sie 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 ausfällt. Wenn ein ARP-Eintrag abläuft (und gemäß diesem Artikel scheinen neuere Versionen von Windows "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 in der Regel rundgesendet. In dem Fall, in dem ein Host einen vorhandenen Eintrag aktualisiert, wird der ARP möglicherweise als Unicast gesendet.
2. Der Zielhost antwortet mit einer ARP-Antwort. In 99% der Fälle handelt es sich um Unicast, der RFC lässt jedoch Broadcast-Antworten zu. (Weitere Informationen finden Sie in der RFC zur IPv4-Adressenkollisionserkennung .)

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

• Die ursprüngliche Anforderung kommt möglicherweise nicht am Ziel an.
• Die Anforderung kommt möglicherweise am Ziel an, aber die Antwort erreicht möglicherweise nicht die Quelle.
• Einige Hochverfügbarkeitsmechanismen können das "normale" Verhalten von ARP stören:
  • Wie funktioniert das Failover zwischen den HAProxy-Knoten? Verwendet es eine gemeinsam genutzte MAC-Adresse oder verwendet es ARP, um ein Failover einer IP-Adresse zwischen Knoten durchzuführen?
  • Viele der MAC-Adressen in den obigen ARP-Tabellen beginnen mit 00-15-5D, das anscheinend bei Microsoft registriert ist. Verwenden Sie eine Form von Clustering oder eine andere HA auf dem betreffenden Windows-Computer? Sind diese 00-15-5D-MAC-Adressen mit den Hardware-NICs identisch, wenn Sie auf dem Windows-Server eine "ipconfig / all" ausführen?

Zu überprüfende Punkte, ob / wann dies erneut geschieht:

• Sehen Sie sich die Paketerfassungen des ARP-Verkehrs an. Hat irgendein Teil des Gesprächs offensichtlich nicht stattgefunden?
• Überprüfen Sie die Bridging / CAM-Tabellen des Switches. Stimmen alle in Frage kommenden MAC-Adressen mit den von Ihnen erwarteten Ports überein?
• Verfügen andere Hosts im Subnetz über 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 unterschiedlichen Quellcomputern in dieselbe MAC-Adresse aufgelöst? dh 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.

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

Ich stellte fest, 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 Netbalancer seitdem deinstalliert.

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