经典测试实践分享——以太网交换机性能测试需要关注的细节

在以太网交换机测试中，常见的性能测试主要包括二层转发性能测试、三层转发性能测试、buffer性能测试。

二、三层转发性能测试，主要使用的测试套件是RFC 2544、RFC 2889。其中RFC2544，是关于一些比较基础的转发测试用例，例如吞吐量，时延，丢包率等。而RFC2889，除了和RFC2544相同的转发部分测试外，还增加了一些主要针对以太网交换的测试用例，例如MAC地址学习速率、广播转发延时、拥塞控制等。在二层和三层转发测试方面（主要是指吞吐量、延时测试），两者是基本相同的。buffer性能测试，主要是针对存储转发设备的buffer容量的测试。因为不同产品的buffer结构各不相同，所以没有像RFC那样标准的测试用例和衡量标准。需要根据不同产品的特征、不同的应用场景和流量模型，进行测试用例设计。

一、二三层转发性能测试

各厂商的测试仪器都提供了多种测试套件来进行二三层转发性能测试。具体的测试方法都有详细说明，这里就不赘述了。本节将重点介绍这些测试套件背后的一些细节问题。

1.同步模式和异步模式

使用TestCenter测试时，有一个设置是选择测试使用同步模式还是异步模式。在端口发送测试流量时，测试仪对发包顺序存在一个调度，保证在任意时刻，每一个端口都只唯一收到从一个端口发来的报文，避免在多对多测试时，出现某个时刻，多个端口同时向一个端口发包，产生拥塞的情况。

以8个端口的Full Mesh测试为例，表1表示在某一个时间点（行），每个端口（列）发包的目的端口。

	t1	t2	t3	t4	t5	t6	t7	t8	t9
P1	P2	P3	P4	P5	P6	P7	P8	P1	P2
P2	P3	P4	P5	P6	P7	P8	P1	P2	P3
P3	P4	P5	P6	P7	P8	P1	P2	P3	P4
P4	P5	P6	P7	P8	P1	P2	P3	P4	P5
P5	P6	P7	P8	P1	P2	P3	P4	P5	P6
P6	P7	P8	P1	P2	P3	P4	P5	P6	P7
P7	P8	P1	P2	P3	P4	P5	P6	P7	P8
P8	P1	P2	P3	P4	P5	P6	P7	P8	P1

表1 测试仪器发包顺序

在同步模式中，测试仪器严格按照表1中的设置来进行发包。这就保证了任意一个时间点，任意端口都不会同时收到两个或两个以上端口发送的报文。这就避免了测试时出现拥塞。

异步模式，是指测试仪器端口并不是严格在同一时间点发包，而是按照一个固定的时间差（TestCenter上默认为64us，可配置）来发送。这样就可能存在某个时刻多个端口会同时向同一个端口发包的情况，产生了拥塞。

同步模式下的性能测试，因为测试仪器保证了不会产生拥塞，所以主要关注的是设备的带宽，和设备的buffer关系不大；而在异步模式下，测试会产生拥塞，所以需要设备有相对较大的buffer缓存能力，来保证达到线速转发。

2. store-forward与cut-through以及相应的时延

交换机按照处理帧的不同方式分为存储转发（store-forward）和直通式（cut-through）。在时延测试时会体现出区别。

图1 单个报文在交换机中的转发时刻

如图1所示，报文在进入交换机到从交换机转发主要经历几个时刻：报文的第一个字节进入交换机的时刻为T1，报文全部进入交换机的时刻T2，报文从交换机端口转发时的时刻T3，报文全部从交换机端口转发出去的时刻T4。这几个时刻之间的差值分别定义为Δ1、Δ2、Δ3。显然，Δ1和Δ3会受到报文字节长度的影响。

对于store-forward转发，交换机在转发之前必须接收整个报文，并且进行错误校验，如果没有错误再发往目的地址。所以报文需要全部进入buffer缓存后，再转发。也就是说，T3一定是在T2之后，报文的整个转发流程中，有一部分是buffer内的调度时间Δ2。

