在我們的系統中，有三台主機都連接到同一個乙太網路交換機，如下圖所示：
A (192.168.0.21, WIN10_1809) <-> Switch <-> B (192.168.0.100, Debian Linux 9)
^
|
C (192.168.0.201, WIN10_1809)
在這些主機中的任兩台之間，定期進行網路通信，既有下層的 ping 操作，也有上層的業務消息（基於 TCP 或 UDP）。
偶爾（例如一天或兩天一次）主機 B 和主機 C 會透過 ping 操作（持續約 7 秒）發現主機 A 無法訪問，而主機 A ping 主機 B 和主機 C 則沒有問題。上層TCP或UDP通訊也會失敗，而主機B和主機C之間的通訊卻完全正常。
該問題發生在我們公司的多個系統上，看起來網路硬體（已更換交換器和連接電纜）和網路流量（即使系統空閒且頻寬使用率低於 1% 時問題仍然發生）不存在對問題做出重大貢獻。
然後，透過使用Wireshark檢查系統中的網路流量（透過乙太網路交換器捕獲，下載），我們發現 ping 請求已發出，但沒有收到回應：
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!)
同時，主機 A 的 ping 請求已得到回复，如下所示：
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)
此外，我們也發現，當錯誤發生時，主機A會啟動ARP偵測和ARP公告程序。
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.
根據RFC 5227：
在開始使用 IPv4 位址（無論是透過手動設定、DHCP 或其他方式接收）之前，實現此規範的主機必須透過廣播 ARP 偵測封包來測試該位址是否已在使用中。這也適用於以下情況：網路介面從非活動狀態轉換為活動狀態時、電腦從睡眠狀態喚醒時、連結狀態變更表示乙太網路線已連接時、802.11 無線介面與新基地台關聯時、或連接發生任何其他變更（主機主動連接到邏輯連結）時。
但從主機 A 上的 Windows 事件日誌來看，沒有任何證據表明上面列出的任何事件，只有下面列出的三個事件日誌 - 不確定這些是問題的原因還是結果：
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
我們也檢查了現場的日誌文件，沒有發現任何問題發生的證據──現場使用的是WIN7和舊版的軟體，而家裡使用的是WIN10和新版的軟體。
經過近兩個月的檢查，仍未找到根本原因。任何意見或建議將不勝感激。另外，請告訴我是否有其他更適合此類問題的地方。
答案1
原來是Windows 10本身提供的一個排程任務導致了這個問題，該任務位於Microsoft/Windows/Management/Provisioning/Logon下。作業系統啟動後第一次執行時會啟動網路堆疊重新啟動（自1803或1809版本以來）：
\windows\system32\provtool.exe /turn 5 /source LogonIdleTask
當我們在作業系統啟動後手動執行該任務時，問題可能會重現。然後，在停用該任務後，在觀察了近一周的五個系統上不再出現該問題。
另外，我們能到達這裡主要是因為OSR 上的這篇文章。但不知道該任務實際上做了什麼以及為什麼需要重新啟動網路堆疊。
ps 留下這個以防萬一有人遇到同樣的問題，希望它有所幫助。