软件定义网络中网络诊断的思考和探索

赵宇粟　张鹏飞　金耀辉

摘要：提出一种轻量级的诊断平面，它利用OpenFlow协议中多流表的功能，将探针包注入网络，探针包经过各个网络设备后会携带相关的转发规则的信息。通过收集携带这些信息的探针包、利用一组类似于程序调试的诊断原语，能够快速地检测数据平面转发的正确性和网络性能问题。认为主动诊断数据平面真实的转发行为会是SDN网络诊断的一个重要方向。

关键词： 网络诊断；软件定义网络；诊断平面

Abstract：We propose a lightweight network debugging plane leveraging multiple flow tables to send probe packets into the network. When traversing network devices， probe packets carry information about forwarding rules. By collecting those probes packets and using debug primitives similar to program debugging， we can determine the correctness and network performance of the data plane forwarding. Debug the forwarding behavior of data plane is an important direction of software-defined network （SDN） network debugging.

Key words：network debugging； SDN； debugging plane

1网络故障和网络诊断

一般来说，网络诊断针对的网络故障，只包括网络的连通性问题，即端到端是否可达，但在广义上还包括了网络的性能问题，比如网络延迟和带宽。虽然网络性能问题更多的是用户之间的竞争所造成的，但是错误的配置以及软硬件的故障也会导致网络性能的急剧下降，而且事实上很多用户会要求网络管理员去解决网络的性能问题[1]，因此网络诊断的对象不仅是网络的连通性问题，而且还应当包括网络的一些性能方面问题。

一直以来，网络诊断都是非常困难的工作。网络管理员每天都要处理各种原因导致的网络故障，比如错误的配置、链路或者器件的失效以及软硬件的故障等等。而目前，仅有很少的工具可用于网络诊断，包括ping、traceroute和SNMP等，这些工具功能简单，能够解决的问题有限，而面对特别是网络性能问题的时候，更是一筹莫展，网络管理员依然需要依靠自己丰富的经验去排查具体的故障原因。

1.1网络故障的普遍性

文献[1]对61名网络管理员做了一份详尽的调查，得到了一些结论。

（1）超过50%的人提到，经常发生的网络故障包括3类：端到端可达性的失效、网络延迟和吞吐问题以及间歇性的连接问题。即既存在连通性方面问题，也存在着网络性能方面问题。

（2）超过40%的人提到，经常性的故障原因在于交换机/路由器的软件故障和硬件失效。

（3）超过80%的人经常使用ping和traceroute，超过60%的人经常使用SNMP。

（4）35%的网络管理员每月收到超过100起网络故障的通告。

（5）解决每一起网络故障的平均时间中，31.6%的人需要半个小时至一个小时，而24.6%的人需要超过一个小时的时间。

由此可见，网络管理员面对的网络故障种类繁多、原因复杂，而且遇到的次数和花费的时间都很巨大，但是可用的工具却十分有限。因此，网络管理员急需更为强大的网络诊断工具。

1.2网络诊断的困难性

结合上文的分析，在传统网络中，网络诊断比较困难的原因是多方面的：

（1）表征网络的各种状态参数分散在各个网络设备上，在传统的网络中，通常需要管理员亲自登陆这样一些设备，才能获得相关的网络状态参数，同时这些状态参数是会经常变化的，这导致了要想准确地捕捉网络相关状态，就要不停地去监测整个网络的情况。

（2）导致网络故障的原因很多，除了人为的配置错误外，各种网络设备都有可能失效或者发生软硬件的故障。

（3）网络规模不断扩大，网络拓扑更加复杂，可能失效的网络设备和链路也不断增多，文献[2]就提到在其观测的数据中心内部（规模没有具体说明，但是可以看到有1.3万条链路，因此规模不算大），每天平均都含有40.8次的链路失效以及5.2次的器件失效。

（4）可用工具的缺乏导致网络故障不容易定位，并且故障原因不容易查明。

1.3 SDN给网络诊断带来的机遇和

挑战

软件定义网络（SDN）将传统网络中分布式的控制平面剥离了出来，放到了逻辑上集中式的控制器中，这使得网络状态可以直接通过对话控制器而获得；而由于其可编程的特性，我们可以轻松地实现对所有网络设备的统一管理，同时还可以根据自身的需求，开发一些新的功能，比如网络诊断。

然而SDN还处于发展的初期，目前也仅仅只有一种广泛应用的实现（OpenFlow[3]），而控制器的性能不足问题以及网络设备的兼容问题导致了还没有真正商用的SDN环境。同时，针对SDN的研究和应用还处于活跃的上升期，暂时还没有成熟的技术去支撑类似传统网络中的各种网络应用，因此也没有很多针对SDN的网络诊断工具。

2 SDN中网络诊断的研究

现状

2.1网络诊断的形式化描述

