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

ippen

呵呵，cu真是高手如云啊，看样子这个贴子发的太迟了，早点发能学到更过东西

原帖由 ShadowStar 于 2008-7-9 14:34 发表


我之前的工作中，用一台双CPU，4核的系统作全部上网流量的过滤和控制，一直没出过问题。
流量高峰大概400Mbps，平时也有200－300Mbps。

原帖由 wchun 于 2008-7-9 21:28 发表
楼主请看我以前发过的贴：
http://linux.chinaunix.net/bbs/thread-835936-1-1.html

我觉得使用多IP进行NAT不应该使用-j SNAT。

The history of SAME is to make a target act like SNAT, but choose th ...

上面两位兄弟能不能说说你们用的硬件设备配置，使用的linux系统的版本，以及对系统作了什么调整？现在系统的并发连接数和流量是多少？

我目前仍然存在的问题
1.使用双cpu是否能有效提高流量和并发连接数
2.系统抵御高速小包的能力如何？现在我让系统跑16w的并发连接，主因就是要避免这种情况，留有余量对系统稳定有好处，所以非常希望了解一下其他兄弟的看法和做法。
对于wchun的不用 SNAT 的问题，我是用另外的方法解决的，将出现问题的网站单独nat到一个ip上，就可以了

ippen

拜读了兄弟的帖子
http://linux.chinaunix.net/bbs/thread-835936-1-1.html

原帖由 wchun 于 2006-9-29 11:51 发表

net.ipv4.netfilter.ip_conntrack_tcp_timeout_established = 900
net.ipv4.netfilter.ip_conntrack_buckets = 1048576
net.ipv4.netfilter.ip_conntrack_count = 56567
net.ipv4.netfilter.ip_conntrack_max = 1048576


由于网络规模大，有几千台机器吧。高峰时期ip_conntrack_count 可以到20万。使用6个公网地址做SNAT.

有个疑问,当中的net.ipv4.netfilter.ip_conntrack_max = 1048576，才1万并发连接，而下面说20万，是不是参数错了？

[ 本帖最后由 ippen 于 2008-7-10 09:28 编辑 ]

platinum

原帖由 ippen 于 2008-7-10 09:27 发表
拜读了兄弟的帖子
http://linux.chinaunix.net/bbs/thread-835936-1-1.html



有个疑问,当中的net.ipv4.netfilter.ip_conntrack_max = 1048576，才1万并发连接，而下面说20万，是不是参数错了？

1048576 好像是 1024 * 1024 的结果，也就是 1M 个并发数，也就是 100W 个

ShadowStar

原帖由 platinum 于 2008-7-9 23:48 发表

为什么说单 IP 4W 连接的说法是没有道理的呢？没想通

只要保证”SIP:sport -> DIP:dport“唯一就可以了。

也就是说：A,C（客户）——B（网关NAT）——D,E（外网）
A:5000 -> D:80 —— B:5000 -> D:80
C:5000 -> E:80 —— B:5000 -> E:80
是可以成功的。
B的5000端口是可以复用的。
所以单IP SNAT的数量并不一定小于端口数量。

ShadowStar

原帖由 ippen 于 2008-7-10 09:18 发表
呵呵，cu真是高手如云啊，看样子这个贴子发的太迟了，早点发能学到更过东西

上面两位兄弟能不能说说你们用的硬件设备配置，使用的linux系统的版本，以及对系统作了什么调整？现在系统的并发连接数和流量是多少？

我目前仍然存在的问题
1.使用双cpu是否能有效提高流量和并发连接数
2.系统抵御高速小包的能力如何？现在我让系统跑16w的并发连接，主因就是要避免这种情况，留有余量对系统稳定有好处，所以非常希望了解一下其他兄弟的看法和做法。
对于wchun的不用 SNAT 的问题，我是用另外的方法解决的，将出现问题的网站单独nat到一个ip上，就可以了

我说的之前工作中的是采用的2＊Opteron 2212的CPU，4GB内存，Intel 82544的网卡，conntrack_max = 2097152。硬件配置好象是这样，记不太清楚了。
系统版本不重要，主要是内核，我那时候用的是2.6.23的，Gentoo的。

1。双CPU对于提高流量和并发肯定是有帮助的。
2。所谓的高速小包，无非就是同样带宽的情况下，pps更高罢了，因为对于系统来说，数据包的大小对吞吐量的影响并不大，只是在copy时有点影响，大部分消耗系统资源的就是针对数据包头的计算，尤其以conntrack的hash计算最为严重。路由表的查找也是hash计算的，但是比conntrack好多了。还有就是ip／tcp报头中校验值的计算。
要想提高性能，无非就是把没用的干掉罢了。

kevin.tan

原帖由 ShadowStar 于 2008-7-9 14:29 发表


说句实话，目前在做的就是内核方面的工作。所以也没时间维护特征码的更新了。

ipp2p那个在2.6.24／iptables-1.4.0上工作没什么问题，也做了一些改进。但是不太好往外摘，因为我都是直接做到内核代码树里 ...

ShadowStar兄好强

dbtwater

学习
学习。。。

old-cow

eth0 和 eth1 配置成透明的网桥模式,还能不能做NAT呢?

depthblue_xsc

好久没见到这种级别的帖子了，顶一个

platinum

原帖由 ShadowStar 于 2008-7-10 10:54 发表
2。所谓的高速小包，无非就是同样带宽的情况下，pps更高罢了，因为对于系统来说，数据包的大小对吞吐量的影响并不大，只是在copy时有点影响，大部分消耗系统资源的就是针对数据包头的计算，尤其以conntrack的hash计算最为严重。路由表的查找也是hash计算的，但是比conntrack 好多了。还有就是ip／tcp报头中校验值的计算。
要想提高性能，无非就是把没用的干掉罢了。

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