对于cut-through转发，交换机只要检查到报文头中所包含的目的地址就立即进行转发，无需等待报文全部被接收，也不进行错误校验。也就不存在buffer内的调度时间Δ2

根据如上的转发特征，定义了以下几种转发时延类型：

• LILO（Last In/Last Out）

指帧的最后一个bit进入设备端口，到帧的最后一个bit从设备端口转发之间的时间间隔，即报文的转发时延为T4-T2=Δ2+Δ3。

• LIFO（Last In/First Out）

是指帧的最后一个bit进入设备端口，到帧的第一个bit从设备端口转发之间的时间间隔。即T3-T2=Δ2。这段时间是交换机完全接收到报文后，进行表项查找，buffer调度，再转发所需要的时间。store-forward方式使用这个时间来衡量时延。可以看出，这种时延计算方式，不受转发报文的大小影响。

• FIFO（First In/First Out）

指帧的第一个bit进入设备端口，到帧的第一个bit从设备端口转发之间的时间间隔。即T3-T1=Δ1+Δ2 。在cut-through方式下，只要报文头到达交换机即开始转发，报文不被缓存，也就没有Δ2的时间。所以cut-through选用这种时延计算方式。在cut-through方式下，这种方式也不受转发报文大小的影响。

3 混合帧测试/IMIX测试

一般在进行转发性能测试时，会测试不同长度报文的转发。

在测试strore-forward方式的设备时，尤其是异步模式下，随着报文长度的增加，转发测试时产生的拥塞对于buffer的要求会更高（因为每个报文占用的buffer增多，buffer调度的时间增长）。所以经常发现，随着报文长度的增加，延时测试的结果会越来越大。对于某些设备，当测试5k以上的jumbo帧时，吞吐量甚至有可能达不到100%。更极端的一种情况，是混合包长的转发性能测试，也就是IMIX测试，即测试流量是由不同大小的报文按照一定的比例混合组成。通过测试发现，按照混合帧构造流量的测试结果，甚至会比以jumbo帧（例如一个报文9k）构造流量的测试结果更差。这是为什么呢？

因为设备在转发不同大小报文时，所使用的时间差别很大。以1518和64字节为例，转发一个1518字节的报文约等于24个64字节报文的转发时间。当交换机的一个端口在转发一个大字节报文的过程中，可能会有多个不同字节大小的报文也要从这个端口出去，这就产生了严重的拥塞，导致丢包。所以在混合帧的情况下，对Buffer的要求会更高。

4 二三层转发测试时丢包的一般原因

在性能测试过程中，经常会遇到非设备性能因素导致的丢包，对测试产生困扰。这里简单罗列几种：

• 测试套上报FCS错误。一般是因为某根网线、光纤或某个模块故障。解决方法为更换网线、光纤或模块；
• 小字节不丢包，大字节丢包。因为大字节占用buffer资源更多，所以这种情况一般是因为长帧造成的资源不足引起的，可以通过改变buffer设置，来优化测试结果；
• 大字节不丢包，小字节丢包。这种情况一般是由描述符资源限制引起的。部分芯片会为每个报文在其入端口上分配一个报文描述符，相同流量情况下，小字节占用的报文描述符就多；
• MAC HASH冲突。在二层性能测试中，如果使用大量MAC地址测试，可能会出现少量MAC不能被芯片学习的情况，导致部分流量广播，造成丢包。应先测试设备的MAC HASH能力，然后调整MAC地址的数量；
• 聚合端口HASH不均造成丢包。一般情况下，在多芯片或者堆叠环境中，芯片之间的级联口，或者堆叠设备之间的堆叠链路，都会使用多个高速链路的聚合方式来实现。在HASH算法不能保证绝对平均的情况下，会产生某条高速HASH到的流量速率过大，导致的丢包。

二、buffer性能测试

1 buffer简介

buffer是端口下的一部分存储空间，用于缓存端口拥塞时的拥塞报文。一般情况下，buffer分为独立buffer和共享buffer两种。独立buffer是指每个端口下各自独占的一块buffer，仅给本端口使用，如图2左。每个端口的独立buffer，会按照一定比例分配给每个本地队列。一般来说，默认队列所占用的资源最多。共享buffer，是一块提供给所有端口使用的buffer资源，即每个端口在自己的独立buffer用尽以后，都可以去抢占共享buffer，如图2右。当然，每个端口每个队列可以抢占的共享buffer是有一个上限的。

图2 独立buffer与共享buffer

不同设备的buffer结构各不相同。有些设备所有buffer都是独立的，按照一定比例分给所有端口；有些设备是独立+共享的方式，并且可以通过命令行进行调整。后者保证了每个端口的每个队列都有流量分布，不会出现有的端口/队列的流量太大而有的端口/队列流量很少甚至没有流量的情况，也可以在一定程度上满足部分端口和队列的突发流量对buffer的抢占需求。

在转发性能测试中，一般使用恒定速率的流量。而在实际应用中，大部分情况下是TCP流量。TCP协议使用滑动窗口机制进行发包，简单来说，TCP流量模型是连续的burst流量。

每一组burst流量，都是以网卡线速连续发送若干个报文（一般情况为1480字节，报文数目由TCP滑动窗口的大小决定）。每发出去一组burst流量，发送端都会根据对端的回应来调整下一组burst的发送时间以及burst内包含的报文数目（滑动窗口大小）。这也就意味着，即使是两条同为300Mbps的TCP流量同时从一个GE端口出去，如果两条流量的某一组burst有重合，也有可能产生拥塞。

拥塞会导致丢包和增加时延。这些都可能导致TCP重传和滑动窗口减小，进一步导致TCP速率的降低，降低链路的利用率。所以，在高带宽利用率的网络中，如数据中心，对于设备buffer能力的衡量，就成为了一个很重要的指标。

对于buffer的测试，主要从两个方面来进行：

• 一方面是设备可用buffer的大小：buffer越大，设备缓存报文的能力越强，在拥塞情况下，越不容易丢包；
• 另一方面是报文转发的时延和抖动：经过缓存后的报文，报文的时延绝对值一定会增加。但是同一条流的时延抖动应该仍然在可接受范围内。否则也会导致TCP的有效速率降低。

2 buffer容量测试之一：单端口最大可用buffer测试

该测试的目的是验证设备上单端口发生拥塞时，可以使用的最大buffer。

该测试的思路是，使用一个线速发包的端口，发送若干个burst报文。如果不丢包，则增大burst报文的数目继续测试；如果丢包，则减少burst报文的数目。直到得到设备单端口buffer的极限值。

具体测试方法：三个端口P1、P2、P3参与测试，P1向P3线速发送持续流量，P2向P3以线速burst发送N个报文，观察是否有丢包，如果有则降低N值，否则提高N的值。直到测试出两条流都不丢包情况下，N的最大值。则N*报文物理长度基本等于该设备单端口最大可用buffer值。同时记录此时两条流的时延和抖动。

考虑到不同设备内部对报文的缓存方式不同，所以一般会遍历不同包长度的情况。不同队列的buffer设置也可能不同，可以考虑遍历不同的队列进行测试。

3 buffer容量测试之二：满端口buffer测试

该测试的目的是测试整机的buffer值。测试思路是上一个测试的扩展：在所有端口都线速发包的情况下，给每一个端口都burst发送若干报文，通过是否丢包来调整burst报文的数目，找到设备整机buffer的极限值。

具体测试方法：设备上所有端口均参与测试。保留一个高速端口Pn用于发送Burst流量。其他所有端口进行持续的100%吞吐量的Full Mesh测试。同时，使用Pn向其他所有端口以线速burst发送N个单播报文。与单端口的测试相同，得到一个所有流量都不丢包情况下的最大的N值。N*报文物理大小，即基本等于设备的整机buffer。同时，记录此时所有流量的时延和抖动。

该测试一样要考虑不同大小报文的遍历和不同队列的遍历。

4 设备拥塞测试之一：HOLB测试

