Networking

Windows 10 上的意外 ARP 探測和 ARP 公告

  • September 2, 2020

在我們的系統中,三台主機都連接到同一個乙太網交換機上,如下圖所示:

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

引用自:https://serverfault.com/questions/1031065