Ядро: переполнение кэша DST
Я нахожусь под постоянными наводнениями во время, которые обычно имеют более низкие величины. Я часто наблюдал, как моя система перестала отвечать на запросы в своей сети, в то время как я наблюдал это в журналах,
kernel: [455951.513204] __ratelimit: 1771 callbacks suppressed
kernel: [455951.513207] dst cache overflow
Я много исследовал это, но не нашел подходящего ответа. Я использую версию ядра 2.6.32-5-amd64 в системе Debian 6.
1 ответ
На этой странице ( http://bluecoat.force.com/knowledgebase/articles/Solution/CB-IPdestinationcacheoverflowdstcacheoverflowipdstcachemessage) есть инструкции по увеличению кэша, связанного с этим сообщением - цитируется ниже.
Однако, если вы находитесь "в постоянных затоплениях", увеличение этого кэша может только усугубить проблему затопления, и, вероятно, лучше решить проблему до того, как она попадет в вашу систему. Возможно, сбрасывая оскорбительный трафик на ваш маршрутизатор / брандмауэр.
Используйте следующую процедуру для оценки ситуации и изменения размера кеша dest. Все следующие команды предполагают, что вы подключены к консоли 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)
echo 524288> / proc / sys / net / ipv4 / route / max_size
ПРИМЕЧАНИЕ. После применения Check Point HFA или обновления Check Point сценарий fwstart может быть перезаписан.
Чтобы получить изменения в реальном времени, используйте эту команду:
$ sysctl -w net.ipv4.route.max_size = 2097152