一个网络配置验算器的设备设想

Sina WeiboBaiduLinkedInQQGoogle+RedditEvernote分享




最近看到appleleaf写得一系列文章,虽然没有仔细看,但是标题就让我很敬佩了。昨天和陈首席还谈到这一点。今天洗澡的时候又想起这个问题,把我之前写的一篇blog翻出来,与大家分享。

最近几年不用功,所以不知道是不是有这样的设备。记得几年前有过类似的设备,不过是通过监听之后进行验算,推演出网络的拓扑的软件。不过我这个想法可能有些不一样。

我的想法是有个软件或者类似过去思科和Juniper工程师在考试时都用过的模拟机,模拟一个网络上的所有设备,及设备上所有的配置。然后模拟一下流量,看看这些配置是否配合的比较好,或者是否有冲突。这个设备主要的作用是在设备部署之前,验算一下所有的配置是否有问题。而在一个已经部署的网络上开通因为新的业务诞生,而带来新的配置需求的时候,进行一下新配置的测试,看看是否有冲突,是否会因为一些配置的问题在网络中出现一些黑洞。

这个配置有些像ixia或者spirent等测试仪器的协议一致性测试仪,以及前面提到的模拟机,还有就是思博伦、IXIA的流量发生测试仪器。另外可以界面有些像编程里的DEBUG工具,可以一次运行然后出个报告,也可以一步步的调试,看问题究竟在哪里。

这个东西可以有几个阶段,第一个阶段是验证网络设备,第二个阶段是验证服务器的配置,第三阶段是安全设备的配置。最好的情况是能够基于整个系统进行完整的 验证性测试。

我觉得类似的东西还是很需要,现在的一些网络规模很大,而且上面跑得应用,以及一些安全的要求很高,所以配置会比较复杂,安全、QoS、静态、动态路由。而且在数据中心里,由于有虚拟机的出现,可能有很多动态的配置会有出现。

一个严谨的运营商、严谨的客户比如电力用户,我觉得很有必要,每次网络调整,新上线设备,都可以进行迭代性的测试,先看看是否适应以前的业务,看看以前的问题情况是否会类似出现,然后看看未来的东西是否会冲突。冲突是在哪里。

帖上原来blog的原文,原文链接在这里复杂的网络服务部署之后如何验收网络没有问题呢?,时间是2009年2月17日。如果有公司想做类似的产品,又需要一个没有经验的产品经理,欢迎来找我,首席有我的联系方式。我个人是做不了这个东西,因为我不会编程序,但是我可以把需求再细化,而且有过带团队和一定的销售沟通经验。如果能够有人和我一起做这个产品,我会把我从这个产品的收入的1%贡献给弯曲评论。大家也给我出出主意,这个东西我咋能够赚更多的钱。

原文如下《复杂的网络服务部署之后如何验收网络没有问题呢?》

今天有一个朋友提出了个问题,假如网络部署完了,如何验证MPLS VPN、QoS配置正确呢?虽然我们正在和Fluke合作一个网络维护的专区,但是我个人觉得现在的解决 方案还难以满足。我想了个方法,可能有些难度,但是还是值得尝试的。

首先分析一下客户的可能需求。这个验收测试中,其实用户担心的不是设备不支持,更担心的是配置的错 误或者搭建的错误或者其他的失误没有实现最初的预期。

难题在哪里呢?这样一个测试实际上很难做。比如QoS这样的配置很复杂,配错了并不会不通,流量小的时候看不出来,所以一般的ping一下,或者 tracert一下,或者点播一下一个视频源,打个电话可能不能体现出来真正的问题,只有在网络开始正常运行的时候才会发现问题,这时候损失已经造成了。

Fluke虽然现在按照国标做了一个方案,但是这个方案显然在应付大型特别是特大型的电信运营商网络的时候还是存在问题。比如验证运营商城域网或者省域网 络里的MPLS VPN配置,QoS配置是否正确很难。现在运营商的网络动辄就是几个G,几十G,乃至百余G的带宽,小仪表很难达到要求(要在拥塞的时候才能体现出来)。Spirent CommunicationIXIA或者安捷伦的方案是可以做得,而且以前这些测试仪器厂 商也有过类似的尝试,但是说句实话,对于大多数运营商来说要做这样的测试也不太容易,凑够能够形成拥塞的如此大量的仪表端口,在中国很难,世界上也很难, 我看除了Spirent Communication或者思 科和Juniper自己的实验室外,一下子凑齐那么多端口挺难的。另外,就是如果要做测试,并不仅仅要拥塞,还要验证 延迟的情况,因为很多QoS的策略需要较复杂的验证,不是说光丢包,还要看高SLA的业务是否没有丢包,而且没有延迟;稍差一些的SLA的业务是否,没有 丢包但是考router的buffer调度,降低了延迟品质。这还要做很多仪器之间的时钟同步。

如果如此去解决方案,要不凑不够设备没法做,要不就是高射炮打了蚊子。

