Добрый день.
Имеется DGS-3627G, собирает оптику и роутит абонентов, к нему через L2 железку подключены несколько серверов с Linux.
Между всеми железками бегает OSPF, на одном из серверов на loopback прописан ипшник 10.0.0.2.
Свитч и сервера находятся в одном VLAN с адресами 10.127.255.0/28, после запуска ospf все маршруты нормально прописываются и юзеры видят сервер 10.0.0.2. Но если некоторое время на сервер нет активности, то arp запись на сервере устаревает, и если теперь пингануть адрес 10.0.0.2, то сервер в ответ на

не получает ничего.
arp -a показывает


В тоже время между серверами связь нормальная, при удалении записи на томже сервере, все происходит в штатном режиме.

соответственно arp -a


10.127.255.1, 10.127.255.5 - Linux
10.127.255.2 - DGS-3627G

Судя повсему на длинке есть какоето ограничение на arp от "неизвестных" ip. Вопрос, это можно както отключить?
Я понимаю что проблему можно решить топорно прописав статику или еще както, но хочется универсального решения.

какая версия прошивки?

включен ли cpu_interface_filtering? попробуйте его отключить для теста

_________________
Это текст, который можно добавлять к размещаемым вами сообщениям. Длина его ограничена 255 символами.

Firmware Version : Build 2.52.B45
CPU Interface Filtering State: Disabled

В момент проявления проблемы на DGS-3627G есть маршрут до 10.0.0.2? Если с коммутатора DGS-3627G ping-ануть 10.0.0.2, то ARP запись появляется?

_________________
С уважением,
Бигаров Руслан.

Маршрут до 10.0.0.2 присутствует, получен по OSPF.
Если на коммутаторе уже есть arp запись для 10.127.255.5 (этот шлюз указан для 10.0.0.2 и именно там висит на лупбеке 10.0.0.2) то после того как с коммутатор пинганешь 10.0.0.2 на сервере arp непоявляется.
Если на коммутаторе нет этой arp записи, то соответственно он делает who-has и они друг дружку с сервером после этого находят.
Если с коммутатора пингануть 10.127.255.5, то на сервере появляется для него запись и все начинает работать, но опятьже до того момента как по какимлибо причинам запись на сервере устареет раньше чем на свитче.

Получил от Вас описание проблемы по почте, я проверю ее на тестовом стенде и сообщу Вам по результатам.

Такая же картина на куче 3612 с прошивкой 2.40.B75.

Пришлось прибивать статически маки всех серверов.

На тестовом стенде я также наблюдаю подобное поведение коммутатора, я уточню в штаб-квартире и сообщу Вам по результатам.

Есть ли новости по этой проблеме?

2.52.B44 та же беда.

В указанной AlekseyN топологии коммутатор не отвечает на ARP запрос от лупбек интерфейса сервера, так как его IP (IP источника) не находится в одной подсети с интерфейсом коммутатора. Если бы для ARP запроса использовался не лупбек интерфейс на линуксе с указанными настройками, а интерфейс с адресом находящимся в одной подсети с интерфейсом коммутатора, то указанной клиентом проблемы не возникло бы.

Поведение линуксового сервера корректируется при помощи
echo 1 > /proc/sys/net/ipv4/conf/all/arp_announce
тогда все начинает работать как нужно длинку, запросы от лупбека идут с сурс адресом интерфейса подсети свитча.

Так в итоге это помогло или нет?

Да это помогает и работает. Можно даже добавить в какойнить FAQ.
Ну единственное что корректнее будет написать в /etc/sysctl.conf следующую строчку net.ipv4.conf.all.arp_announce = 1 и выполнить sysctl -p

Рад слышать!