如图1所示，在应用层的各种网络策略（NP）通过编译器（C）编译成可被网络设备执行的预期网络状态（ENS），而ENS通过网络设备的执行（SE），生成真实的网络状态（ANS），

ANS还受到真实的网络拓扑（T）的制约。则有：

[NP→CENSSETANS]

网络故障的最终体现是ANS有错误，若往前推则有以下3种类型的故障：

（1）SE有错误，即网络设备的软硬件故障。

（2）T有错误，即链路或器件的失效。

（3）ENS有错误，即配置错误。

需要指出的是，一般都可以假定C是正确的，因此NP有错误等价于ENS有错误，即针对应用层的网络诊断等价于针对控制平面的网络诊断。则在SDN环境下，网络诊断的层面可分为两种：针对控制平面的和针对数据平面的。

2.2 控制平面的网络诊断

逻辑上集中式的控制平面给网络管理带来了方便，也增加了故障的可能性：所有的网络应用都有操作转发状态的权利，如果一个网络应用要求某一数据包转发到端口A，而另一应用要求转发到端口B，那么就有可能发生错误。因此有必要对控制平面的所有策略进行评估。

文献[4]-[5]提出了包头字段分析（HSA）的方法，将数据包处理的过程抽象成同协议无关的几何模型，即所有的网络设备都是针对输入数据包的转移函数，网络拓扑也同样抽象成一个转移函数。通过从指定数据源开始，计算端到端的可达性，从而可以发现网络中断的具体位置，为网络诊断提供了帮助。

文献[6]提出了一种高层次的编程语言，提供了针对分类和汇聚网络流量的声明式查询以及描述高层数据包转发策略的功能库，从而提高了网络编程代码的正确性和可重用性，类似的还有文献[7]。文献[8]提出了一种实时检测网络不变量的方法，它在控制器和网络设备之间增加了一层，每当有新的转发流表项要插入到网络设备时，该层都会去检查，看这条新的规则是否违反了某个网络不变量，从而在一定程度上避免了控制平面上多应用之间的矛盾所带来的网络问题。

然而针对控制平面的网络诊断通常假设控制平面的所有要求都能够被数据平面所执行，因此只需要检查控制平面是否存在错误就可以了。显然，这样的假设没有考虑到数据平面由于软硬件故障或是固件故障的存在，而导致的错误的转发行为；同时，网络中器件或是链路的失效也无法被控制平面的静态检测探查到。

2.3 数据平面的网络诊断

文献[9]-[10]利用OpenFlow协议修改每一条流表项，使得途径交换机的每一个数据包都产生一个“明信片”，这个明信片中包含了该数据包所经的交换机ID、出端口号和流表的版本号等信息，这样一些信息能够刻画出数据包在网络传输中途径每一跳的真实情况，反映了数据包的网络中的详细历史，在网络诊断时能够提供更为真实、详细的数据支持。虽然文章提到了使用压缩算法以及在交换机和主机端提供相应的数据压缩支持，但是每一个数据包产生一个明信片的代价依然很高。同时，局限于OpenFlow1.0协议，文章必须修改明信片中的目的多媒体接入控制（MAC）地址来输出相关信息，而如果数据包的目的MAC地址曾被修改过，该方法是无法发现的。

文献[11]提出在SDN/OpenFlow环境下，记录控制信道的所有网络流量和数据平面的所有网络流量，并强调在需要诊断网络时，将这些流量按照原有的顺序重放出来，就能够重现问题。同时，重放流量时，可以选择在一个隔离的试验环境中，这样可以排除生产环境中其他因素的干扰，为网络诊断和问题诊断提供了极大的方便。该方法需要额外的数据存储来储存相关的网络流量，当重放的数据量很大时，存储的开销也会相应提高，同时，仅仅将问题重现出来，并不能够直接找到造成网络故障的原因。

以上的两种方法属于被动监测的方式，通常需要很多额外的资源，比如带宽或者是存储，这样的方式虽然很全面，但是毫无疑问包含了很多无用的信息，这就造成了资源的浪费。因此，还有一些工作着眼于主动式的发送探针包，去针对数据平面进行网络诊断。

文献[1]通过对网络设备中所有规则的爬取，计算出能够触发所有规则的数据包的集合，然后周期性地在网络边缘的测试终端上发送这样一些数据包，去定位网络问题所发生的位置。这样的方式需要假设网络状态在较长的一段时间内是稳定不变的，因为计算数据包集合的时间很长，这对于类似数据中心这样的动态场景显然是不合适的。文章着重在于网络故障的定位，而对于故障原因的挖掘没有提供更有效的帮助。

文献[12]提出了SDN版本的traceroute，该方法不局限在IP层，能够输出数据包在网络中的完整路径。局限于OpenFlow1.0协议，文章采用了染色算法去捕获相应的探针包，这在网络设备支持多流表的情况下是完全不需要的。

3 SDN中的网络诊断平面

