web-dev-qa-db-ja.com

エラー「カーネル:nf_conntrack:テーブルがいっぱいです。パケットをドロップします」を軽減する方法

最近、サーバーの1つ(Debian Squeeze)が重い負荷の間に応答しなくなるという問題が発生しました。カーネルログを見ると、これが原因だと思います。

kernel: nf_conntrack: table full, dropping packet

私が理解しているように、これはconntrackモジュールであり、接続のステートフルトラッキングを実行し、接続の詳細を格納するために使用されるテーブルがいっぱいであることを報告します。

私が行った調査から、これを軽減する方法は2つあるようです。

  1. テーブルのサイズを大きくします。

  2. システムからモジュールを完全に取り外します。

ただし、どちらも/proc/sys/net/ipv4/ip_conntrack_maxnor /proc/sys/net/ipv4/netfilter/ip_conntrack_maxこのマシンに存在します(存在しませんipv4netの下のカタログ)。

lsmodを実行すると、結果が得られません。

だから、私は少し混乱しています-おそらく誰かが私のために状況を明らかにすることができますか?

  • Conntrackはインストールされていますか?もしそうなら、設定はどこですか?そして、なぜそれがlsmodに表示されないのですか?
  • Conntrackがインストールされていない場合、何がテーブルフルメッセージを発行していますか?

ありがとうございました

2
UpTheCreek

これは経験によるものです-私はこの情報を検証するための調査を行っていません:これと同じエラーがシステムログにあるいくつかのシステムを見ましたそして/proc/sys/net /には何もありませんipv4/ip_conn *または/ proc/sys/net/ipv4/netfilter。理由も知りたいのですが、元の症状の修正を見つけたら、それはそれほど重要ではありません。 ;)

緩和戦略は2つありました。sysctl(ナイーブな短期的アプローチ)を介して制限を増やすことと、追跡される接続の数が非常に多い理由を理解することです。

デフォルトの制限を超えており、問題のサーバーが多数の接続を処理するように設計されていない場合は、制限に達してはいけないのは当然のことです。高い接続追跡要件を持つサービスの良い例は、10万以上のクライアントにサービスを提供する「パブリック」DNSサーバーです。

緩和策は、ログを調べ、DOS/DDOS対策が実施されていることを確認し(たとえば、fail2banを参照)、適切なファイアウォール構成がインストールされていることを確認することです。

Lsmodに関しては、アクティブに見えるがモジュールがリストされていないという状況に遭遇したことはありません。そのような状況がどのように発生するのかはわかりません。

2
zaTricky

多くの場合、conntrackの設定は/ proc/sys/net/netfilter/nf_conntrack_maxにあります。

1
Matthew Sharp