Запросы Arp с нечетным исходным IP остаются без ответа

У меня есть сервер с проблемами сетевого подключения, которые, как я полагаю, происходят из-за проблем с обработкой протокола arp.

Допустим, топология сети выглядит следующим образом:

• сеть 192.168.106.0, маска сети 255.255.255.0
• маршрутизатор на 192.168.106.1
• "проблемный сервер" на 192.168.106.2
• другой сервер на 192.168.106.3

Теперь предположим, что "проблемный сервер" может молчать в сети в течение периодов, достаточных для истечения срока действия его записи arp на маршрутизаторе.

Когда кто-то из этой сети пытается подключиться к "проблемному серверу", время ожидания всех попыток истекает. Соединения внутри сети с "проблемным сервером" успешны.

Если сам "проблемный сервер" пытается подключиться к какому-либо другому адресу за пределами сети, соединение будет успешным - и после этого также некоторое время будут происходить и внешние подключения к "проблемному серверу". Кроме того, соединения от "проблемного сервера" к "другому серверу" в порядке.

Глядя на трафик arp в случае, когда "проблемный сервер" долгое время молчал, я вижу в сети запросы arp на адрес "проблемного сервера", но адрес "сказать" на них является сетевым адресом (192.168.106.0) вместо адреса маршрутизатора (192.168.106.1) - и это, как я предполагаю, и является причиной этой проблемы: по какой-то причине маршрутизатор имеет неправильный адрес ответа в своих запросах arp.

"Другой сервер" остается доступным, но я предполагаю, что причина в том, что он часто устанавливает соединения с внешними сетями и, таким образом, предотвращает истечение срока действия записи arp на маршрутизаторе.

Есть комментарии / предложения?

Рассматриваемые серверы работают под управлением Linux (CentOS 5.x?) И работают как виртуальные машины в VMWare ESXi (5.0?) (Я проверю / заполню детали версии, как только вернусь к работе в понедельник). Маркер / модель роутера для меня неизвестна.

Ответы на вопросы, дальнейшие выводы

Извиняюсь за медлительность, чтобы вернуть это.

К сожалению, моя видимость со стороны сети (что-либо кроме самой платформы VMWare) сильно ограничена.

Основанный на пакетах запроса arp от маршрутизатора, это продукт Juniper (угадывание по MAC-адресу запрашивающей стороны).

Это небольшая сеть, поэтому рассмотрим топологию как маршрутизатор, коммутатор и один сервер VMWare, на котором размещены несколько виртуальных машин.

Что касается инициатора нечетных запросов arp, это в значительной степени должен быть сетевой шлюз: они появляются только тогда, когда я пытаюсь подключиться к "проблемной" машине из-за пределов сети, и прекращаются, когда попытка прекращается или отменяется. Незначительная странность заключается в том, что MAC-адрес в этих запросах не совпадает с тем, который виден для маршрутизатора в таблице arp сервера после установления исходящего соединения. Однако как MAC-адрес, присутствующий в этих "нечетных" запросах, так и MAC-адрес, показанный в таблице arp сервера, имеют OUI Juniper-assigner.

Тогда один, возможно, связанный вывод; похоже, что Linux не будет отвечать на запросы arp, где "Tell" адрес - это сетевой адрес, в то время как Windows (по крайней мере, Vista) это делает. Это я не смог проверить в реальной проблемной среде, но с моими собственными игрушками дома.

Кроме того, похоже, я не полностью одинок в этом вопросе; похожий опыт можно найти здесь: alpacapowered.wordpress.com