我们提出了网络诊断平面，它通过主动的方式，利用OpenFlow1.1+协议中的多流表的功能，实现了探针包的识别和捕获、流表项信息的输出和各种诊断原语，还能够实现：

（1）主动式的探测数据平面的真实转发行为。

（2）诊断网络连通性问题和网络性能问题。

（3）提供程序调试器的原语，包括breakpoint、backtrace、single-step和continue。

主动式网络诊断系统的整个架构如图2所示，以下是主要组成部分及其功能说明。

代理：检查控制器下发的流修改信息，在原始信息的后面添加额外的指令，使用于网络诊断的探针包能够携带途径网络设备的ID、匹配的流表、匹配的流表项等信息。

网络诊断器：根据管理员的诊断需求（测试网络可达性或是网络性能，不同的诊断原语）产生相关的探针包，并解析和分析收到的探针包，给出相应的结果。

监控端口：在网络设备端，专门用来收发探针包。该端口既可以是独占的，也可以是复用其他端口，在独占的情况下，能够更准确地去诊断网络的性能问题。

诊断信道：带外信道，可以复用控制信道。

网络诊断的流程如图3所示。

（1）网络诊断器根据网络管理员的需求，生成相关的探针包，发往指定网络设备的监控端口。

（2）探针包像正常的数据包一样在该网络设备中去匹配流表，转发到相应的出端口后，复制一份数据包，经过多一级流表的处理，再通过监控端口发往网络诊断器。

（3）探针包到达下一个网络设备，重复步骤2。

（5）直到探针包到达主机端被丢弃，或者跳数达到上限（由于回路的原因，或者是诊断的需求，比如只转发三跳、到了某个交换机就不继续转发）。

（6）网络诊断器收集并解析所有的探针包后，给出路径信息以及每一跳所匹配过的流表项信息。

4 结束语

传统网络的诊断工具简单有限，对于网络状态无法及时获取，也没有全网的视角，面对各种可能导致网络问题的错误配置、链路和器件失效以及软硬件故障时，显得无能为力。软件定义网络的诞生，带来了控制平面和数据平面的分离，网络管理员可以通过逻辑上集中式的控制器快速地获取所有的网络状态，得到整个网络的视角；而网络的可编程性使定制的网络诊断成为可能，加速了诊断的效率和准确性。在SDN环境下，针对控制平面和数据平面的网络诊断都有了一定的研究和发展，而主动式的诊断相对被动式有着资源消耗少、针对性强的特点，因此主动地去诊断数据平面真实的转发行为会是SDN网络诊断的一个重要方向。

参考文献

[1] Zeng H， Kazemian P， Varghese G， et al. Automatic test packet generation[C]//Proceedings of the 8th International Conference on Emerging Networking Experiments and Technologies， 2012： 241-252.doi： 10.1109/TNET.2013.2253121

[2] Gill P， Jain N， and Nagappan N. Understanding Network Failures in Data Centers： Measurement， Analysis， and Implications [C]//ACM SIGCOMM Computer Communication Review， 2011， 41（4）： 350-361.doi： 10.1145/2018436.2018477

[3] OpenFlow[EB/OL]// https：//www.opennetworking.org/sdn-resources/openflow

[4] Kazemian P， Varghese G， and McKeown N. Header Space Analysis： Static Checking for Networks[C]//NSDI， 2012： 113-126

[5] Kazemian P， Chan M， Zeng H， et al. Real Time Network Policy Checking Using Header Space Analysis[C]//NSDI， 2013： 99-111

[6] Foster N， Harrison R， Freedman M J， et al. Frenetic： A Network Programming Language[C]//ACM SIGPLAN Notices， 2011， 46（9）： 279-291

[7] Voellmy A， Agarwal A， Hudak P. Nettle： Functional Reactive programming for Openflow Networks[R]. USA： YALE University New Haven CT Dept. of Computer Science， 2010

[8] Khurshid A， Zhou W， Caesar M， et al. Veriflow： Verifying Network-Wide Invariants in Real Time [J]. ACM SIGCOMM Computer Communication Review， 2012， 42（4）： 467-472

[9] Handigol N， Heller B， Jeyakumar V， et al. Where is the Debugger for My Software-Defined Network？[C]//Proceedings of the First Workshop on Hot Topics in Software Defined Networks， 2012： 55-60

[10] Handigol N， Heller B， Jeyakumar V， et al. I know What Your Packet Did Last Hop： Using Packet Histories to Troubleshoot Networks[C]//Proc. USENIX NSDI， 2014

[11] Wundsam A， Levin D， Seetharaman S， et al. OFRewind： Enabling Record and Replay Troubleshooting for Networks[C]//USENIX Annual Technical Conference， 2011

[12] Agarwal K， Rozner E， Dixon C， et al. SDN Traceroute： Tracing SDN Forwarding Without Changing Network Behavior[C]//Proceedings of the Third Workshop on Hot Topics in Software Defined Networking， 2014： 145-150