Ситуация следующая. Есть сервер мониторинга сети. Каждые пять минут он опрашивает по snmp 150 хостов. В ядре сети стоит DGS-3627G, этот сервак подключен к нему. Когда подходит время опроса, некоторые маки хостов на серваке ещё есть, и система мониторинга успешно опрашивает хост без арп-запроса, а вот на DGS-3627G, к этому времени, маков хостов в таблице соответствия мак-порт ака FDB (не путать с arp-ip) уже нет. В итоге, при таком раскладе, DGS-3627G шлёт запрос на все порты броудкастом и эти пакеты идут по всем хостам в сети. Если увеличить время жизни FDB то всё нормально, но т.к. хостов много и многие являются транзитными для других, то геморно увеличивать FDB на этих хостах. Вот и хотелось бы уменьшить время жизни ARP-кэша на самом сервере - тогда ему придётся отправить арп-запрос перед очередным опросом и записи маков появятся на соответствующих портах всех свичей

miksoft,
<<Почему? У вас настолько велика сеть, что не хватает размера arp-таблицы? Или кто-то балуется arp-спуфингом?

На DGS-3627G, как и на остальных подобных коммутаторах фирмы Дlink, время жизни соответствий mac- порт 300 сек, но в реалии меньше и из-за этого коммутатор забывает через какой порт отсылать пакет и шлёт его по всем портам, далее тоже самое делают и следующие коммутаторы с пришедшими на них пакетами и так до конечных узлов. Т.е. на конечных узлах можно увидеть эти пакеты, не предназначенные данным узлам. Это всё выливается хоть в небольшой, но всё же не нужный трафик, да и плюс видно содержимое пакетов в которых присутствует комьюнити.

<<Сомневаюсь, что этим вы серьезно улучшите ситуацию. Ведь arp-запрос всегда идет широковещанием.

Я и не спорю, что арп-запрос широковещательным.
Мне нужно чтобы на сервере арп кэш очищался перед очередным опросом и затем он отправит арп-запросы и коммутаторы соответственно обновят у себя таблицу маршрутов по портам и фсё будет гуд

Можно, конечно это в крон засунуть.... но не то.

Провёл несколько тестов на продолжительность жизни арп-запросов в кэше - на хосте пробовал разные значения gc_timeout и запросом i=1; ping 10.1.1.1 -c 1 > /dev/null; while true; do a=$[$i+1]; echo $a; i=$a; arp -n|grep 10.1.1.1; sleep 1; done; отследил сколько времени продержится в кэше мак этого хоста при разном значении этой переменной - работает, но как-то не точно - если поставить gc_timeout=50 - арп-запрос может прожить 80±20 сек, при 100 - 110±60 сек, 150 - 200±40сек, 1000 - 1200±100сек Странный какой-то алгоритм очищения кэша ...