Gan*_*Yin 5 networking arp windows-10
在我们的系统中，三台主机都连接到同一个以太网交换机，如下图所示：
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 和旧版本的软件已在字段中使用，而 WIN10 和新软件则在家中使用。
调查了近两个月，没有找到根本原因。任何意见或建议将不胜感激。另外，请让我知道是否还有其他地方更适合这种问题。
原来是Windows 10本身提供的一个计划任务导致了这个问题，该任务位于Microsoft/Windows/Management/Provisioning/Logon下。操作系统启动后第一次执行时会启动网络堆栈重启（自1803或1809版本以来）：
\windows\system32\provtool.exe /turn 5 /source LogonIdleTask
当我们在操作系统启动后手动运行该任务时，问题可能会重现。然后，禁用该任务后，在观察了近一周的五个系统上不再出现该问题。
另外，我们能到达这里主要是因为OSR 上的这篇文章。但不知道该任务实际上做了什么以及为什么需要重新启动网络堆栈。
ps 留下这个以防万一有人遇到同样的问题，希望它有所帮助。