Я живу под постоянными наводнениями, которые, как правило, невысоки. Я часто наблюдал, как моя система полностью перестает отвечать на запросы в своей сети, в то время как я наблюдал это в журналах,
kernel: [455951.513204] __ratelimit: 1771 callbacks suppressed
kernel: [455951.513207] dst cache overflow
Я много исследовал по этому поводу, но не нашел подходящего ответа. Между прочим, я использую ядро версии 2.6.32-5-amd64 в системе Debian 6.
Эта страница (http://bluecoat.force.com/knowledgebase/articles/Solution/CB-IPdestinationcacheoverflowdstcacheoverflowipdstcachemessage) есть инструкции по увеличению кеша, связанные с этим сообщением - цитируются ниже.
Однако, если вы находитесь «в условиях непрерывного наводнения», увеличение этого кеша может только усугубить проблему наводнения, и, вероятно, лучше решить проблему до того, как она попадет в вашу систему. Возможно, сбросив нежелательный трафик на вашем маршрутизаторе / межсетевом экране.
Используйте следующую процедуру, чтобы оценить ситуацию и изменить размер целевого кэша. Все следующие команды предполагают, что вы подключены к консоли VAP.
Проверьте текущую ситуацию: cat / proc / slabinfo | grep ip_dst_cache
И настройки: cat / proc / sys / net / ipv4 / route / max_size
Установите новое максимальное значение (например, 2621440) и убедитесь, что оно было принято: echo 2621440> / proc / sys / net / ipv4 / route / max_size; cat / proc / sys / net / ipv4 / route / max_size
Еще раз проверьте текущую ситуацию: cat / proc / slabinfo | grep ip_dst_cache
Через некоторое время загрузка процессора должна снизиться.
Другая проблема, с которой может столкнуться заказчик, заключается в том, что таблица подключений межсетевого экрана заполнена. Когда это происходит, системе требуется больше памяти.
Если брандмауэр не развернут в основной части сети, этой проблемы возникнуть не должно. Если клиент все еще видит это состояние, это может быть вызвано тем, что кто-то пытается подделать IP-адреса во внутренней сети, выполнив своего рода сканирование nmap с поддельными IP-адресами или что-то в этом роде. Для типичного центра обработки данных перед серверами и / или межсетевым экраном по периметру это не должно соблюдаться. Причиной может быть какая-то DoS / DDoS-атака. Независимо от источника проблемы, описанная выше процедура решит ее.
Все параметры sysctl загружаются во время загрузки через сценарий /etc/init.d/network. Команда такая:
sysctl -e -p /etc/sysctl.conf
Этот скрипт запускается перед процессом Check Point, поэтому изменения не сохраняются после перезагрузки.
Когда Check Point установлен, это значение настроено на 524288, когда брандмауэр запускается скриптом fwstart. Таким образом, даже если мы изменили параметр в файле /etc/sysctl.conf, а Linux настраивает его во время загрузки, при запуске брандмауэра это значение снова изменяется. Затем, если мы просто остановим (cpstop) и запустим (cpstart) брандмауэр, эти значения будут снова изменены.
Check Point изменяет это значение - $ cd $ FWDIR / bin $ grep -n max_size fwstart echo 524288> / proc / sys / net / ipv4 / route / max_size
Чтобы убедиться, что ядро будет иметь правильное значение после перезагрузки или перезапуска брандмауэра, выполните следующие действия:
Настройте файлы ниже, чтобы отразить правильное значение
- /etc/sysctl.conf
Отключить строку в скрипте fwstart ($ FWDIR / bin / fwstart)
эхо 524288> / proc / sys / net / ipv4 / route / max_size
ПРИМЕЧАНИЕ. После применения Check Point HFA или обновления Check Point сценарий fwstart может быть перезаписан.
Чтобы получать изменения в реальном времени, используйте эту команду:
$ sysctl -w net.ipv4.route.max_size = 2097152