Probe ARP e annuncio ARP imprevisti su Windows 10

Question

Nel nostro sistema sono presenti tre host tutti collegati allo stesso switch Ethernet, illustrato di seguito:

A (192.168.0.21, WIN10_1809) <-> Switch <-> B (192.168.0.100, Debian Linux 9)
                                  ^
                                  |
                       C (192.168.0.201, WIN10_1809)

Tra due qualsiasi di questi host, ci sono periodicamente comunicazioni di rete, sia operazioni di ping di livello inferiore che messaggi aziendali di livello superiore (basati su TCP o UDP).

Occasionalmente (come una volta al giorno o due giorni) l'host B e l'host C scopriranno che l'host A è inaccessibile dalle operazioni di ping (che durerebbero circa 7 secondi) mentre l'host A non avrebbe problemi a eseguire il ping dell'host B e dell'host C. Allo stesso tempo, anche le comunicazioni TCP o UDP di livello superiore relative all'host A fallirebbero mentre le comunicazioni tra l'host B e l'host C sono del tutto normali.

Il problema si verifica su più sistemi nella nostra azienda e sembra che l'hardware di rete (abbia sostituito lo switch ei cavi di collegamento) e il traffico di rete (il problema si ripresenti anche quando il sistema è inattivo e utilizza meno dell'1% di larghezza di banda) no dare un contributo importante al problema.

Quindi, controllando il traffico di rete nel sistema utilizzando Wireshark (acquisito tramite switch Ethernet, download ), scopriamo che le richieste di ping sono state inviate senza che sia stata ricevuta alcuna risposta:

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!)

Allo stesso tempo, le richieste di ping dall'host A hanno ricevuto risposta come osservato:

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)

Inoltre, scopriamo che l'host A avvierà un sondaggio ARP e un processo di annuncio ARP quando si verifica l'errore.

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.

Secondo RFC 5227 :

Prima di iniziare a utilizzare un indirizzo IPv4 (ricevuto dalla configurazione manuale, DHCP o da qualche altro mezzo), un host che implementa questa specifica DEVE testare per vedere se l'indirizzo è già in uso, trasmettendo pacchetti ARP Probe. Ciò si applica anche quando un'interfaccia di rete passa da uno stato inattivo a uno attivo, quando un computer si risveglia dallo stato di sospensione, quando un cambio di stato del collegamento segnala che è stato collegato un cavo Ethernet, quando un'interfaccia wireless 802.11 si associa a una nuova stazione base, o quando si verifica qualsiasi altro cambiamento nella connettività quando un host viene connesso attivamente a un collegamento logico.

Ma dal registro eventi di Windows sull'host A, non ci sono prove per alcun evento elencato sopra, solo i tre registri eventi elencati di seguito - non sono sicuro se queste siano la causa o l'effetto 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

Abbiamo anche controllato i file di registro nei campi e non abbiamo visto alcuna prova di problemi che si verificano lì - WIN7 e le vecchie versioni di SW sono state utilizzate nei campi mentre WIN10 e il nuovo SW vengono utilizzati a casa.

Ho studiato per quasi due mesi e non è stata trovata alcuna causa principale. Qualsiasi consiglio o suggerimento sarebbe molto apprezzato. Inoltre, fammi sapere se ci sono altri posti più adatti a questo tipo di problema.

Answer 1

Si scopre che un'attività pianificata fornita da Windows 10 stesso ha causato il problema, che si trova in Microsoft / Windows / Management / Provisioning / Logon. Avvierà un riavvio dello stack di rete quando viene eseguito per la prima volta dopo l'avvio del sistema operativo (dalla versione 1803 o 1809):

\windows\system32\provtool.exe /turn 5 /source LogonIdleTask

Quando eseguiamo manualmente l'attività dopo l'avvio del sistema operativo, il problema potrebbe essere riprodotto. Quindi, dopo aver disabilitato l'attività, il problema cessa di ripetersi su cinque sistemi, che sono stati osservati per quasi una settimana.

Inoltre, potremmo raggiungerci principalmente a causa di questo post su OSR . Non so cosa fa effettivamente l'attività e perché è necessario il riavvio dello stack di rete.

ps Lascialo nel caso qualcuno incontri lo stesso problema, spero che aiuti.