Em nosso sistema, existem três hosts, todos conectados ao mesmo switch Ethernet, ilustrado abaixo:
A (192.168.0.21, WIN10_1809) <-> Switch <-> B (192.168.0.100, Debian Linux 9)
^
|
C (192.168.0.201, WIN10_1809)
Entre quaisquer dois desses hosts, ocorrem periodicamente comunicações de rede, tanto operações de ping de nível inferior quanto mensagens comerciais de nível superior (baseadas em TCP ou UDP).
Ocasionalmente (como uma vez por dia ou dois dias) o host B e o host C descobririam que o host A está inacessível por operações de ping (que durariam cerca de 7 segundos), enquanto o host A não teria problemas ao executar ping no host B e no host C. Ao mesmo tempo, as comunicações TCP ou UDP de nível superior relacionadas com o host A também falhariam, enquanto as comunicações entre o host B e o host C seriam totalmente normais.
O problema acontece em vários sistemas da nossa empresa e parece que o hardware de rede (substituímos o switch e os cabos de conexão) e o tráfego de rede (o problema ainda acontece mesmo quando o sistema está ocioso e com menos de 1% de uso de largura de banda) não. dar uma contribuição importante para o problema.
Em seguida, verificando o tráfego de rede no sistema usando o Wireshark (capturado através do switch Ethernet,download), descobrimos que as solicitações de ping foram enviadas e nenhuma resposta foi recebida:
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!)
Ao mesmo tempo, as solicitações de ping do host A foram respondidas conforme observado:
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)
Além disso, descobrimos que o host A iniciaria uma investigação ARP e um processo de anúncio ARP quando o erro ocorresse.
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.
De acordo comRFC 5227:
Antes de começar a usar um endereço IPv4 (recebido de configuração manual, DHCP ou algum outro meio), um host que implementa esta especificação DEVE testar para ver se o endereço já está em uso, transmitindo pacotes de sonda ARP. Isto também se aplica quando uma interface de rede transita de um estado inativo para um estado ativo, quando um computador desperta do modo de suspensão, quando uma mudança de estado de link sinaliza que um cabo Ethernet foi conectado, quando uma interface sem fio 802.11 se associa a uma nova estação base, ou quando ocorre qualquer outra alteração na conectividade onde um host se torna ativamente conectado a um link lógico.
Mas no log de eventos do Windows no host A, não há evidências de nenhum evento listado acima, apenas os três logs de eventos listados abaixo - não tenho certeza se estes são a causa ou o efeito do problema:
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
Também verificamos os arquivos de log nos campos e não vimos nenhuma evidência de problema acontecendo lá - o WIN7 e versões antigas do SW foram usados nos campos enquanto o WIN10 e o novo SW estão sendo usados em casa.
Investiguei por quase dois meses e nenhuma causa raiz foi encontrada. Qualquer conselho ou sugestão seria muito apreciado. Além disso, informe-me se houver outros locais mais adequados para esse tipo de problema.
Responder1
Acontece que uma tarefa agendada fornecida pelo próprio Windows 10 causou o problema, que está localizado em Microsoft/Windows/Management/Provisioning/Logon. Ele iniciaria uma reinicialização da pilha de rede ao ser executado pela primeira vez após a inicialização do sistema operacional (desde a versão 1803 ou 1809):
\windows\system32\provtool.exe /turn 5 /source LogonIdleTask
Quando executamos manualmente a tarefa após a inicialização do sistema operacional, o problema pode ser reproduzido. Então, após desabilitar a tarefa, o problema deixa de acontecer novamente em cinco sistemas, que estão monitorados há quase uma semana.
Além disso, poderíamos chegar aqui principalmente por causa deesta postagem no OSR. Não sei o que a tarefa realmente faz e por que a reinicialização da pilha de rede é necessária.
ps Deixe isso caso alguém tenha o mesmo problema, espero que ajude.