HOLB测试的目的很简单，就是验证设备上某一个端口产生拥塞后，会否影响其他端口的转发。

测试方法：4个端口（P1、P2、P3、P4）参与测试，P1向P2持续线速发送流量，P3使用50%的带宽向P2持续发送流量，同时使用剩下50%带宽持续向P4发送流量。此时，P2上会因为超线速而拥塞丢包。需要验证的是：P3到P4的流量没有丢包，同时该流量的时延和抖动正常。

该测试的扩展：将设备上所有端口分成4个一组，同时进行相同的HOLB测试，验证所有的P3到P4的流量没有丢包，时延和抖动正常。

5 设备拥塞测试之二：N+1 burst测试

该测试主要针对共享buffer模式的设备。一是可以测试得到设备上的共享buffer大小，二是测试发生拥塞之后，设备的buffer调度机制是如何调整的。

          

图3 N+1 burst 测试端口流量图

burst测试方法：如图3所示，设备每四个端口组成一组，在每组中，P1->P2打入线速流量，P3->P2打入burst流量，P4作为监控端口。其他端口也是四个一组，流量配置和第一组一致。先测试只有一组端口情况下，所有流量不丢包的最大burst值N；然后增加为两组端口同时测试，得到N1和N2；再三组端口同时测试，得到N1，N2，N3。随着组数的增加，测试得到的总buffer值（N1+N2+N3+…..）会越来越大。直到组数增加到某一个值后，得到的总buffer值不再增大。此时即约等于整机的共享buffer值。

N+1测试：当得到整机的buffer后，在相同的流量模型下，每一组的P3，都打入N+1个报文的burst流量。此时，设备的buffer刚好超过临界值。

此时，因为不同设备的调度策略不同，可能会有不同的测试结果：

• 测试结果一：设备会因为出端口buffer资源用尽，只丢弃这多出来的一个包。测试结果是每一组都只丢弃了这多出来的一个包。
• 测试结果二：设备为了防止发生拥塞的端口长时间占用太多资源，会触发一个惩罚机制，动态的减小该端口/队列可以抢占的资源上限。导致测试的结果是，每一组流量的丢包都大于1。

6 使用真实的TCP流量进行buffer测试

以上的测试结果都比较抽象，若想直观具体的体现出设备的buffer性能还需要用真实的TCP流量来测试。

使用某些可以发送100%吞吐量的TCP流量的L4-L7协议仿真测试板卡，可以进行如下的测试，测试出设备buffer调度能力的直观具体的性能指标。

图4 拥塞环境下的TCP流量转发测试

测试思路如下：两个设备通过高速链路互联，每个设备上连接若干个测试仪器端口。每个设备的端口为一组，两组之间互相发送backbone流量。此处的流量是使用L4—L7测试仪器构建的TCP流量（建议使用有效带宽较大的FTP协议）。每一组端口的物理带宽之和，要超过互联端口的带宽。测试组网见图4，其中，高速互联口为10GE，每个设备上选择20个GE口，互相发送backbone的FTP流量。

在固定长度时间内（如5分钟）进行测试。测试完成之后，计算两组端口之间传输的FTP报文的总大小，然后算出总的平均速率V（需换算为报文的物理层速率）。

测试结果为：

• 如果设备的buffer性能足够，那么V应该接近10GE，互联链路的有效带宽为100%。否则会导致TCP的重传，以及滑动窗口调整，互联链路的有效利用率下降，V小于10GE。
• 如果V约等于10GE，则增加两个设备上的测试仪器端口数目，再次测试；
• 如果V明显小于10GE，则降低两个设备上的测试仪器端口数目，再次测试。
• 最终得到一组数据，体现出在不同端口数目的情况下（也就是不同程度的拥塞情况下），设备的有效带宽利用率。

结束语

性能测试涉及的细节很多，每一个细节，可能都会对测试的结果产生不可预知的影响。反过来说，深入了解每一个细节，以及背后所隐藏的内容，才能够设计出更优秀的测试用例，也才能够得到更加客观、有意义的测试结果。