nf_conntrack: table full, dropping packet

简介:
Mar 26 21:53:50 Gentoo-2012 kernel: [974749.140915] net_ratelimit: 3606 callbacks suppressed
Mar 26 21:53:50 Gentoo-2012 kernel: [974749.140918] nf_conntrack: table full, dropping packet.
Mar 26 21:53:50 Gentoo-2012 kernel: [974749.144022] nf_conntrack: table full, dropping packet.
Mar 26 21:53:50 Gentoo-2012 kernel: [974749.144031] nf_conntrack: table full, dropping packet.
Mar 26 21:53:50 Gentoo-2012 kernel: [974749.144037] nf_conntrack: table full, dropping packet.
解决办法
修改内核参数
vi /etc/sysctl.conf
net.ipv4.netfilter.ip_conntrack_max = 655350
net.ipv4.netfilter.ip_conntrack_tcp_timeout_established = 1200
#默认超时时间为5天,作为一个主要提供HTTP服务的服务器来讲,完全可以设置得比较短
sysctl -p # 让刚刚修改过的设置生效
默认值是
net.ipv4.netfilter.ip_conntrack_max = 65536
net.ipv4.netfilter.ip_conntrack_tcp_timeout_established = 432000
 
centos6.1上面如下设置
net.netfilter.nf_conntrack_max = 655360
net.nf_conntrack_max = 655360
查看是否生效
cat /proc/sys/net/netfilter/nf_conntrack_max
655360
 
 
 
           Netfilter conntrack performance tweaking, v0.8
           ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

             Hervé Eychenne <rv _AT_ wallfire _DOT_ org>

This document explains some of the things you need to know for netfilter
conntrack (and thus NAT) performance tuning.

Latest version of this document can be found at:

http://www.wallfire.org/misc/netfilter_conntrack_perf.txt

------------------------------------------------------------------------------

There are two parameters we can play with:
- the maximum number of allowed conntrack entries, which will be called
  CONNTRACK_MAX in this document
- the size of the hash table storing the lists of conntrack entries, which
  will be called HASHSIZE (see below for a description of the structure)

CONNTRACK_MAX is the maximum number of "sessions" (connection tracking entries)
that can be handled simultaneously by netfilter in kernel memory.

A conntrack entry is stored in a node of a linked list, and there are several
lists, each list being an element in a hash table.  So each hash table entry
(also called a bucket) contains a linked list of conntrack entries.
To access a conntrack entry corresponding to a packet, the kernel has to:
- compute a hash value according to some defined characteristics of the packet.
  This is a constant time operation.
  This hash value will then be used as an index in the hash table, where a
  list of conntrack entries is stored.
- iterate over the linked list of conntrack entries to find the good one.
  This is a more costly operation, depending on the size of the list (and on
  the position of the wanted conntrack entry in the list).

The hash table contains HASHSIZE linked lists.  When the limit is reached
(the total number of conntrack entries being stored has reached CONNTRACK_MAX),
each list will contain ideally (in the optimal case) about
CONNTRACK_MAX/HASHSIZE entries.

The hash table occupies a fixed amount of non-swappable kernel memory,
whether you have any connections or not.  But the maximum number of conntrack
entries determines how many conntrack entries can be stored (globally into the
linked lists), i.e. how much kernel memory they will be able to occupy at most.

This document will now give you hints about how to choose optimal values for
HASHSIZE and CONNTRACK_MAX, in order to get the best out of the netfilter
conntracking/NAT system.

Default values of CONNTRACK_MAX and HASHSIZE
============================================

By default, both CONNTRACK_MAX and HASHSIZE get average values for
"reasonable" use, computed automatically according to the amount of
available RAM.

Default value of CONNTRACK_MAX
------------------------------

On i386 architecture, CONNTRACK_MAX = RAMSIZE (in bytes) / 16384 =
RAMSIZE (in MegaBytes) * 64.
So for example, a 32 bits PC with 512MB of RAM can handle 512*1024^2/16384 =
512*64 = 32768 simultaneous netfilter connections by default.

But the real formula is:
CONNTRACK_MAX = RAMSIZE (in bytes) / 16384 / (x / 32)
where x is the number of bits in a pointer (for example, 32 or 64 bits)

Please note that:
- default CONNTRACK_MAX value will not be inferior to 128
- for systems with more than 1GB of RAM, default CONNTRACK_MAX value is
  limited to 65536 (but can of course be set to more manually).

Default value of HASHSIZE
-------------------------

By default, CONNTRACK_MAX = HASHSIZE * 8.  This means that there is an average
of 8 conntrack entries per linked list (in the optimal case, and when
CONNTRACK_MAX is reached), each linked list being a hash table entry
(a bucket).

On i386 architecture, HASHSIZE = CONNTRACK_MAX / 8 =
RAMSIZE (in bytes) / 131072 = RAMSIZE (in MegaBytes) * 8.
So for example, a 32 bits PC with 512MB of RAM can store 512*1024^2/128/1024 =
512*8 = 4096 buckets (linked lists)

But the real formula is:
HASHSIZE = CONNTRACK_MAX / 8 = RAMSIZE (in bytes) / 131072 / (x / 32)
where x is the number of bits in a pointer (for example, 32 or 64 bits)

Please note that:
- default HASHSIZE value will not be inferior to 16
- for systems with more than 1GB of RAM, default HASHSIZE value is limited
  to 8192 (but can of course be set to more manually).

Reading CONNTRACK_MAX and HASHSIZE
==================================

Current CONNTRACK_MAX value can be read at runtime, via the /proc filesystem.

Before Linux kernel version 2.4.23, use:
# cat /proc/sys/net/ipv4/ip_conntrack_max

Since Linux kernel version 2.4.23 (thus Linux 2.6 as well), use:
# cat /proc/sys/net/ipv4/netfilter/ip_conntrack_max
  (old /proc/sys/net/ipv4/ip_conntrack_max is then deprecated!)

Current HASHSIZE is always available (for every kernel version) in syslog
messages, as the number of buckets (which is HASHSIZE) is printed there at
ip_conntrack initialization.
Since Linux kernel version 2.4.24 (thus Linux 2.6 as well), current HASHSIZE
value can be read at runtime with:
# cat /proc/sys/net/ipv4/netfilter/ip_conntrack_buckets

Modifying CONNTRACK_MAX and HASHSIZE
====================================

Default CONNTRACK_MAX and HASHSIZE values are reasonable for a typical host,
but you may increase them on high-loaded firewalling-only systems.
So CONNTRACK_MAX and HASHSIZE values can be changed manually if needed.

While accessing a bucket is a constant time operation (hence the interest
of having a hash of lists), keep in mind that the kernel has to iterate over
a linked list to find a conntrack entry.  So the average size of a linked
list (CONNTRACK_MAX/HASHSIZE in the optimal case when the limit is reached)
must not be too big.  This ratio is set to 8 by default (when values are
computed automatically).
On systems with enough memory and where performance really matters, you can
consider trying to get an average of one conntrack entry per hash bucket,
which means HASHSIZE = CONNTRACK_MAX.

Setting CONNTRACK_MAX
---------------------

Conntrack entries are stored in linked lists, so the maximum number of
conntrack entries (CONNTRACK_MAX) can be easily configured dynamically.

Before Linux kernel version 2.4.23, use:
# echo $CONNTRACK_MAX > /proc/sys/net/ipv4/ip_conntrack_max

Since Linux kernel version 2.4.23 (thus Linux 2.6 as well), use:
# echo $CONNTRACK_MAX > /proc/sys/net/ipv4/netfilter/ip_conntrack_max

where $CONNTRACK_MAX is an integer.

Setting HASHSIZE
----------------

For mathematical reasons, hash tables have static sizes.  So HASHSIZE must be
determined before the hash table is created and begins to be filled.

Before Linux kernel version 2.4.21, a prime number should be chosen for hash
size, ensuring that the hash table will be efficiently populated. Odd
non-prime numbers or even numbers are strongly discouraged, as the hash
distribution will be sub-optimal.

Since Linux kernel version 2.4.21 (thus Linux 2.6 as well), conntrack
uses jenkins2b hash algorithm which is happy with all sizes, but power
of 2 works best.

If netfilter conntrack is statically compiled in the kernel, the hash table
size can be set at compile time, or (since kernel 2.6) as a boot option with
ip_conntrack.hashsize=$HASHSIZE

If netfilter conntrack is compiled as a module, the hash table size can be
set at module insertion, with the following command:
# modprobe ip_conntrack hashsize=$HASHSIZE

where $HASHSIZE is an integer.

Since 2.6.14, it is possible to set hashsize dynamically at runtime,
after boot and module load.

Between 2.6.14 and 2.6.19 (included), use:
# echo $HASHSIZE > /sys/module/ip_conntrack/parameters/hashsize

Since 2.6.20, use:
# echo $HASHSIZE > /sys/module/nf_conntrack/parameters/hashsize

Ideal case: firewalling-only machine
------------------------------------

In the ideal case, you have a machine _just_ doing packet filtering and NAT
(i.e. almost no userspace running, at least none that would have a growing
memory consumption like proxies, ...).

The size of kernel memory used by netfilter connection tracking is:
size_of_mem_used_by_conntrack (in bytes) =
        CONNTRACK_MAX * sizeof(struct ip_conntrack) +
        HASHSIZE * sizeof(struct list_head)
where:
- sizeof(struct ip_conntrack) can vary quite much, depending on architecture,
  kernel version and compile-time configuration. To know its size, see the
  kernel log message at ip_conntrack initialization time.
  sizeof(struct ip_conntrack) is around 300 bytes on i386 for 2.6.5, but
  heavy development around 2.6.10 make it vary between 352 and 192 bytes!
- sizeof(struct list_head) = 2 * size_of_a_pointer
  On i386, size_of_a_pointer is 4 bytes.

So, on i386, kernel 2.6.5, size_of_mem_used_by_conntrack is around
CONNTRACK_MAX * 300 + HASHSIZE * 8 (bytes).