如果客户只是要验证是否配置正确,业务部署正确,就不需要按照实验室测试的方法进行压力测试。因为用户选型的时候会进行详细的对比测试,产品分析,这些工 作会知道哪些板卡支持哪些功能和业务,buffer是否能行,功能是否能够支持,选型阶段基本上已经解决了支持不支持的问题。现在的问题是配置是否真的正 确了,业务是否部署了,特别是很多设备在一起的时候。

这个要求有些像软 件测试工作,拿着产品最初的设计文档,测试是否都达到了最初的设计指标。其实,在部署过程中可能会有很多问题,漏了的 问题,或者想错了的地方可能都会影响配置。现在的网络我觉得配置会越来越复杂,在运营商网络现在有很多业务还有安全要求,要在融合的网络里支持多种服务质 量要求的业务,以及支持移动语音、移动视频服务。在企业级网络里,数据中心之外要支持多媒体应用和复杂的安全配置,在数据中心里涉及到虚拟化、存 储也有很复杂的配置。和过去的路由起来,vlan和生成树配好就ok不一样。

我想能否分检查和测试两个层面。测试也分两个层面,验证性和抽测。

检查实际上和小学、中学数学里的验算差不多。

测试的第一个层面是验证性测试。能否结合Sniffer的方法和程序的方法来做呢?我记得好像Juniper的router可以做在线的抓包,主要针对路 由协议等等。这个的思路还是考虑到现在很多复杂的业务都会有一些协议必然的开销在网络设备之间和网络设备与终端之间交互,通过捕捉包,关联,比对正确模 板,看配置是否有误。比如一个第三方软件全网注重收集所有节点的协议信令,配合实现输入的拓扑信息,进行关联,来验证是否实际网络的配置复合你的预期。而 且我觉得应该可以开发一个模拟器,把我们的需求翻译成配置,在翻译成设备之间相关信令的交互过程,这样就可以把实际网络的收集信息与标准模板进行匹配,有 问题的报警。协议模拟器,以前在测试router的时候很多测试厂商都会开发类似的协议一致性测试软件。通过逐个比对,确认没有错误。

由于有些业务需要发起后才会体现配置的正确与否,验收方还可以抽样发起一些业务,同时在每个节点抓包,再进行匹配,因为有些信令、协议开销是要业务发起的 时候才会产生。

另一点,我觉得就是抽样测试。我想可以在有一定流量后,利用一些点进行业务模拟,而后看情况。网络里要部署一些探针,类似Sniffer或者说有些基于应 用层的协议分析软件,看实际情况。

在验收之后,就是需要运营商进行试运行,其实运营商都会做。这个过程中,必须要全面部署一些探针,关键节点部署。有一个汇总系统,来看是否存在问题。

我觉得需要一个这样的系统来支持如此验收测试。第一是全网主要节点部署的探针,一个探针信息的汇总收集、分析平台,这个平台要能够根据一些我们关注的业务 进行关联,如果只是一些数据包,客户是很难进行分析的。第三是一个演算平台,可以集成一些协议一致性测试软件,把我们的需求翻译成配置,配置然后进行模 拟,可以实现收集信息和模拟的信令进行比对。另外,如果有些流量发生软件,在一些服务器和计算机上可以部署,并且在抓包信息的分析汇总平台上看 到我们测试的流量,这个方案会更好一些。

初步想到这些,欢迎各位拍砖。

(1个打分, 平均:5.00 / 5)

雁过留声

