【SDNLAB独家译稿】OpenFlow性能测试目前依然处于起步阶段，虽然有少数的开源工具用于测试OpenFlow性能，但是比较OpenFlow产品的性能还没有一个标准。思博伦测试仪提出了对这些SDN产品的一个测试标准，作者对思博伦OpenFlow性能测试白皮书进行整理翻译，接本系列上一篇《思博伦OpenFlow性能测试白皮书上篇》，本文翻译余下的5.2-6小节。

5.2 Flow-Mod性能

Flow-mod测试从控制器发送一个flow-mod消息去添加、删除或修改一个交换机的OpenFlow表规则到该交换机开始使用流规则去转发包之间的延迟。换句话说，这将帮助您得到一个交换机的OpenFlow查找表被更新的速度。如果安装单个流规则需要100毫秒，flow-mod性能将是每秒安装10个flow-mod。

以太网交换机的flow-mod性能的范围可以从每秒不到10个到每秒数百甚至数千个flow-mod。

开发一种flow-mod测试方法的几点考虑因素包括：

如何衡量仿真控制器发送FLOW_MOD消息到交换机在转发表中安装此消息的时间呢？
如前面提到的，OpenFlow barrier request/reply消息旨在验证交换机已经处理了OpenFlow消息。然而，有研究表明这可能不足以提供“流规则被安装在ASIC中“细粒度的时间测量。一个更好的方法如下：

• 删除所有表中的所有流。
• 创建一个最低优先级的默认流去丢弃所有的数据包，以致没有包可以被转发。
• 首先发送匹配被测流量的数据包。
• 发送一组FLOW_MOD消息来添加流，同步发送FLOW_MOD消息和输出口成功接收第一个包的时间戳。
• 计算发送第一个FLOW_MOD与接收最后FLOW_MOD中的第一个包之间的时间，除以累加的流数目来计算安装FLOW_MOD的平均时间。
• 可以在这n个表（除了最后一个包含“Goto-Table”指令的表）中重复这些测试。这将确保最后一个表填入流之后才进行数据包转发。

在停止验证FLOW_MOD是否已安装之前，应该发送多少FLOW_MOD？

测试的时候可以尽可能快的添加流直到返回TABLE_FULL错误，或者一次性安装10，20，100或一些其它数目的流。

安装一个流所花费的时间会随着已安装流的总数逐渐增加吗？
比如，安装第2000个流比安装第20个流花费更长的时间？如果您的应用程序使用大表，这会对您的网络产生不利影响，研究表明，对于大型TCAMs，添加流将TCAM内存填满需要更长的时间。在这种情况下，需要测试流表规模的一个范围（例如，10，50，100，1000，2000，直到全表）。

安装流与修改或删除流呈现不同的性能？
研究表明修改流比添加一个新流花费时间更长，所以添加、修改和删除流都应该进行性能测试。

安装带有通配符的一个流比精确匹配一个完整的12元组的流花费时间更长？
如果是这样的话，你应该考虑精确匹配和通配符域两方面的测试，采用不同表规模，并分别添加、修改和删除流。

5.3 Packet In/Out性能

对于报文中一个可用的OpenFlow动作，其匹配一定的规则，封装后转发给控制器（称为Packet-In消息）。同样地，一个OpenFlow控制器封装一个数据包并通过网络转发到交换机（称为Packet-Out消息）。因为这个特点对于许多应用程序，包括拓扑发现、MAC的学习和强制网络门户都是非常有用的，封装的数据包如何在交换机和控制器之间快速传送是很重要的。

对于OpenFlow的Packet-In和Packet-Out分组的性能瓶颈趋于交换机内部，ASIC和本地交换机CPU之间，或者是本地交换机CPU的处理能力。而交换机的性能差别很大，通常看不到超过100个Packet-In数据包/秒的交换机。

开发一种Packet In/Out测试方法的考虑因素包括：

Packet-Out消息中规则的类型会影响数据包发送的延时吗？
一定要测试packet-out消息里不同的flow-mod消息。

确定发送数据包的速度。
假如交换机每秒只能处理10个Packet Out消息，你每秒发送了1000个数据包，你可能会得到一个灾难性的失败。发送一个数据包，确认它的延迟（即发现断点），并随着时间的推移逐渐增加速度，直到到达实际断点。

假如数据包的大小影响延迟，那么查出来。
它很有可能受到这样的影响。我们可以尝试通过逐步增加RFC-2544帧大小（64，128，256，512，1024，1280，1518，等等）。

5.4 Table-Miss流条目性能

