4

Эта проблема была предложена мне одним из моих профессоров, потому что она возникла только после перехода с 100-мегабайтных карт на гигабитные сетевые карты. Второй запрос arp, исходящий от компьютера, который отправляет эхо-запрос (для отправки ответа), не отправляется до тех пор, пока не пройдут эхо-запросы.

Я решил провести домашнее тестирование с парой виртуальных машин и посмотреть, смогу ли я найти причину.

Пример захвата Wireshark

После очистки кэша arp на обеих машинах (arp -d) и проверки связи я получил те же результаты, что и мой профессор, но не могу понять, почему.

Я немного погуглил и нашел кого-то с похожей проблемой, использующей linux (я использую Windows 10), он что-то говорил о существовании устаревшей записи в таблице arp, а также о том, что называется задержкой первого теста, но я так и не смог чтобы найти любую информацию об этих вещах для Windows.

Кто-нибудь знает, почему это может происходить? Или для чего нужен второй запрос arp, если он не находит первое устройство?

|источник

1 ответ1

2

Похоже, это то, что Брюс Хартпенс называет «Возвращение ARP». Как описано в этом отрывке из Пакетного руководства по протоколам базовой сети.

Диалог, показанный на рисунке 4-12, иллюстрирует еще один важный аспект ARP - только хост, инициирующий диалог (генерирующий запрос ARP), поместит запись для хоста назначения в свою локальную таблицу ARP. То есть другие станции, слышащие обмен, даже если они получают запрос ARP, не будут добавлять эти станции в свои собственные таблицы ARP. Однако многие хосты (особенно маршрутизаторы) проявляют агрессию, когда дело доходит до заполнения их таблиц, и, услышав трафик ARP или участвуя в сообщениях ARP, впоследствии будут генерировать свои собственные запросы ARP для заполнения своих таблиц.

Короткий ответ. Хост назначения заполняет свою собственную таблицу ARP теперь, когда он знает о другом хосте.

|источник

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .