专家与用户的区别——写在前面的话
SDN——一帮骨灰级的专业网管，不愿被网络产品厂商技术绑架，自行研究出的用软件控制网络流量转发技术，目前正得到多方面的关注与追捧。此情此景，不由让我想起十多年前刚工作不久，有幸进入一家国内知名杀毒软件公司做一个小小的技术支持人员。那时CIH病毒泛滥，每到4.26被CIH病毒破坏的硬盘成堆的摆放在我们面前。为了缓解这种情况，我们和“王老师”的公司推出了两种相同又不同的解决办法：“王老师”公司是告之用户如何用他们的软盘启动电脑后通过类似DEBUG的工具编辑硬盘分区表，并进行改写，从而将被病毒破坏的引导头信息恢复。我们是告诉用户软盘启动后，如何在菜单选项中选择自动修复硬盘。我当时的领导形象的将这两种解决方案称为一种是将用户培养成为数据修复专家，一种是为用户提供解决方案。事实证明，最终我们成功了。而现在的SDN给我的感觉和以前一样——我们应该用什么方法帮用户修理“硬盘”?
大二层的兼容与异构——对SDN观点的转变
由于初期对SDN技术没有深入了解，使我产生一种SDN是一帮技术高富帅玩的东西，与我等屌丝无关的观点。当我对SDN进行一番挖苦之后，思博伦SDN测试技术资深专家罗竑旻的一翻话，使我对SDN的观点有了根本性的改变。“SDN并非不堪重用，不但在国外大型数据中心中已经有很多成功应用，即便在国内电信行业中，也正在试验利用SDN解决传输网数据通讯问题。” 传输网也在试用SDN?这段话让我开始对SDN技术进行重新审视。不由得回想起多年以前参加某企业网络系统验收时的一个情景：该企业网络系统规模庞大，部门间采用三层OSPF交换设备进行连接，为保障数据传输的可靠性，采用的是双机热备的形式部署。测试网络切换时间时发现，由于三层路由需要重新汇聚，即便是在简单测式环境中，统计单位也是以分钟来计算，每次倒换的时长基本在十几分钟以上。也就是说一但出现故障就会有长时间网络瘫痪的情况出现。当问及为什么采用OSPF时，承办方给我看了一张企业内部有着密密麻麻网络设备节点的网络拓扑，并问了我一个问题，不用OSPF我怎么把这么多网络设备连起来?!一句话问的我哑口无言。再回头看现如今的传输网，同样的问题再次出现，三层网络路由倒换时间漫长，大二层技术各厂商自行其事，而这一张大网又绝对不可能由一个厂商的产品进行部署，用什么办法才能将这张网高效率的连起来?看来不是通信企业主动选择SDN，而是SDN所具备的先天技术优势逼迫厂商不得不进行选择。
理想与现实的差距——实际测试中的问题
理想是美好的，但现实是骨感的。这句话用在现在的SDN上可能会非常的合适。为了考查SDN交换机的实用性，《网络世界》评测实验室也试着组织了一次以验证SDN交换机实用性为目的的架顶式交换机SDN功能公开比较测试活动。
活动初期，各交换机厂商对此有着积极的响应。得益于Avaya、博科、H3C和锐捷这几家厂商在前期的交换机SDN功能调查中的及时回复，使我们初步了解了目前SDN交换产品在生产厂商中的技术发展情况，使得SDN交换产品测试的初步测试方案可以顺利制定。在随后《网络世界》组织的SDN交换产品测试方法研讨会上，Avaya、博科、思科、瞻博等厂商也积极参与了测试方法的讨论。然而实际测试时的情况刚好相反，仅有一家新兴的SDN交换设备厂商xNet(网锐)公司提供产品进行测试。
为什么会出现这种情况?从与各厂商研讨测试方案的过程中，可见一些端倪：与ONF组织的PlugFest测试不同，既然要进行SDN交换产品实用性测试，除了一些数据中心的组网及用户管理功能外，必然要对SDN交换机的网络转发处理性能进行测试。得益于思博伦通信对本次测试的大力支持，我们可以用思博伦TestCenter测试仪表产生一个很大的测试流量，并且可以构造出一个很大的流量表，来测试SDN控制器对大流量的处理能力。而这个测试项也是在测试方法研讨中，各厂商讨论最集中，顾虑最多的一项。原计划在测试中，采用20个万兆接口，每个接口设置200个IP地址，所有IP地址成网状连接并进行转发。这样设计，预计可以构造出一个1600万条以上的巨大流表。之所以这样设计，是考虑到在目前的现网环境中，一个万兆接口肯定不会只有一个接入IP，单个万兆端口200个接入IP已算是一个相当保守的设计了，而全网状转发这个测试项，对于传统二、三层交换设备来讲，也不是一件困难的事情。然而参与研讨的厂商纷纷遗憾的说，目前万兆TOR交换设备在SDN功能上支持不了这么大的表项。目前比较理想状态下，万兆TOR的交换机表项也就在4000条左右(这够干什么的??)。于是改为在产品所支持最大表项下进行流量转发性能测试。即便如此，那些表示将要参与的厂商也都再未出现，还好有xNet的积极参与，才使本次测试活动可以顺利进行了下去。
功能测试——SDN不负所望
虽然参与厂商仅剩下了一家，但正是因为xNet的大力协助，使我们的测试活动还是可以继续进行了下去。在功能测试中，我们对在数据中心中呼声最高的环网连接、数据流路径切换和用户权限管理这三项功能进行了测试。
环网连接
环网连接，这可以算得上是大二层云计算网络的标志性功能了。环网连接无风暴，根据路径智能选路，这些全新的网络应用功能在SDN交换网络中是否可以实现，下面，我们就实际的验证了一下。
在这项测试中，我们采用了两台48口千兆(具备4个万兆上联接口)X1-48T和一台48口万兆(4个40G上联接口)的X10-48S型号的xNet 白盒SDN交换机进行了组网测试。测试中，我们将三台交换机的6个万兆接口两两互连，通过第三方Floodlight控制器组成一环形网络。(网络拓扑及实际测试环境参见下图)
Floodlight自动生成网络拓扑
环网实际测试环境
在随后利用两台PC接入环网进行测试发现，三台SDN交换机通过Floodlight控制器组成的环网中，未出现广播风暴现象，两台PC可以互相Ping通，数据传输正常。由此可知，在现阶段SDN交换设备在设备组网功能方面，还是可以满足大二层组网的应用需求的。#p#
路径切换
数据流传输的路径切换时间，关系到网络的稳定性及可靠性，回想起当年三层网络动辄十数分种的心跳切换时间，现在SDN[注]的路径切换时长又是多少呢?为此我们对SDN数据流路径切换时间又进行了一次测试。测试还是在上面的环型组网环境中进行，两台PC分别接入A、B两台交换机，在控制器上设置并检测数据传输路径是由A—B双向进行传输后，A、B上接入的两台PC互Ping。断开A交换机与B交换机的网络连接(拔掉光纤)。查看网络是否可以自动切换到A—C—B的路径继续进行数据传输，并从丢包数计算路径转换的切换时间。
切换时间Ping包截图
从上图的切换时间Ping包截图中，我们可以发现，当SDN环网A-B的链接断掉之后，环网链路自动转换到A-C-B链接继续进行传输，Ping包测试结果表示并没有Ping包丢失，只是切换时Ping包延时增高到了52ms(上图中红框标出)。从十几分种到几十毫秒，这样的链路切换时间已经有了跨时代的进步。
用户管理
在当前的网络应用中，还需要对接入用户进行分类管理，为此我们也对SDN交换机用户接入管理能力进行了测试。测试还是采用环网的测试环境，在控制器上设置两台接入PC一台可以从接入的DHCP Server上获得IP地址，另一台则禁止IP地址的自动获取。在实际测试中，无论是转换接入端口还是换交换机，这两台PC的接入权限并没有发生变化。由此可知，在目前SDN交换设备上，通过控制器可以有效的对网络设备的接入权限进行管理。
从以上三种SDN功能性测试上来看，xNet的SDN交换设备与Floolight控制器配合确实可以解决数据中心组网搭建、连接链路切换以及用户接入管理控制功能。而SDN交换机的实际应用性能如何呢?我们在随后的性能测试中有了更深入的了解。
性能测试——控制器 控制器!
在接下来的测试中，我们对SDN[注]交换机数据转发性能进行了测试。为此我们通过思博伦Spirent TestCenter测试仪表生成了一个200G的测试流量，通过测试仪表上的20个万兆接口与xNet白盒SDN交换机X10-48S相连，并对数据包转发性能进行测试。
Spirent TestCenter上20个万兆光纤接口
X10-48S上20个万兆光纤接口
在测试的流量结构上设置上，我们听从了xNet网络工程师的建议，减少了每端口数据流的条数，采用一对一的方式进行连接，并在每个端口上设置了50个IP地址，每个端口的源IP分别向目的端口的50个目的IP发起连接请求，共建立1000条IP连接并传输数据。#p#
Spirent TestCenter目前已经支持Openflow控制器仿真，但在本次连接性测试中，我们为了同时了解第三方控制器在真实流量转发时的处理能力而未曾采用。在通过Spirent TestCenter测试仪表测试时，我们发现，1000条连接建立顺利，并可以顺利产生测试流量。但接下来的RFC 2544标准测试中，却发生了意外。在2544测试中，我们采用从10%开始，以二分法的方式，进行网络层吞吐量性能测试时发现，测试时，始终有大量的数据包丢包产生，以至于最后吞吐量性能接近“清零”。在问题排查中我们发现，测试仪表发流时，第三方的Floodlight SDN控制器不能及时给予处理，从而导致流表无法全部成功建立，更严重的是，反复几次流表重建后，还会引发SDN控制器“死机”现象的出现。从而使测试仪表所发数据流无法正常进行转发。原本xNet交换机通过其自主研发的flexSDN技术可以将SDN流表“缓存”在其交换机上，从而有效缓解此类问题的出现。然而在进行2544测试的同时，为了对控制器流表处理能力进行测试，每次发流前，我们都会设置测试仪表将端口进行重置，导致xNet交换机上流表清空。因此，当控制器处理能力不足，乃至于死机时，测试流量失去流表的引导，从而导致了测试的失败。
为了保证测试不受控制器处理能力的影响，我们又一次减低了连接建立的条数，采用每端口单IP共建20条连接的方式进行测试。这次测试顺利得以通过。(测试结果参见下表)
在网络性能中，我们可以看出除64Byte下xNet SDN[注]交换机吞吐量性能较低外(由于实际应用中，基本不会出现64Byte 100%吞吐量的应用，因此现在很多交换机厂商也开始降低为小字节数据包转发性能)，其产品在网络层吞吐量性能始终保持在99.9%以上。(由于SDN技术转发与控制分离的技术设计，其数据包转发时，包内必需添加相应识别字段，因此吞吐量性能不能达到100%)表明xNet X10-48S型白盒SDN交换机从自身数据包转发性能上来看，是完全没有问题的。220微秒以内的数据包转发时延也可以很好满足当前数据中心网络[注]数据转发的应用需求。
但从第三方控制器的网络流表处理能力来看，今后SDN交换技术的发展必然还将会在一段十分曲折的道路上前行。
未来发展——重筑SDN 1.0
前段时间参加迪普科技的DP xFabric解决方案架构发布会，他们用的一个词“重筑”，给我留下了很深的印象。我曾设想如果迪普的xFabric架构与xNet的flexSDN技术结合，可能将会极大加快SDN向实用性迈进的步伐。三层网络架构需要重筑，目前看来，SDN技术也需要一次重筑。我是从产品测试的角度来考虑这个问题的：
首先，我们要解决SDN数据传输一致性的问题，不要再盲目追求更多更全的SDN新功能。从底层做起，甚至是从链路层做起，统一不同交换机厂商SDN交换数据传输标准。做到各厂商产品在数据传输层面上的互联互通。
在这方面，最好是由测试仪表厂商来进行引导。例如Spirent TestCenter上加入统一的SDN控制功能，在性能测试时，流表统一先由测试仪表进行下发，下发完成后再进行转发性能测试。这在Spirent TestCenter(目前STC已经支持Openflow控制器仿真，本次测试由于要对第三方控制器性能同步进行测试而未曾采用)上并非一件十分困难的事情。当各厂商SDN交换产品在统一测试仪表下可以成功完成数据转发后，其SDN产品的互通性自然也可以达到实用性的要求了。也再也没有组织众多厂商进行协议一致性测试的必要。
其次，要解决SDN控制器连接处理能力的问题，这就需要重新定制一个全新的SDN控制器处理性能测试方案。第一，要了解SDN控制器在实际应用中所必须的流表建立速率，并对SDN控制器处理性能进行测试。具体测试方法可以参照目前应用层网络产品对新建连接性能测试方法来进行。第二，要了解SDN控制器在应用中所需的流表容量，并制定相应标准进行测试。这同样可以参照应用层产品测试对并发连接数的测试要求。通过这两项测试，可以解决SDN控制器处理能力和稳定性方面的问题。
最后是SDN功能性上的要求，这方面，不妨彻底放开，在保障底层网络互联互通的基础上，由网络厂商八仙过海，自行去设计对SDN流量的管理控制功能，那个厂商的管理控制功能做的多，处理性能强，自然就可以占据网络的核心领域，不足的厂商自然会被排挤到网络的边缘，或者接入设备的地位上，从而实现自然的优胜劣汰。
随着功能及性能方面的不断提升，SDN技术自然会得到蓬勃的发展，从而彻底改善目前网络应用现状。希望这一切都可以从“重筑SDN 1.0”重新开始!
