构建一台大容量的NAT服务器

ShadowStar

原帖由 old-cow 于 2008-7-10 13:08 发表
eth0 和 eth1 配置成透明的网桥模式,还能不能做NAT呢?

可以，因为netfilter已经hook进bridge的处理函数了。

ShadowStar

原帖由 platinum 于 2008-7-10 14:09 发表
要看这些高速小包（pps 很大的时候）的 tuple 是不是很多
如果这些小包都是同一个 tuple，那么几乎没什么过多由于 conntrack 带来的消耗
但是，如果是 syn-flood 这样的东西过来，每一个包可能都是唯一一个 tuple，那么性能就会骤然下降，而且由于 conntrack_max 设置过大还有可能导致内核崩溃

conntrack_max限定的是nf_conn的数量，它应该是tuple ＊ 2。设置过大仅仅会导致内存耗尽。理论上来说并不是内核崩溃的直接原因。

其实不管是不是一个tuple，只要pps够大，都会造成很大的影响，毕竟没个数据包都要计算hash的。这个计算是CPU时间消耗最高的。

platinum

原帖由 ShadowStar 于 2008-7-10 14:38 发表


conntrack_max限定的是nf_conn的数量，它应该是tuple ＊ 2。设置过大仅仅会导致内存耗尽。理论上来说并不是内核崩溃的直接原因。

其实不管是不是一个tuple，只要pps够大，都会造成很大的影响，毕竟没个数 ...

我以前做过试验，内存溢出后 socket 会有问题，ssh 会断开，系统很多 app 都无法正常运行
另外，2.6 内核系统里有个 pktgen，可以发送特制的 udp 包
如果这些包是同样的 sip 和 dip，pps 可以轻松到达 10Wpps
如果是不同的，但 IP 变化范围小于 conn_max，则通过率是一样的
但是，如果范围大于 conn_max，则通过率骤减为原来的 1/4 甚至 1/5
同时，去掉 nf_conntrack_ipv4 功能，则恢复成 10W 左右（用 PC 测试的，打压机器和受测机器性能都有限）
由此证明
1、IP 变化范围 < ip_conntrack_max 时，基本上没有消耗，基本上等同于没有 conntrack 状态
2、IP 变化范围远远 > ip_conntrack_max 时，conntrack 性能骤降，成为性能

以上测试环境：
PC1 ------ LINUX(bridge) ------ PC2

ShadowStar

原帖由 platinum 于 2008-7-10 14:48 发表

我以前做过试验，内存溢出后 socket 会有问题，ssh 会断开，系统很多 app 都无法正常运行
另外，2.6 内核系统里有个 pktgen，可以发送特制的 udp 包
如果这些包是同样的 sip 和 dip，pps 可以轻松到达 10Wp ...

HASH就是这样啊，随着实际数据数量趋进于hash_size，碰撞越来越多。
当最恶劣的情况出现时，hash算法的复杂度由O(1)变为O(n)，退化为链表，性能当然会严重下降。

水田青蛙

mark

old-cow

原帖由 ShadowStar 于 2008-7-10 14:33 发表


可以，因为netfilter已经hook进bridge的处理函数了。

谢谢!

--------------------------------------
编辑/root/nat如下：
# eth0 is internet interface
# eth1 is intranet interface
INCOMING=eth0
OUTGOING=eth1
ip addr add 222.222.222.8 dev $OUTGOING
ip addr add 222.222.222.9 dev $OUTGOING
ip addr add 222.222.222.10 dev $OUTGOING
ip addr add 222.222.222.11 dev $OUTGOING
IPPOOL=222.222.222.8-222.222.222.11

iptables -t nat -F
iptables -t nat -A POSTROUTING -s 内部IP地址/子网 -o $OUTGOING -j SNAT --to $IPPOOL

iptables-save -c >/etc/sysconfig/iptables

=--------------------------------------------------

那么对于上面的操作需要进行怎样的修改呢?

old-cow

环境是用 eth0 和 eth1 做了 br0.

wheel

测了下还是有swap分区的好。。

platinum

原帖由 wheel 于 2008-7-10 16:10 发表
测了下还是有swap分区的好。。

纯内核部分不会写入 SWAP 的

platinum

原帖由 ShadowStar 于 2008-7-10 15:06 发表


HASH就是这样啊，随着实际数据数量趋进于hash_size，碰撞越来越多。
当最恶劣的情况出现时，hash算法的复杂度由O(1)变为O(n)，退化为链表，性能当然会严重下降。

如果 bucket 够大，按理说是不是就不会这样了呢？
或者说，是 netfilter 的 hash 函数写的不好，引起过多碰撞？