PING 응답에 원래 호스트 MAC에 대한 ARP 요청이 필요한 이유는 무엇입니까?

PING 응답에 원래 호스트 MAC에 대한 ARP 요청이 필요한 이유는 무엇입니까?

아래 그림과 같은 시나리오가 있습니다.
여기서 두 개의 호스트 시스템은 허브를 통해 연결됩니다.

여기에 이미지 설명을 입력하세요

좋아, 그래서 호스트 1은 호스트 2를 핑하려고 하고 나는 동일한 허브에 연결된 세 번째 호스트에 Wireshark를 설정했습니다. 놀랍게도 단일 ping 명령이 작동하려면 6개의 패킷이 표시되는데 4개가 있어야 합니다. Wireshark에서 본 내용은 다음과 같습니다.

여기에 이미지 설명을 입력하세요

이제 내가 이해할 수 없는 것은 ARP 응답 대상이 아닌 동안 패킷 5 및 6이 생성되는 이유가 이미 보낸 사람 Mac을 알고 있다는 것입니다.

아니면 제가 이해하는 데 문제가 있는 건가요? 도와주세요.

답변1

원래 답변

첫 번째 응답은 호스트-1 인터페이스가 아닌 허브 인터페이스에서 나옵니다. 물건을 다시 보낼 때 호스트 1의 IP를 사용하는 인터페이스의 Mac을 알아야 합니다. 일부 스위치는 이 작업을 자동으로 수행하지만 다른 스위치는 그렇지 않습니다.

개선된 답변:


              .-----------.
              | hub       |
              |           |
[host-1 i1]+--+hi1     hi2+--+[i2 host-2]
              |           |
              `-----------´

network interfaces: 
i1, i2, hi1, hi2

애플리케이션 계층의 IP 주소를 통해 호스트 2에서 호스트 1로 무언가를 보낸 후 호스트 2에 대한 초기 응답(및 모든 후속 응답)은 호스트 1의 인터페이스 hi2가 아닌 인터페이스 에서 나옵니다 .i1

이미 알려진 호스트-1의 IP로 무엇이든 보내려면 호스트 2는 링크 계층에서 패킷을 보낼 위치를 알아야 합니다. 이를 수행하려면 호스트 2는 호스트 1의 IP를 포함하는 인터페이스의 MAC 주소를 요청해야 합니다.

일부 스위치는 이러한 종류의 변환을 자동으로 수행합니다. mac-path를 기억합니다.뒤로. 대부분의 허브는 그렇지 않으므로 두 번째 요청입니다.

답변2

나는 주어진 대답이 틀렸다고 생각합니다. 제 생각에는 이 현상은 STALE ARP 항목을 찾거나 피하기 위한 Linux 커널의 ARP 구현으로 인해 발생합니다. 발신자의 MAC 주소를 학습하면 수신자의 로컬 ARP 캐시를 업데이트하고 해당 항목을 'DELAY' 상태로 설정합니다. ~5초(기본값, 에서 변경 가능 delay_first_probe_time)를 기다린 후 수신기는 연결 가능성을 조사한 다음 호스트가 이제 'REACHABLE'로 간주되는지 결정합니다.

자세한 내용은 여기에서 확인할 수 있습니다.

https://osqa-ask.wireshark.org/questions/15792/arp-replies-appear-with-delay-in-wireshark-output/

관련 정보