“一个网络配置验算器的设备设想”有9个回复

  1. wenlujon 于 2010-03-05 4:19 下午

    意思是说Spirent Communication和IXIA能够做你的这种验证?但是限制是很难“凑够能够形成拥塞的如此大量的仪表端口”:
    1)需要多少端口,并且这个主要是受什么制约而导致不能凑够如此多的端口?
    2)你的设想可以解决以上限制?也就是说,到时候如果你的设想产品化之后,大家为何要买你的产品而不买Spirent Communication和IXIA?

  2. 理客 于 2010-03-05 11:36 下午

    出恭和洗澡等对大荣顿悟idea的时候:)
    这个不是用来完全代替物理上的测试,而是做物理测试能做但实际上做起来feasibility有问题的地方,是很好的complementation,每个vendor都应该去做,同时,市场还需要一个cross vendor的产品,这个应该是一个有实际市场空间的产品,但是难度和工作量确实很大,其实不只这一个产品,对于网络,需要两个:
    1、网络规划和budget:用什么模式(L2/L3/MPLS,SDH/CWDM/DWDM,DSL/MW/GPON)等等涉及的非常多,建网是5年内TCO最小的,实际还涉及到business plan,competitor、技术演进等更多的复杂方面,运营商希望有一个工具能近似的做大部分的这些事,给出基于数据的分析,解决其设备和网络演进如何match其marketing的问题,因为运营商自己的能力有限,也可能被vendor忽悠,这都是有现实的教训的
    2、就是大荣的delivery和maintenance工具

    这方面,top的vendor肯定是有在research的,但是drivers不足,因为没有这些,可能对这些大vendor更好,这里没有和高深的技术瓶颈,但投入是比较大,如果要真正做出商用产品了,vendor是靠不住的,还得第三方,open source估计也没有兴趣,这个太小众了

  3. ABC 于 2010-03-06 5:17 上午

    荣总的想法和设计确实对一些大的SP和行业客户很有帮助。
    做这样一套系统,难度不亚于做出IXIA和Smartbits。
    做这样一套东西出来,与其卖产品不如卖服务。

  4. 陈怀临 于 2010-03-06 2:03 下午

    我个人非常希望大荣能静下心来,把这些年对网络系统的观察和理解,写下来。我荣弟的视野,看问题的角度有许多赞的地方。是我们这些工程师出身的人所不具备的。

    大荣,一定要把学识写下来。流传下来。

  5. ASR1k 于 2010-03-06 9:50 下午

    说说我这些年来的观察吧, 刚好最近跟几个仪表商都有些交往.

    对于厂商而言, 需要的是测试仪表产生足够大的流量, 并能够完成足够多的控制平面测试. 特别是消息定制方面的需求会非常高. 例如一个DPI的功能, 可能需要定制一些特定的header/body, 就拿http来说. webdav caldav这些新的method, 很多厂商是不支持的, 倒是一些开源软件做的不错. 以前信令网的时候, 像inet 这一类的仪表定制消息就做的很好, 到了IP网络上, 各个厂商都有一些缺点.

    事实上很多时候厂商都会在自己的设备上改动一些code来完成测试, 代价很高. 因此厂商和设备商的配合显得十分重要, 这一点上感觉ixia做的非常好, 经常有些新项目的需求, 给ixia提出来后, 它们基本上都能很好的提出解决方案, 例如EIGRP或者SCCP一类的私有协议支持.

    另外厂商都希望仪表商能够提供一些api, 例如tcl的api来协助厂商完成自动化测试. 但是逆向思维一下, 为什么厂商不能给仪表上提供一些api, 让仪表商来操纵厂商设备的NP, 这样会好很多, 因为不会出现被测物性能高于仪表的情况.

    说完厂商再来说说运营商测试需要的东西, 运营商很多时候需要的是流量仿真来对网络进行验收. 因此客户行为模拟以及骨干网流量仿真显得非常重要. 另外还有一些全网的安全性检测的需求…breakpoint这个公司的东西做的挺好的. 能够很容易的产生大量的traffic. 并且对于0day攻击, ddos攻击仿真模拟比较好….

    最后说说各个测试仪的情况吧

    ixia总体上来说是很不错的, ixNetwork和Ixload用起来也蛮方便的, 但是2-3层测试和4-7层测试的整合做的不够. 另外收购了安捷伦的router测试仪和一个无线应用的厂商(3G/4G之类的..)后, 测试手段将会比以前更丰富.

    司博伦, 感觉最近几年做的不怎么样. 07年前还挺火的, 现在也就一般, avalanche的功能的确挺简单的.

    breakpoint, 新公司, 容量大, 流量仿真做的蛮好的. 基于flash的客户端, 这个想法不错. 但是可扩展性太差, 特别是协议的定制方面, 但是有一个做法很不错, 他们是把NP挂在FPGA后面的, 这样多种应用的流量混合注入到一个接口会比较方便.

    其它的公司, 安捷伦的N2x, 这是一个非常好的系统, 不过已经被ixia收购了, 也就不做讨论了

  6. bigrong 于 2010-03-07 7:41 下午

    抱歉,这篇文章真的应该写得短些,不要把以前的blog粘进来。
    我想理解我意思是理客、ABC。
    其实我想做的东西不是测试仪表,顶多是有个接口可以自动配置一下已有的仪表,调用一下就ok了。
    关键的关键还是模拟验证配置。

  7. ASR1k 于 2010-03-08 10:51 上午

    这东西啊, 其实我们也研究过的, 不光是研究, 还强制要求Ixia给我们提供过lib库的, 基于tcl的lib库.

  8. bigrong 于 2010-03-08 6:00 下午

    楼上还是理解有误。
    我说要做的东西首先是验证网络设备配置是否有误,而且是一堆网络设备配置是否有误,一堆网络设备为新业务和应用部署的时候是否配置有误。ixia等这些仪表在整个系统中就是一个配角,可有可无的。

  9. OLDSTONE 于 2010-05-28 7:27 下午

    兄弟 你的想法很好 可实现起来不容易 因为你要玩的是模拟真实环境下的所谓设备配置参数是否合理有效 然后通过压力测试或者其他触发测试来确认是否OK 你想过么 首先在所有网络环境上 设备是单点的 对网络的反应是在单体的基础上随机的 而你要做的是用一套软件在一套硬件平台上模拟整个概念 那单体的反应就会按照你设定的软件随机反应率来实现 这和现实情况就完全不同了 对现实的借鉴意义也不够大 因为原来要统计的可触发问题或者其他要收集参数已经变成你在软件中设定的各自参数概率了 不知道我说的意思和你的想法是否锲合 如果有误 我们再探讨