Windows10での予期しないARPプローブとARPアナウンス
私たちのシステムでは、3つのホストがすべて同じイーサネットスイッチに接続されています。これを以下に示します。
A (192.168.0.21, WIN10_1809) <-> Switch <-> B (192.168.0.100, Debian Linux 9)
^
|
C (192.168.0.201, WIN10_1809)
これらのホストのいずれか2つの間で、下位レベルのping操作と上位レベルのビジネスメッセージ（TCPまたはUDPに基づく）の両方のネットワーク通信が定期的に行われます。
時折（1日1回または2日に1回など）、ホストBとホストCは、ping操作（約7秒続く）によってホストAにアクセスできないことを検出しますが、ホストAはホストBとホストCにpingを実行しても問題ありません。同時に、ホスト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イベントログからは、上記のイベントの証拠はなく、以下の3つのイベントログのみです。これらが問題の原因なのか結果なのかはわかりません。
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
また、フィールドのログファイルを確認しましたが、そこで問題が発生している証拠はありません。WIN10と新しいSWが自宅で使用されている間、WIN7と古いリリースのSWがフィールドで使用されています。
2か月近く調査しましたが、根本的な原因は見つかりませんでした。アドバイスや提案をいただければ幸いです。また、このような問題に適した場所が他にあるかどうかをお知らせください。
回答
Windows 10自体によって提供されるスケジュールされたタスクが問題を引き起こしたことが判明しました。これは、Microsoft / Windows / Management / Provisioning / Logonの下にあります。OSの起動後（1803または1809リリース以降）に初めて実行されると、ネットワークスタックの再起動が開始されます。
\windows\system32\provtool.exe /turn 5 /source LogonIdleTask
OSの起動後に手動でタスクを実行すると、問題が再現される可能性があります。次に、タスクを無効にした後、1週間近く監視されている5つのシステムで問題が再び発生しなくなります。
また、OSRに関するこの投稿のおかげで、ここにたどり着くことができました。タスクが実際に何をするのか、なぜネットワークスタックの再起動が必要なのかはわかりません。
ps誰かが同じ問題に遭遇した場合に備えて、これを残しておいてください。それが役立つことを願っています。