LINUX.ORG.RU

Ответ на: комментарий от true_admin

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

Casst
() автор топика
Ответ на: комментарий от Nao

Вроде помогло, сенкс. Провёл несколько тестов на продолжительность жизни арп-запросов в кэше - на хосте пробовал разные значения 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сек.

Nao, gc_stale_time у меня по-умолчанию 60 - не думаю, что он может на это повлиять, но по-тестю.

Casst
() автор топика
Ответ на: комментарий от Casst

да я тоже обратил внимание что некоторые таймауты неточно обрабатываются. Такое ощущение что там garbage collector просто периодически запускается и чистит всё скопом. По крайней мере я такое с tcp-сессиями наблюдал по выводу netstat.

true_admin ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.