Добрый день!
Имеется устройство DGS-3620-28SC. Прошивка 2.00.B041. До этого была 2.00.B033, там тоже была проблема о которой буду говорить.

Есть около двадцати устройств, которые общаются в пределах одной ospf area и обмениваются маршрутами, все ospf-интерфейсы в одном влане, клиентские подсети редистрибьютятся. Суммарно чуть больше 600-та маршрутов. Почти все устройства DGS-3627, парочка DGS-3620, один juniper ex3200 и один dgs3610.

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

Если на 3620 удалить арп-запись, которая указывает на ex3200 или dgs3610 - некоторое время все работает, потом проблема появляется снова.
Кол-во арп-записей около 2500. На другом 3620 арпов меньше на 300-400 записей, там нет этой проблемы, но не думаю, что это важно.

Что делать? Готов предоставить всю необходимую информацию.

Вот чем мне нравится D-link - это стабильностью! Уже на протяжении нескольких лет на L3 устройствах возникает проблема с ARP, стабильно, на всех устройствах (за исключением 3610-xx, это не D-link)!

Вам нужно попробовать несколько вариантов:
1) на проблемном 3620 снизить ARP Aging time, следить за тем, чтобы количество записей не превышало 2к
2) часть IP интерфейсов перекинуть на другой свич для снижения количества ARP записей на проблемном
3) По крону, тупо чистить ARP каждые 20 минут

Только что выяснил, что создание статической арп-записи на 3620, которая указывает на ospf интерфейсы джунипера и 3610, не помогает.

Попробуйте также сделать статическую запись в fdb

В конечном итоге дело оказалось в следующем. 25-й порт - основной, 26-й резервный, включены эти порты в разные свитчи на разных точках для резервирования. На оба порта приходил тегированный влан, в котором бегает OSPF, но принимался только на 25-м порту (т.е. не был добавлен на 26-й порт). В момент проблемы в fdb мак висел там где и нужно - на 25-м порту, а вот в ipfdb запись висела на 26-м порту.
Иван Мартынюк из киевского офиса указал нам на это когда выслали ему tech_support. Сами не подумали это проверить, т.к. пинг с самого свитча шел нормально. У меня в голове не укладывалось что при этом может быть где-то запись неправильная, если на самом свитче пинг с любого из его интерфейсов шел.

Мы сделали 26-й порт основным, а с 25-го и локально и удаленно убрали влан с OSPF. Все работает как положено. Есть мнение что все-же трафик на 26-м порту как-то принимался в влане с OSPF, хотя должен был дропаться. ingress checking включен, gvrp выключено.

Рад слышать, что разобрались.