En nuestro sistema, hay tres hosts, todos conectados al mismo conmutador Ethernet, que se ilustra a continuación:
A (192.168.0.21, WIN10_1809) <-> Switch <-> B (192.168.0.100, Debian Linux 9)
^
|
C (192.168.0.201, WIN10_1809)
Entre dos de estos hosts, periódicamente hay comunicaciones de red, tanto operaciones de ping de nivel inferior como mensajes comerciales de nivel superior (basados en TCP o UDP).
Ocasionalmente (como una vez al día o dos días), el host B y el host C descubrirían que el host A es inaccesible mediante operaciones de ping (que durarían alrededor de 7 segundos), mientras que el host A no tendría problemas para hacer ping al host B y al host C. Al mismo tiempo, las comunicaciones TCP o UDP de nivel superior relacionadas con el host A también fallarían, mientras que las comunicaciones entre el host B y el host C son totalmente normales.
El problema ocurre en varios sistemas de nuestra empresa y parece que el hardware de red (hemos reemplazado el conmutador y los cables de conexión) y el tráfico de red (el problema persiste incluso cuando el sistema está inactivo y con menos del 1% de uso de ancho de banda) no dar una contribución importante al problema.
Luego, al verificar el tráfico de red en el sistema usando Wireshark (capturado a través del conmutador Ethernet,descargar), descubrimos que las solicitudes de ping se enviaron sin recibir respuesta:
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!)
Al mismo tiempo, las solicitudes de ping del host A fueron respondidas como se observa:
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)
Además, descubrimos que el host A iniciaría una sonda ARP y un proceso de anuncio ARP cuando ocurre el error.
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 acuerdo aRFC 5227:
Antes de comenzar a utilizar una dirección IPv4 (ya sea recibida mediante configuración manual, DHCP o algún otro medio), un host que implemente esta especificación DEBE probar para ver si la dirección ya está en uso, transmitiendo paquetes de sonda ARP. Esto también se aplica cuando una interfaz de red pasa de un estado inactivo a uno activo, cuando una computadora se despierta del modo de suspensión, cuando un cambio de estado de enlace indica que se ha conectado un cable Ethernet, cuando una interfaz inalámbrica 802.11 se asocia con una nueva estación base, o cuando se produce cualquier otro cambio en la conectividad donde un host se conecta activamente a un enlace lógico.
Pero en el registro de eventos de Windows en el host A, no hay evidencia de ninguno de los eventos enumerados anteriormente, solo los tres registros de eventos que se enumeran a continuación; no estoy seguro si estos son la causa o el efecto del 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
También hemos verificado los archivos de registro en los campos y no hemos visto evidencia de que haya problemas allí: se han usado WIN7 y versiones anteriores de SW en los campos, mientras que WIN10 y el nuevo SW se están usando en casa.
He investigado durante casi dos meses y no se ha encontrado ninguna causa raíz. Cualquier consejo o sugerencia será muy apreciado. Además, avíseme si hay otros lugares más adecuados para este tipo de problema.
Respuesta1
Resulta que una tarea programada proporcionada por el propio Windows 10 causó el problema, que se encuentra en Microsoft/Windows/Management/Provisioning/Logon. Iniciaría un reinicio de la pila de red cuando se ejecuta por primera vez después de que se inicia el sistema operativo (desde la versión 1803 o 1809):
\windows\system32\provtool.exe /turn 5 /source LogonIdleTask
Cuando ejecutamos manualmente la tarea después de que se inicia el sistema operativo, el problema podría reproducirse. Luego, después de desactivar la tarea, el problema deja de ocurrir nuevamente en cinco sistemas, que han sido observados durante casi una semana.
Además, pudimos llegar aquí principalmente gracias aesta publicación en OSR. Sin embargo, no sé qué hace realmente la tarea y por qué es necesario reiniciar la pila de red.
PD: Deje esto en caso de que alguien tenga el mismo problema, espero que le ayude.