私たちのシステムでは、下図に示すように、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 日か 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
また、フィールドのログ ファイルも確認しましたが、問題が発生した形跡はありませんでした。フィールドでは WIN7 と古いリリースのソフトウェアが使用されており、自宅では WIN10 と新しいソフトウェアが使用されています。
2 か月近く調査しましたが、根本的な原因は見つかっていません。アドバイスや提案があれば、ぜひ教えてください。また、この種の問題に適した他の場所があればお知らせください。
答え1
結局、Windows 10 自体が提供するスケジュールされたタスクが問題の原因であることが判明しました。このタスクは、Microsoft/Windows/Management/Provisioning/Logon にあります。このタスクは、OS の起動後初めて実行されると、ネットワーク スタックの再起動を開始します (1803 または 1809 リリース以降)。
\windows\system32\provtool.exe /turn 5 /source LogonIdleTask
OS 起動後にタスクを手動で実行すると、問題が再現されました。その後、タスクを無効にしたところ、5 台のシステムで問題が再発しなくなり、約 1 週間にわたって監視しました。
また、私たちがここまでたどり着けたのは、OSRのこの投稿ただし、タスクが実際に何を実行するのか、またネットワーク スタックの再起動がなぜ必要なのかはわかりません。
追伸：誰かが同じ問題に遭遇した場合に備えてこれを残しておきます。役立つことを願っています。