对bypass的一点疑问！
panabit的开发者你们好！我看过了网站上关于bypass的介绍，加之以前工作中曾多少接触过一些，有一点疑问提出来供你们参考。panabit是很不错的东西，希望能够越来越好！我看到文档里面介绍，要把bypass和watchdog功能作一联动，系统宕机时，“狗”不能被定时“喂”，于是就会触发系统重启，或者切换到bypass模式下。我的疑问是，在很多情况下，系统是不会宕机的，而仅仅是桥接的接口出现问题，不能正常通信。例如，前段时间我用了0805版本，当时跑几个小时桥接就不通了，但是系统确实是正常运转的，没有down掉。那么这个时候，是不是也符合触发bypass起作用的条件呢？
众所周知，网桥设备的系统若要提高可靠性，能够智能的bypass是非常重要的。我没有设备进行测试，也没有太深的研究，但是在你们提供的文档中，我只看到系统宕机时会切换到bypass模式，保持网络畅通，没有看到当桥接部分功能出问题时，bypass是否也能够起作用的描述，不知道这部分功能是否有价值，供你们参考吧！
另外，顺便说一下，关于MAC地址的问题。在panabit里面，查看TOPN个IP的流量的时候，能否把IP地址对应的MAC地址也打印出来？我想这个从技术上很容易就能实现。为什么提这个建议呢，源于实际应用中，网管人员都有一个IP和MAC地址绑定或者对应的需求，当然这个绑定不需要在网桥设备上做。如果网管没有在网关设备上进行IP/MAC的显性绑定，那么即使在panabit上做了很完善的限速策略，仍无法避免终端用户自己擅自修改IP地址来逃避监管的现象。而且，不是所有的网关设备都有这样的功能，也不是所有的网管都喜欢绑定IP/MAC。所以，如果在panabit上有一个IP地址和MAC地址对应的话，那么网络管理者的工作会轻松一些，无论IP如何改，去篡改MAC难度还是大一些，那么有了直观的MAC数据，去定位到出问题的机器也会容易一些，不知道这么说是不是清楚了。 在部分三层交换网络中，panabit是安装在网络出口如防火墙之后的，单机的数据包经过三层交换机后传到panabit再传到防火墙或NAT出去，在panabit收到三层交换机的数据包时，这时的MAC地址已经是三层交换机的MAC地址了，而不是原来单机的MAC地址。在三层交换机里还储存着单机MAC的对应表。简单的说就是单机的MAC地址无法通过三层交换传到panabit上。 用了三层交换当然没有办法了，但是好像不是所有人都有钱三层交换吧？ 原帖由 hips 于 2008-7-22 11:28 发表 http://www.panabit.com/forum/images/common/back.gif
panabit的开发者你们好！我看过了网站上关于bypass的介绍，加之以前工作中曾多少接触过一些，有一点疑问提出来供你们参考。panabit是很不错的东西，希望能够越来越好！
我看到文档里面介绍，要把bypass和watchdog功 ...
谢谢您的提议！
1. 关于bypass
“网桥部分出问题”后触发bypass，这个理论上是可以做，我们会根据实际的情况，看是否需要将这部分加进去。我们希望byass控制这一块同panaos是独立的，这样就不会受panaos影响。
2. 关于IP-MAC绑定
这个功能需要调查一下，看看到底有哪些网友需要，如果确实有很多这方面的需求，我们会加进去。你不妨在论坛上发个帖子调查一下。 hips提到的两点我表赞同，期待panabit在这方面能加强完善！ 原帖由 panabit 于 2008-7-22 12:22 发表 http://www.panabit.com/forum/images/common/back.gif
谢谢您的提议！
1. 关于bypass
“网桥部分出问题”后触发bypass，这个理论上是可以做，我们会根据实际的情况，看是否需要将这部分加进去。我们希望byass控制这一块同panaos是独立的，这样就不会受panaos影响 ...
1，所谓单点故障呢，在你们的模型里，我看到了两个可能性：系统宕机和panaOS实效。所以仅仅避免宕机故障是不完全的。我不了解你们设计这套东西的具体理念，但从产品角度而言，可靠性越高的东西用户价值越高。
在这里，能够让设备从单点故障里摆脱的方式，好像只有通过bypass。PanaOS是不能够保证100％的可靠性的，这不是技术问题，而是个显然的问题，因为没有东西能够保证自己100％正确。所以如果我做决策，我不会考虑程序或者模块的纯洁性问题，有些时候，用户价值是首要的，你说对吗？
2，我去“问题解答”发了帖子了。:lol 原帖由 hips 于 2008-7-22 14:11 发表 http://www.panabit.com/forum/images/common/back.gif
1，所谓单点故障呢，在你们的模型里，我看到了两个可能性：系统宕机和panaOS实效。所以仅仅避免宕机故障是不完全的。我不了解你们设计这套东西的具体理念，但从产品角度而言，可靠性越高的东西用户价值越高。
...
你说的没错！
但是从设计和实现的角度看，有时需要在复杂度和功能之间做一个平衡，并且需要划定一个明晰的问题边界。
我们刚开始是希望bypass控制这一块独立于panaos。目前网桥如果出现问题，那基本上只有两个可能：
1）master panaos crash，此时slave panaos会接管系统，然后它自己变成master，系统重新准备一个新的slave panaos.
2) panaos内部出现死循环：这说明程序逻辑出现问题，不应该划归于意外情况，而且这个不应该以bypass手段解决。
从目前所有的专业版运行情况看，还没有出现过由于panaos出现问题而导致bypass的问题。但是，正于你说述，没有谁会100%信任软件，只不过需要做一个平衡而以。
如果仔细研究一个好的系统，我们往往发现，其做的好是由于其在各种因素之间的平衡把握得好，我也希望自己能够达到这个境界。 楼上hips的意思我明白了，在软件系统方面引起单点故障的因素可以有：
1. 系统宕机
2. 网桥故障
3. PanaOS失效
如果上述因素都和WatchDog联动，从而激发bypass那么就更加合理了。
[ 本帖最后由 allenpeng 于 2008-7-22 22:41 编辑 ] 原帖由 panabit 于 2008-7-22 14:32 发表 http://www.panabit.com/forum/images/common/back.gif
你说的没错！
但是从设计和实现的角度看，有时需要在复杂度和功能之间做一个平衡，并且需要划定一个明晰的问题边界。
我们刚开始是希望bypass控制这一块独立于panaos。目前网桥如果出现问题，那基本上只有两个 ...
较一下真，别介意啊！我感觉你说来说去，跟我不在一个平台上。你也说了软件的可靠性达不到100％，那么用master还是用slave，只是在软件这个层面上做了一个热备这种概念的东西，并不能突破自身的可靠性范畴；软件自身逻辑问题，那属于bug。但是无论你找出来多少bug，或者稳定运行很长时间出了问题没归结到OS身上，这都不能从逻辑上严密的证明整个体系的可靠性和稳定性值得信赖。我已经提到了当初贵程序的0805版本，试用中我确实遇到了这样的问题，找原因那是开发者的问题，但是无论是什么原因，保证用户的网络正常是一个产品必须首要考虑的，就像研究飞行器，从来都是把飞行员逃生放到第一位，除了小日本的神风。你不能说我这个功能没发现问题，就不考虑出问题时的应对。
从交流中看，我觉得你们的设计理念肯定是精益求精，设计智慧也体现得淋漓尽致，而且做到bsd的kereel级别，国内也算领先了。但是如果我是产品总监或者为了一个重要的网络选型，那么我可能会犹豫，原因非常简单，我没有看到可靠性所在。宕机或者软件失效不是假设，而是现实存在的问题，没有好的应对策略，那么这套设计就是有风险的。在市场上，为了终极的成功，这种风险是不被允许存在的。
每一个设计者，开发者都有自己的偏执性，其实是对自己产品的自信，这一点是值得钦佩的。再次重申，交流而已，无抬杠冒犯之意！ 原帖由 hips 于 2008-7-22 17:07 发表 http://www.panabit.com/forum/images/common/back.gif
较一下真，别介意啊！我感觉你说来说去，跟我不在一个平台上。你也说了软件的可靠性达不到100％，那么用master还是用slave，只是在软件这个层面上做了一个热备这种概念的东西，并不能突破自身的可靠性范畴；软件 ...
我没有觉得你抬杠，呵呵。
我认为你说的很有道理，BTW，你使用8.05的那个特征库出现了网桥问题？
页:
[1]
2