已在7000人的校园网络中部署桥式panabit，谈下个人感觉。
以前用开centos linux中brigde模式。运用iptables,ipp2p和l7filter。现在ipp2p停止开发了，l7的效果实在不明显。但是还是很喜欢linux里面connlimit和time功能。linux有灵活的contrack可以使用，适当的使用脚本可以统计连接数巨多的udp端口进行阻挡;使用connlimit可以对每ip的限制连接数。panabit在管理界面上是一流的，但是识别率还有待提高。具体表现是未知流量占90%，游戏流量无法识别。灵活性还是不够，功能上感觉增加tcp和udp端口block功能以及连接数限制功能，这两个方面应该不是难事，恳请版主帮忙。:lol
目前校园网的出口带宽是远远跟不上内网用户的需求的，不但是p2p，还有网络游戏流量；都必须满足，个人采取的办法是按时段分流，但是识别率存在的问题，很难做到精细。
[ 本帖最后由 hjc0759 于 2007-7-2 16:29 编辑 ] 原帖由 hjc0759 于 2007-7-2 16:15 发表 http://www.panabit.com/forum/images/common/back.gif
以前用开centos linux中brigde模式。运用ipp2p和l7filter。现在ipp2p停止开发了，l7的效果实在不明显。但是还是很喜欢linux里面connlimit和time功能。linux有灵活的contrack可以使用，适当的使用脚本可以统计连 ...
这么大的网络，使用标准版估计不行。这也许就是为什么90%无法识别的原因吧。 原帖由 panabit 于 2007-7-2 16:19 发表 http://www.panabit.com/forum/images/common/back.gif
这么大的网络，使用标准版估计不行。这也许就是为什么90%无法识别的原因吧。
你使用floweye flow stat看看你的最大flow数有多少，有没有alloc fail的情况。 BTW,能否给我们抓一下maze的数据包？
谢谢先！ 原帖由 panabit 于 2007-7-2 16:19 发表 http://www.panabit.com/forum/images/common/back.gif
这么大的网络，使用标准版估计不行。这也许就是为什么90%无法识别的原因吧。
呵呵。没敢在单线上部署，上传链路上面部署了桥而已。个人感觉处理能力还是有余的，服务器是hp ml530.
上传流量一般是80Mb左右 原帖由 panabit 于 2007-7-2 16:20 发表 http://www.panabit.com/forum/images/common/back.gif
你使用floweye flow stat看看你的最大flow数有多少，有没有alloc fail的情况。
# floweye flow stat
tcpflow num: 1
udpflow num: 13816
alloci failed: 0
pool size: 65536
pool base: 0xc7643000
pool iterator: 0xc7808480(29010)
pool highwater: 0xc7964fc0
maximum flow: 51328
btw 你们都是热心人。谢谢 原帖由 panabit 于 2007-7-2 16:21 发表 http://www.panabit.com/forum/images/common/back.gif
BTW,能否给我们抓一下maze的数据包？
谢谢先！
可以。如何操作呢。也听说这个协议的霸道了。 原帖由 hjc0759 于 2007-7-2 16:27 发表 http://www.panabit.com/forum/images/common/back.gif
可以。如何操作呢。也听说这个协议的霸道了。
sniffer 抓咯。
7000 人的网络，能否上张图看看。:victory: sniffer的pc显然受不了那么大的流量了。既然panabit是个桥，我想调试模式也应该有吧。这个就可以抓包了。 原帖由 ihweb 于 2007-7-2 16:47 发表 http://www.panabit.com/forum/images/common/back.gif
sniffer 抓咯。
7000 人的网络，能否上张图看看。:victory:
panabit部署在两台8800之间