У меня есть сервер с проблемами сетевого подключения, которые, как я полагаю, возникают из-за проблем с обработкой протокола arp.
Допустим, топология сети выглядит следующим образом:
Теперь предположим, что «проблемный сервер» может молчать в сети в течение периодов, достаточных для того, чтобы его запись arp на маршрутизаторе закончилась.
Когда кто-то из-за пределов этой сети пытается подключиться к «проблемному серверу», время ожидания всех попыток истекает. Подключение изнутри сети к «проблемному серверу» выполняется успешно.
Если «проблемный сервер» сам пытается подключиться к какому-либо другому адресу за пределами сети, соединение будет успешным, а после этого также на некоторое время будут успешными соединения извне сети с «проблемным сервером». Кроме того, соединения от «проблемного сервера» к «другому серверу» в порядке.
Глядя на трафик arp в случае, когда "проблемный сервер" долгое время молчал, я вижу запросы arp в сети для адреса "проблемного сервера", но адрес "tell" на них - это сетевой адрес ( 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" address - это сетевой адрес, тогда как Windows (по крайней мере, Vista) отвечает. Я не смог проверить это в реальной проблемной среде, но с моими собственными игрушками дома.
Кроме того, похоже, что я не совсем одинок с этой проблемой; аналогичный опыт можно найти здесь: alpacapowered.wordpress.com
Сегодня произошло интересное изменение ситуации.
В конце концов, все свелось к двум вещам:
Маршрутизатор Juniper, или фактически кластерная система брандмауэра, каким-то образом потеряла синхронизацию конфигурации между сторонами кластера. В результате не все части кластера FW имели актуальную конфигурацию, и это приводило к неправильным запросам arp (да, неправильные запросы arp действительно исходили от маршрутизатора / межсетевого экрана).
Приложение для управления брандмауэром также вело себя неправильно, пытаясь протолкнуть некоторую, отличную от текущей, правильную конфигурацию, по крайней мере, в часть кластера брандмауэра.
У меня нет подробностей о том, что было сделано ни для самого брандмауэра, ни для управляющего приложения, но конечный результат состоит в том, что теперь адресом "tell" в запросах arp является IP-адрес маршрутизатора (.1 из исходного описания ) вместо сетевого адреса (.0).
И на эти ("у кого-есть ... скажите ... .1") запросы arp сервер Linux отвечает так, как должен, и входящие соединения работают просто великолепно, даже спустя долгое время после того, как любой след адреса сервера был потерян. из кэша arp маршрутизатора.
Я столкнулся с той же проблемой. Оказалось, что кто-то установил значение manage-ip для адреса подсети:
Cluster:name(M)-> get config | inc aggregate10.200
set interface aggregate10.200 ip x.x.x.x.225/28
...
set interface aggregate10.200 manage-ip x.x.x.224
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Исправить:
unset interface aggregate10.200 manage-ip
В нашем случае это была неправильная конфигурация.