☰

Почему для ответа PING требуется ARP-запрос на MAC-адрес исходного хоста?

tag-icon • tag-icon ping wireshark arp
Почему для ответа PING требуется ARP-запрос на MAC-адрес исходного хоста?

У меня есть сценарий, изображенный ниже.
Здесь две хост-машины соединены через концентратор:

введите описание изображения здесь

Хорошо, так что хост-1 хочет пинговать хост-2, и я настроил Wireshark на 3-м хосте, подключенном к тому же хабу. Теперь удивительно, что одна команда ping сработала, я вижу 6 пакетов, хотя должно быть 4. Вот что я вижу из Wireshark:

введите описание изображения здесь

Теперь мне непонятно, почему пакеты 5 и 6 генерируются, когда получатель ответа ARP уже не знает MAC отправителя.

Или я что-то не так понимаю? Помогите, пожалуйста.

решение1

Оригинальный ответ

Первый ответ приходит с интерфейса концентратора, а не с интерфейса хоста-1. При отправке обратно вам все равно нужно знать mac интерфейса с IP хоста-1. Некоторые коммутаторы делают это автоматически, другие — нет.

Улучшенный ответ:


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

network interfaces: 
i1, i2, hi1, hi2

После отправки чего-либо на хост-1 с хоста-2 через IP-адрес на прикладном уровне первоначальный ответ на хост-2 (и все последующие ответы) будет поступать с интерфейса hi2, а не с i1интерфейса на хосте-1.

Чтобы отправить что-либо на уже известный IP хоста-1, хосту-2 все равно нужно знать, куда отправлять пакеты на канальном уровне. Для этого хост-2 должен запросить MAC-адрес интерфейса, открывающего IP хоста-1.

Некоторые коммутаторы делают этот тип преобразования автоматически — они запоминают MAC-путь.назад. Большинство концентраторов этого не делают, отсюда и второй запрос.

решение2

Я считаю, что данный ответ неверен. По моему мнению, это явление происходит из-за реализации ARP ядра Linux для поиска/избежания УСТАРЕВШИХ записей ARP. После изучения MAC-адреса отправителя он обновляет локальный кэш ARP на приемнике и помещает запись со статусом «ЗАДЕРЖКА». После ожидания в течение ~5 секунд (по умолчанию, может быть изменено в delay_first_probe_time), приемник проверит доступность и затем определит, что хост теперь считается «ДОСТУПНЫМ».

Более подробную информацию можно найти здесь:

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

Связанный контент