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 留下這個以防萬一有人遇到同樣的問題,希望對您有所幫助。