If we take HASHSIZE = CONNTRACK_MAX (if we have most of the memory dedicated
to firewalling, see "Modifying CONNTRACK_MAX and HASHSIZE" section above),
size_of_mem_used_by_conntrack would be around CONNTRACK_MAX * 308 bytes
on i386 systems, kernel 2.6.5.

Now suppose your firewalling-only box has 512MB of RAM (a decent amount
of memory considering today's memory prices). You have to spare a bit of
memory for a few applications (syslog, etc.): 128MB should really be big
enough for a firewall in console mode, for example.
The rest can be dedicated to conntrack entries.
Then you could set both CONNTRACK_MAX and HASHSIZE approximately to:
(512 - 128) * 1024^2 / 308 =~ 1307315 (instead of 32768 for CONNTRACK_MAX,
and 4096 for HASHSIZE by default).
Since Linux 2.4.21 (thus Linux 2.6 as well), hash algorithm is happy with
"power of 2" sizes (it used to be a prime number before).

So here we can set CONNTRACK_MAX and HASHSIZE to 1048576 (2^20), for example.

This way, you can store about 32 times more conntrack entries than the
default, and get better performance for conntrack entry access.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Last changes on Jan 10, 2008

Revision history:
0.8 Make the "Ideal case: firewalling-only machine" paragraph a bit more clearer.
0.7 Hashsize parameter can be set dynamically since Linux 2.6.14.  Thanks
    to Christopher A. Craig for the suggestion.
0.6 Hashsize parameter can be set at boot time with Linux 2.6.  Thanks to
    Tobias Diedrich for pointing this out.
0.5 Added further notice about the varying length of the conntrack structure.
0.4 Since Linux 2.4.21, hash algorithm is happy with all sizes, not only
    prime ones.  However, power of 2 is best.
0.3 Various small precisions.
0.2 Information about Linux kernel versions and corresponding /proc entries.
    (/proc/sys/net/ipv4/netfilter/ip_conntrack_{max,buckets}).
0.1 Initial writing, largely based on my discussions with Harald Welte
    (netfilter maintainer) on the netfilter-devel mailing-list.  Many thanks
    to him!

本文转自it你好 51CTO博客,原文链接:http://blog.51cto.com/itnihao/829172,如需转载请自行联系原作者

相关文章
|
缓存 资源调度 JavaScript
Node.js 包管理器(Corepack)
Node.js 包管理器(Corepack)
|
Shell Android开发
解决Android的adb命令行报错Permission denied
解决Android的adb命令行报错Permission denied
2466 0
解决Android的adb命令行报错Permission denied
|
2月前
|
存储 缓存 调度
vLLM 吞吐量优化实战:10个KV-Cache调优方法让tokens/sec翻倍
十个经过实战检验的 vLLM KV-cache 优化方法 —— 量化、分块预填充、前缀重用、滑动窗口、ROPE 缩放、后端选择等等 —— 提升 tokens/sec。
730 10
|
3月前
|
安全 程序员 数据库连接
web渗透-CSRF漏洞
CSRF(跨站请求伪造)是一种常见的Web安全漏洞,攻击者通过伪造用户请求,诱使其在已登录状态下执行非意愿操作。本文介绍CSRF原理、分类(站外与站内)、DVWA靶场搭建及防御措施,如同源策略与Token验证,提升安全防护意识。
442 0
web渗透-CSRF漏洞
|
6月前
|
数据采集 机器学习/深度学习 Java
Java 大视界 —— Java 大数据在智慧交通停车场智能管理与车位预测中的应用实践(174)
本文围绕 Java 大数据在智慧交通停车场智能管理与车位预测中的应用展开,深入剖析行业痛点,系统阐述大数据技术的应用架构,结合大型体育中心停车场案例,展示系统实施过程与显著成效,提供极具实操价值的技术方案。
|
11月前
|
机器学习/深度学习 边缘计算 运维
机器学习在网络安全中的防护:智能化的安全屏障
机器学习在网络安全中的防护:智能化的安全屏障
484 15
|
9月前
|
人工智能 缓存 UED
deepseek-vue3ai流式输出AI对话助手
原创新作vue3.5+deepseek+vite6+vant4仿DeepSeek-R1流式输出ai聊天对话。支持AI流式打字输出效果、浅色/暗黑主题模式、代码高亮、针对移动端+PC端适配处理。
795 65
|
监控 关系型数据库 MySQL
深入了解MySQL主从复制:构建高效稳定的数据同步架构
深入了解MySQL主从复制:构建高效稳定的数据同步架构
355 1
|
缓存 图形学 UED
U3D开发技术深度解析:异步场景加载与资源管理优化策略
【7月更文第11天】在Unity3D(简称U3D)游戏开发中,优化场景加载与资源管理是提升用户体验的关键一环。通过实现高效的异步场景加载和智能的资源管理策略,我们能显著缩短玩家的等待时间,提升游戏流畅度。本文将详细介绍这两种技术的应用,并提供实用的代码示例。
1241 0
|
消息中间件 网络安全 数据安全/隐私保护
麒麟系统ARM安装rabbitmq
记录下麒麟liunx系统安装rabbitmq的踩坑记录,按照我这个步骤来,100%解决问题。 希望对您有帮助!
麒麟系统ARM安装rabbitmq