“table-miss”流条目是OpenFlow 1.3.0标准的一个新特点。它提供了另一种方法来处理无法匹配的流，这些流在以前的版本中都是被自动丢弃的。table-miss流条目提供一个匹配优先级为0的通配符，并允许以下操作：discard，goto_table，并输出给控制器。输出给控制器类似于packet-in操作。对于table-miss流条目，有两个基本的性能测试。

对比两种情况下drop的性能：一种是流表查找失败时的drop，也就是table-miss的情况，另一种是为每个流配置一个默认的drop action来实现丢弃行为。——当所有表都是空的，所有流默认丢弃。这个测试将确定使用table-miss通配符条目丢弃动作的处理开销。监控交换机indiscard计数与时间是用于测量table-miss条目性能的一种方式。

Table-miss条目还可通过控制器的输出动作来测试，判断转发到控制器的可持续的packet-in数据包的最大速率。有两种基本测试来执行这个动作。

所有流量到达table-miss条目的最大吞吐量（出口拥塞性能）。这个测试将衡量一个OpenFlow交换机指引很多流从多端口输入到单端口的能力。pps输入速率下降，可以通过计算全部数据端口和控制端口的流量差来评估。这将评估在一个具有实时通信量的现有网络且只有table-miss条目可以处理包情况下的交换机的能力。

匹配和不匹配流量的吞吐量性能。这个测试将评估交换机处理除可匹配流条目之外的table-miss流的能力，并确定不匹配流是否及如何影响可匹配流的性能。丢包可以通过所有OpenFlow端口和控制器输出端口进行检测。

5.5流量统计测试

在OpenFlow表中的统计字段包括包的数量，已匹配每个流的字节数以及最后一个报文已匹配流的时间。时间计算有助于除去不活跃的流。

开发一种流统计测试方法的注意事项包括：

• 请记住，流包括表中每个条目的数据包/字节计数。
• 测试高速率查询流计数是否影响交换机上的任何其他操作。

5.6 OpenFlow定时器测试

每个流都有硬和空闲超时。OpenFlow计时器测试的目的是确定这些超时是否准确。例如：

• 交换机删除流，时间是否正确，是否有延时？换句话说，它是否正确执行了程序？
• 测试结果的精度是否受流总数影响？
• 测试结果的精度是否受同时超时的流数目影响？

5.7 管道处理性能

管道处理性能主要是测试OpenFlow交换机直接处理包的能力，就是采取一种行动前，进行多个表的多个条件的匹配。这是OpenFlow协议的一个重要的改进，1.1版本允许OpenFlow交换机更像当下的交换机一样具有包含了多种类型记录的多个表。比如MAC和IPv4地址。正交查找提供了交换机处理数据包的速度以及在可能匹配和动作集的无限阵列中增加的延迟时间的重要基准。

管道处理应包括先前讨论的评估Flow-Mod性能方法。具体来说，管道性能的最好测量应从流量运行开始，交换机初步设定为丢弃所有的数据包，并增加流直到最后的流表被填充并且流量在预定的目的地被接收。

管道性能测试的关键的考虑因素有：

• 现实的数据包匹配和修改方案。例如dst_mac, vlan_id, dst_ip的匹配和dec_ttl的修改。
• 对每个测试的交换机进行相同的管道处理，将测试结果进行比较。
• 预定每个测试使用的流表数。
• 执行简单的管道和复杂的管道测试，以对一个交换机的能力进行全面评估。例如，一个简单的测试可以跨越两个表进行两个匹配项和一个数据包的修改，而一个复杂的测试将跨越十多个表执行五个匹配项和两个分组的修改。

6 开始OpenFlow的性能测试

开始OpenFlow的性能测试需要知道OpenFlow产品执行所需的性能指标，以及与其他产品性能对比情况，这些对SDN建设者和用户来说都是重要的。Tallac网络和思博伦通信制定了OpenFlow性能测试的具体方法，他们也乐于分享。

Tallac网络提供创新的技术、咨询服务和产品，以简化实施软件定义网络（SDN）解决方案。想要获取更多信息可以查看www.tallac.com。

思博伦通信为在通信行业内工作的工程师开发了创新的测试解决方案，能够让他们评估在全球范围内部署的最新技术、基础设施和应用性能。思博伦也为服务技术人员及领域测试工程师提供了一些工具，以提高网络质量，更加高效地排除现场网络故障。欲了解更多信息，请访问www.spirent.com。

译自：http://www.spirent.cn/White-Papers/Broadband/PAB/OpenFlow_Performance_Testing_WhitePaper