Windows 10 上的意外 ARP 探測和 ARP 公告
在我們的系統中，三台主機都連接到同一個乙太網交換機上，如下圖所示：
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 會發現主機 A 無法通過 ping 操作（持續大約 7 秒）而主機 A 在 ping 主機 B 和主機 C 時沒有問題。同時，與主機A相關的上層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 和舊版本的 SW，而在家中使用的是 WIN10 和新版本。
調查了近兩個月，沒有找到根本原因。任何意見或建議將不勝感激。另外，如果有其他地方更適合這種問題，請告訴我。
事實證明，Windows 10 本身提供的計劃任務導致了該問題，該問題位於 Microsoft/Windows/Management/Provisioning/Logon 下。在作業系統啟動後首次執行時，它將啟動網路堆棧重新啟動（自 1803 或 1809 版本以來）：
\windows\system32\provtool.exe /turn 5 /source LogonIdleTask當我們在作業系統啟動後手動執行任務時，問題可能會重現。然後，在禁用該任務後，該問題在五個系統上不再發生，這些系統已經監視了近一周。
此外，我們可以到達這裡主要是因為OSR 上的這篇文章。不知道該任務實際上做了什麼以及為什麼需要重新啟動網路堆棧。
ps 留下這個以防萬一有人遇到同樣的問題，希望對您有所幫助。