В нашей системе имеется три хоста, подключенных к одному и тому же коммутатору Ethernet, как показано ниже:
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. В то же время высокоуровневые TCP- или UDP-соединения, связанные с хостом A, также давали сбой, в то время как соединения между хостом B и хостом C были совершенно нормальными.
Проблема возникает на нескольких системах в нашей компании, и, похоже, сетевое оборудование (коммутатор и соединительные кабели были заменены) и сетевой трафик (проблема сохраняется, даже когда система находится в режиме ожидания и ее пропускная способность используется менее чем на 1%) не вносят существенного вклада в проблему.
Затем, проверив сетевой трафик в системе с помощью Wireshark (перехваченный через коммутатор Ethernet,скачать), мы обнаруживаем, что запросы 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!)
В то же время на запросы ping с хоста A были получены следующие ответы:
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.
В соответствии сRFC5227:
Прежде чем начать использовать адрес IPv4 (полученный вручную, DHCP или каким-либо другим способом), хост, реализующий эту спецификацию, ДОЛЖЕН проверить, используется ли уже адрес, путем широковещательной рассылки пакетов ARP Probe. Это также применимо, когда сетевой интерфейс переходит из неактивного в активное состояние, когда компьютер выходит из спящего режима, когда изменение состояния канала сигнализирует о подключении кабеля Ethernet, когда беспроводной интерфейс 802.11 ассоциируется с новой базовой станцией или когда происходит любое другое изменение в подключении, когда хост становится активно подключенным к логическому каналу.
Однако в журнале событий Windows на хосте A нет никаких свидетельств ни одного из перечисленных выше событий, только три журнала событий, перечисленных ниже, — не уверен, являются ли они причиной или следствием проблемы:
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 и новое ПО.
Исследовал почти два месяца, и никакой первопричины не обнаружено. Любой совет или предложение были бы очень признательны. Также, пожалуйста, дайте мне знать, есть ли другие места, которые лучше подходят для решения этой проблемы.
решение1
Оказывается, проблема была вызвана запланированной задачей, предоставляемой самой Windows 10, которая находится в Microsoft/Windows/Management/Provisioning/Logon. Она инициировала перезапуск сетевого стека при первом запуске ОС (начиная с версии 1803 или 1809):
\windows\system32\provtool.exe /turn 5 /source LogonIdleTask
При ручном запуске задачи после загрузки ОС проблема может быть воспроизведена. Затем, после отключения задачи, проблема перестает возникать снова на пяти системах, за которыми наблюдали в течение почти недели.
Также, мы смогли добраться сюда в основном благодаряэтот пост на OSR. Не знаю, что на самом деле делает эта задача и зачем нужен перезапуск сетевого стека.
P.S. Просто оставьте это на случай, если кто-то столкнется с такой же проблемой, надеюсь, это поможет.