Почему 2-й запрос ARP ждет, пока не исчезнут пинги?
Эта проблема была предложена мне одним из моих профессоров, потому что она возникла только после перехода с 100-мегабайтных карт на гигабитные сетевые карты. Второй запрос arp, исходящий от компьютера, который отправляет эхо-запрос (для отправки ответа), не отправляется до тех пор, пока не пройдут эхо-запросы.
Я решил провести домашнее тестирование с парой виртуальных машин и посмотреть, смогу ли я найти причину.
После очистки кэша arp на обеих машинах (arp -d) и проверки связи я получил те же результаты, что и мой профессор, но я не могу понять, почему.
Я немного погуглил и нашел кого-то с похожей проблемой, использующей linux (я использую Windows 10), он что-то говорил о существовании устаревшей записи в таблице arp, а также о том, что называется задержкой при первом тестировании, но я так и не смог чтобы найти любую информацию об этих вещах для Windows.
Кто-нибудь знает, почему это может происходить? Или для чего нужен второй запрос arp, если он не находит первое устройство?
1 ответ
Похоже, это то, что Брюс Хартпенс называет "Возврат ARP". Как описано в этом отрывке из Руководства по пакетам для протоколов базовой сети.
Диалог, показанный на рисунке 4-12, иллюстрирует еще один важный аспект ARP - только хост, инициирующий диалог (генерирующий запрос ARP), поместит запись для хоста назначения в свою локальную таблицу ARP. То есть другие станции, слышащие обмен, даже если они получают запрос ARP, не будут добавлять эти станции в свои собственные таблицы ARP. Однако многие хосты (особенно маршрутизаторы) проявляют агрессию, когда дело доходит до заполнения их таблиц, и, услышав трафик ARP или участвуя в сообщениях ARP, впоследствии будут генерировать свои собственные запросы ARP для заполнения своих таблиц.
Короткий ответ. Хост назначения заполняет свою собственную таблицу ARP теперь, когда он знает о другом хосте.