우리 시스템에는 세 개의 호스트가 모두 동일한 이더넷 스위치에 연결되어 있으며 아래 그림과 같습니다.
A (192.168.0.21, WIN10_1809) <-> Switch <-> B (192.168.0.100, Debian Linux 9)
^
|
C (192.168.0.201, WIN10_1809)
이들 두 호스트 사이에는 하위 수준 핑 작업과 상위 수준 비즈니스 메시지(TCP 또는 UDP 기반) 모두 주기적으로 네트워크 통신이 있습니다.
때때로(하루 또는 이틀에 한 번) 호스트 B와 호스트 C는 ping 작업(약 7초 동안 지속됨)으로 호스트 A에 액세스할 수 없다는 것을 알게 되지만 호스트 A는 호스트 B와 호스트 C를 핑하는 데 아무런 문제가 없습니다. 동시에 호스트 A와 관련된 상위 TCP 또는 UDP 통신도 실패하지만 호스트 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!)
동시에 호스트 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 이벤트 로그에는 위에 나열된 이벤트에 대한 증거가 없으며 아래에 나열된 세 가지 이벤트 로그만 있습니다. 이것이 문제의 원인인지 결과인지는 확실하지 않습니다.
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 및 이전 SW 릴리스를 사용하고 집에서는 WIN10 및 새 SW를 사용하고 있습니다.
거의 두 달 동안 조사했지만 근본 원인은 발견되지 않았습니다. 어떤 조언이나 제안이라도 대단히 감사하겠습니다. 또한 이런 종류의 문제에 더 적합한 다른 장소가 있는지 알려주십시오.
답변1
알고 보니 Windows 10 자체에서 제공하는 예약된 작업으로 인해 문제가 발생한 것으로 나타났으며 이는 Microsoft/Windows/Management/Provisioning/Logon에 있습니다. OS가 시작된 후 처음으로 실행될 때(1803 또는 1809 릴리스 이후) 네트워크 스택 다시 시작을 시작합니다.
\windows\system32\provtool.exe /turn 5 /source LogonIdleTask
OS가 시작된 후 수동으로 작업을 실행하면 문제가 재현될 수 있습니다. 그런 다음 작업을 비활성화한 후 거의 1주일 동안 관찰된 5개의 시스템에서 문제가 다시 발생하지 않습니다.
또한 우리가 여기까지 올 수 있었던 주된 이유는OSR의 이 게시물. 작업이 실제로 수행하는 작업과 네트워크 스택을 다시 시작해야 하는 이유를 모릅니다.
ps. 누군가가 같은 문제를 겪을 경우를 대비해 이 글을 남겨주세요. 도움이 되기를 바랍니다.