网络发展遭遇瓶颈期，如何推动SDN/NFV解决困局？

SDN/NFV技术优势与测试挑战

随着网络发展遇到瓶颈创新变得越发困难，这时SDN以一种控制和转发分离的可编程形式出现在大家视野中，它让网络的配置更加灵活，让编程人员能自由的决定网络的转发形态。

NFV从14年开始浮出水面，现在也越发火热，它主要是接入了云计算技术，在虚拟化的形式上将很多原先要依赖专有硬件的东西实现了软件化，一定程度上打破了专有硬件垄断趋势。这种基于虚拟化的技术一方面充分利用了所有通用服务器硬件资源，另一方面获得很好的水平扩展能力。

我们所理解的SDN加NFV将来的终极形式就是一种智能网络，改变了原先网络的封闭和配置复杂的情况，用户可以根据实际需求用通俗易懂的方式完成网络的配置，也能够轻松的验证网络配置是否符合要求。

SDN加NFV的引入不光带来了优势，同时也带来了复杂性。以SDN来说控制面和数据面已被分离，一旦网络出现问题，需要分别对他们进行调试，包括接口协议一致性和设备性能都需要测试。NFV由于是基于虚拟化技术，所以整体平台组件众多，接口庞杂，配置项多，调试也变的复杂。

SDN加NFV的方案可能会涉及到软硬联调，端到端的业务中断难以推断错误位置。

SDN/NFV测试挑战主要是在测试范围、测试复杂度、测试频率三个方面。

测试范围方面如果传统的硬件网络采用的是专一的厂商，测试起来可以很方便，而SDN/NFV打破了专有硬件的垄断，在多厂商、多设备、多功能模块的情况下测试范围就变得非常广了，除了要调试硬件还需要调试软件。

随着硬件越来越开放，接口越来越多 ，不同厂商不同功能模块进行集成的时候，测试复杂度比单一网络形态或单一厂商的产品解决方案要高很多。一方面基于云计算的NFV解决方案，要更清晰的定义测试出来的结果能否满足实际的用户需求。另一方面由于NFV是软硬结合，更多的服务是以VNF的形式出现，也就是说基本单位是一个镜像，这个镜像涉及到整个平台的CPU和内存以及其他硬件的使用情况，在满足服务质量的同时，也要对硬件资源的使用情况进行更紧密的结合分析，以确定服务是否能够更优化。

软件领域的持续集成和持续部署是很必要的方式，在成熟的软件领域每个版本或功能的变化都要去做测试，频繁的补丁更新带来的必然是测试频率的加快。

我们在SDN/NFV测试中的探索

这里简要的梳理下我们在SDN和NFV领域测试中的探索。

我们从2013年开始举办SDN/NFV测试活动，主要范围在协议一致性测试、互通性测试。

2014年联合ONF举办国际性测试活动，共20余家厂商参与，交换机和控制器之间通过GRE隧道进行跨洋测试。

2015推出OF1.3协议一致性测试；在ONF测试工作组参与控制器性能测试规范的编写，发布SDN控制器性能测试白皮书。

2016年推出SDN控制器性能测试工具，在ONF测试工作组参与交换机性能测试规范的编写，并推出SDN交换机性能测试。

2017年积极参与NFV测试工作，成为OPNFV Pharos Lab，参与OVP Beta测试，并推出第三方OVP测试。

从2013年起我们累计组织测试活动5次，厂商参与达60余次，累计测试设备共100余次，累计测试解决方案16个。纵观整个测试活动主要有功能测试、性能测试、互通测试这三项测试。功能测试包含OpenFlow协议测试，SDN控制器集群功能、VNF功能测试。性能测试包含SDN控制器、交换机、NFVI平台网络二三层转发以及VNF测试。互通测试包括SDN南向接口互操作性测试、北向接口兼容性测试、东西向接口兼容性测试、NFVI和VIM与VNF及MANO的互通测试。

