In unserem System sind drei Hosts mit demselben Ethernet-Switch verbunden, wie unten dargestellt:
A (192.168.0.21, WIN10_1809) <-> Switch <-> B (192.168.0.100, Debian Linux 9)
^
|
C (192.168.0.201, WIN10_1809)
Zwischen zwei dieser Hosts findet regelmäßig Netzwerkkommunikation statt, sowohl Ping-Operationen auf niedrigerer Ebene als auch Geschäftsnachrichten auf höherer Ebene (basierend auf TCP oder UDP).
Gelegentlich (etwa einmal am Tag oder alle zwei Tage) stellen Host B und Host C durch Ping-Operationen (die etwa 7 Sekunden dauern) fest, dass auf Host A nicht zugegriffen werden kann, während Host A beim Pingen von Host B und Host C kein Problem hat. Gleichzeitig schlägt auch die übergeordnete TCP- oder UDP-Kommunikation in Bezug auf Host A fehl, während die Kommunikation zwischen Host B und Host C völlig normal ist.
Das Problem tritt auf mehreren Systemen in unserem Unternehmen auf und es sieht so aus, als ob die Netzwerkhardware (Switch und Verbindungskabel wurden ausgetauscht) und der Netzwerkverkehr (das Problem tritt auch dann noch auf, wenn das System im Leerlauf ist und weniger als 1 % der Bandbreitennutzung beträgt) nicht wesentlich zum Problem beitragen.
Anschließend überprüfen wir den Netzwerkverkehr im System mit Wireshark (erfasst über den Ethernet-Switch,herunterladen) stellen wir fest, dass Ping-Anfragen gesendet wurden, ohne dass eine Antwort eingegangen ist:
No. Time Source Destination Protocol Length Info
1455 1.509228 192.168.0.100 192.168.0.21 ICMP 98 Echo (ping) request id=0x6812, seq=1/256, ttl=64 (no response found!)
1848 2.250592 192.168.0.201 192.168.0.21 ICMP 66 Echo (ping) request id=0x30f0, seq=30977/377, ttl=128 (no response found!)
2413 3.512684 192.168.0.100 192.168.0.21 ICMP 98 Echo (ping) request id=0x6818, seq=1/256, ttl=64 (no response found!)
3269 5.516020 192.168.0.100 192.168.0.21 ICMP 98 Echo (ping) request id=0x681c, seq=1/256, ttl=64 (no response found!)
Gleichzeitig wurden Ping-Anfragen von Host A wie folgt beantwortet:
1130 1.130713 192.168.0.21 192.168.0.100 ICMP 60 Echo (ping) request id=0x0008, seq=2313/2313, ttl=255 (reply in 1133)
1131 1.130713 192.168.0.21 192.168.0.201 ICMP 60 Echo (ping) request id=0x0008, seq=2312/2057, ttl=255 (reply in 1132)
1795 2.131109 192.168.0.21 192.168.0.100 ICMP 60 Echo (ping) request id=0x0008, seq=2314/2569, ttl=255 (reply in 1798)
1796 2.131110 192.168.0.21 192.168.0.201 ICMP 60 Echo (ping) request id=0x0008, seq=2315/2825, ttl=255 (reply in 1797)
2249 3.131295 192.168.0.21 192.168.0.100 ICMP 60 Echo (ping) request id=0x0008, seq=2316/3081, ttl=255 (reply in 2252)
2250 3.131296 192.168.0.21 192.168.0.201 ICMP 60 Echo (ping) request id=0x0008, seq=2317/3337, ttl=255 (reply in 2251)
Außerdem stellen wir fest, dass Host A einen ARP-Test und einen ARP-Ankündigungsprozess einleiten würde, wenn der Fehler auftritt.
2838 1.501535 SuperMic_78:e0:f1 Broadcast ARP 60 Who has 192.168.0.100? Tell 192.168.0.21
2841 1.501831 JUMPINDU_64:8b:23 SuperMic_78:e0:f1 ARP 60 192.168.0.100 is at 00:e0:4b:64:8b:23
2876 1.516569 SuperMic_78:e0:f1 Broadcast ARP 60 Who has 192.168.0.201? Tell 192.168.0.21
2879 1.516654 SuperMic_8d:2f:67 SuperMic_78:e0:f1 ARP 60 192.168.0.201 is at ac:1f:6b:8d:2f:67
3234 1.817465 SuperMic_78:e0:f1 Broadcast ARP 60 Who has 192.168.0.21? (ARP Probe)
4179 2.817637 SuperMic_78:e0:f1 Broadcast ARP 60 Who has 192.168.0.21? (ARP Probe)
5043 3.817780 SuperMic_78:e0:f1 Broadcast ARP 60 Who has 192.168.0.21? (ARP Probe)
5897 4.817833 SuperMic_78:e0:f1 Broadcast ARP 60 ARP Announcement for 192.168.0.21
In which, SuperMic_78:e0:f1 is host A, JUMPINDU_64:8b:23 is host B and SuperMic_8d:2f:67 is host C.
EntsprechendRFC 5227:
Bevor eine IPv4-Adresse (ob durch manuelle Konfiguration, DHCP oder auf andere Weise) verwendet wird, MUSS ein Host, der diese Spezifikation implementiert, durch Senden von ARP-Testpaketen prüfen, ob die Adresse bereits verwendet wird. Dies gilt auch, wenn eine Netzwerkschnittstelle von einem inaktiven in einen aktiven Zustand wechselt, wenn ein Computer aus dem Ruhezustand erwacht, wenn eine Änderung des Verbindungsstatus signalisiert, dass ein Ethernet-Kabel angeschlossen wurde, wenn eine drahtlose 802.11-Schnittstelle eine Verbindung zu einer neuen Basisstation herstellt oder wenn eine andere Änderung der Konnektivität auftritt, bei der ein Host aktiv mit einer logischen Verbindung verbunden wird.
Aber im Windows-Ereignisprotokoll auf Host A gibt es keinen Hinweis auf eines der oben aufgeführten Ereignisse, sondern nur die drei unten aufgeführten Ereignisprotokolle. Ich bin nicht sicher, ob diese die Ursache oder die Auswirkung des Problems sind:
ID Source Description
7040 Service Control Manager The start type of the windows modules installer service was changed from auto start to demand start
16 Kernel-General The access history in hive \??\C:\ProgramData\Microsoft\Provisioning\Microsoft-Desktop-Provisioning-Sequence.dat was cleared updating 0 keys and creating 0 modified pages
7040 Service Control Manager The start type of the windows modules installer service was changed from demand start to auto start
Wir haben auch die Protokolldateien auf den Feldern geprüft und konnten dort keine Hinweise auf ein Problem finden. Auf den Feldern wurden WIN7 und alte Softwareversionen verwendet, während zu Hause WIN10 und neue Software zum Einsatz kamen.
Ich habe fast zwei Monate lang nachgeforscht und keine Grundursache gefunden. Für jeden Rat oder Vorschlag wäre ich sehr dankbar. Bitte lassen Sie mich auch wissen, ob es andere Orte gibt, die für diese Art von Problem besser geeignet sind.
Antwort1
Es stellte sich heraus, dass eine geplante Aufgabe von Windows 10 selbst das Problem verursachte. Sie befindet sich unter Microsoft/Windows/Management/Provisioning/Logon. Sie initiierte einen Neustart des Netzwerkstapels, wenn sie zum ersten Mal nach dem Start des Betriebssystems ausgeführt wurde (seit Version 1803 oder 1809):
\windows\system32\provtool.exe /turn 5 /source LogonIdleTask
Wenn wir die Aufgabe nach dem Start des Betriebssystems manuell ausführen, kann das Problem reproduziert werden. Nachdem wir die Aufgabe deaktiviert haben, tritt das Problem auf fünf Systemen, die fast eine Woche lang beobachtet wurden, nicht mehr auf.
Außerdem konnten wir hierher vor allem wegendieser Beitrag auf OSR. Ich weiß jedoch nicht, was die Aufgabe eigentlich macht und warum ein Neustart des Netzwerkstapels erforderlich ist.
PS: Lassen Sie das einfach stehen, für den Fall, dass jemand auf das gleiche Problem stößt. Ich hoffe, es hilft.