单从总结上不能看出什么问题，因此我们也梳理了一下这5次测试中所暴露的问题。首先前期由于大家对OpenFlow协议实现的形式不同，导致沟通上出现或多或少的问题。近些年我们也积极组织对南向接口方面的测试，不过南向接口其实测试起来蛮困难的，因为除开OpenFlow有一个很标准的协议之外，其他的实现方式非常不同，导致这方面的互通测试难度非常大。

最后总结两个趋势。第一NFV的测试比重会逐渐增大，SDN则会由于各个厂商对OpenFlow协议的实现趋于成熟，而在测试活动中的积极程度有所下降。第二因为测试内容由SDN转向NFV互通测试成功率会逐步提高。

OpenFlow1.3的一致性测试包括一个控制通道的连接和四个数据通道的连接，主要用来测试OpenFlow协议一致性，从15年正式推出到17年累计64款设备通过OF1.3协议一致性认证测试。通过29个测试组，342个测试用例终结OpenFlow体现的协议内容，并且全部的测试协议一致性。

SDN交换机性能测试在提交到ONF的测试工作组之后，由于ONF的合并问题，导致该项目暂时搁浅。但是我们在推出该草案后也积极推出了SDN交换机性能测试的工具，在关键的发包的功能模块上做了一些优化，由于工具上层使用的是Python，因此底层是用的C语言进行的重写，总共包括了7个测试组和30个测试用例。

SDN控制器性能测试可能针对的是的单个控制器也可能是控制器集群。这套工具是我们完全基于C语言编写的，做了一些多核多线程的优化，对CPU亲和性进行了调整，使用了内存池和线程池的技术，通过环形缓冲区解决了TCP粘包的问题。

以前在测试设备的时候，不管是用专用的硬件测试仪还是在通用服务器上开发的测试工具都能很方便的测试。但是NFV组网相对复杂，既有底层的undelay网络又有虚拟机之间的overlay网络。这种情况下测试拓扑其实是可以跟着演进，当然也可以使用传统的方法将VNF当做黑盒来测试，只需要将外部的测试仪接到服务器的特定接口上就行了。VNF之间的网络服务更多的可能是VNF串起来的服务功能链，这时要想进行内部的网络测试就需要用到虚拟测试仪，这个虚拟测试仪也可以当做是平台上的VNF，用来在虚拟机之间的Overlay网络中进行发包以及打流测试。

OPNFV OVP 与ONF CORD测试介绍

虽然目前NFV大多是基于虚拟化的平台，但是还是存在接口不同，集成难度大的问题。通过OPNFV OVP测试能够帮助建立基于OPNFV基础设施的市场，降低NFV最终用户的使用风险，通过验证硬件和软件平台接口以及各个组件来降低企业测试的成本。

上图是CORD的原型设计和架构，主要包含RCORE、ECORD、MCORD。这里对CORD的原理就不多做介绍，主要还是谈下CORD官方推出的测试环境。

该测试环境中有一个Cord in a-Box的方式，这是一个完整的解决方案或者说是Cord环境。不过Cord在国内的部署难度很大，它使用的一些镜像在国内的访问速度非常的慢，在搭建Cord in a-Box中会遇到很多问题。后续Cord又提出了CATS（Cord自动化测试系统），包含了一个以容器的方式运行的测试套件Cord Tester。Cord in a-Box只是单一物理机模拟的形式，主要由测试人员或测试人员解决整体环境部署过程中遇到的问题，也可以通过物理的方式针对开源的服务器硬件或交换机硬件做一些更具体的配置工作。

云网融合时代下的测试即服务

从2013年开始我们已经做了很多积极的探索，后续也不会停下脚步，当然也不会一种沿用传统的方式来做测试工作，而是要在云时代的环境下推出更适合时代发展的测试服务。我们希望在后续的云网融合时代推出一个更为敏捷的平台，在该平台上能够更灵活的选择测试内容和范围。