【测试工具】你不可不知的思博伦TestCenter技术签名字段

引言

在交换机和路由器的测试中，经常需要测到典型字节64、128、256、512、1024、1280、1518的吞吐性能。当使用思博伦的TestCenter测试时，在某些场景下测试64字节和1518字节会出现99%+丢包，吞吐量测试结果为0的问题。原因是TestCenter发流的每个数据包都含有一个20字节的专有技术签名字段，当测试字节过大过小会引起此字段被破坏，导致TestCenter收到后无法甄别进而判断为没接收数据包。本文介绍思博伦TestCenter的技术签名字段，及其对测试字节大小的影响。

消失的数据包

最近有朋友咨询一个TestCenter打流遇到的问题，他用TestCenter测试RFC2544，64字节的吞吐量测试结果为0。手动发100Mbps的64字节UDP流发现很奇怪的现象，端口统计结果和流统计严重不一致，在端口统计中，接收口的速率跟发送口的一致，说明打流几乎没有丢包，但在流统计中，接收速率只有0.39Mbsp，远低于发送速率100Mbps，说明有打流有大量丢包。难道TestCenter出异常了？

其实不然，端口统计结果中的Rx L1 Rate统计的单纯是此接口收到的报文，甚至包括由其他设备发出的报文，而流统计结果的Rx L1 Rate统计的接到的仅限于此流发出的报文。当流发出报文被破坏，TestCenter收到后无法识别就会判断它不是此流发出的报文，结果就导致流的TX和RX速率相差甚远，甚至RX速率为0。这里的报文被破坏，主要指报文的技术签名字段被破坏。

TestCenter的核心机制：技术签名字段

思博伦TestCenter是一款高性能网络测试平台，主要用于验证和评估网络设备及系统的性能，可以精确统计流量丢包、乱序、时延等等，而这些功能都依赖TestCenter特有的技术签名字段。

在TestCenter的官方文档中对技术签名字段（Signature Field）的介绍如下图

从中可以看出，技术签名字段含有32位的Stream ID和38位的以10纳米为单位的Timestamp，前者可以支持最高40亿个流报文，可以用于统计丢包和乱序，后者可以用于精确地统计时延。

此外还有一点很关键，技术签名字段固定为20字节，且在IP数据包的末尾，这意味着TestCenter构造的报文不能太小，否则不够字节容纳技术签名字段，也不能太大，否则在传输过程中出现分片，在报文末尾的数字签名字段极有可能被拆分在两个数据包中。因此，在用TestCenter跑大小字节的吞吐性能时，需要根据需要选择合适的最小最大字节，不能一味地跑64字节和1518字节。

当帧太小时，Data部分只有18字节，无法容纳技术签名字段

当帧太大时，数据包被分配，技术签名字段的前12个字节被分在数据块1中

如何计算出打流字节

首先，我们需要了解TestCenter的一个机制，即建流时设的帧大小，就是发出的数据报文的大小，包含所有报文头部、Data部分以及校验和。

如上图，一个64字节的UDP构成包括14字节以太网头部，20字节的IP头部，8字节的UDP头部，18字节的Data，4字节的帧校验序列FCS。

其次，我们要了解常见的报文头部大小

以太网头部（eth）:14字节

VLAN标签（vlan）：4字节

IP头部（ip）：20字节

PPP头部（ppp）：8字节

UDP头部（udp）：8字节

TCP头部（tcp）：20字节

帧校验序列（FCS）：4字节

然后，为了避免出现分片，需要保证发送的帧的IP头部+Data部分不能大于MTU，其中IPOE WAN的MTU最大值是1500，PPPOE WAN的MTU值最大是1492

根据不同的打流场景，计算出报文最小和最大字节数

场景1，IPOE WAN不带vlan且MTU设为1500，打UDP流测NAT性能

LAN to WAN和WAN to LAN，两种场景LAN口和WAN口发出的报文结构一样，所以最大最小字节也一样：

最小字节=eth+ip+udp+技术签名+FCS=14+20+8+20+4=66字节

最大字节=eth+MTU+FCS=14+1500+4=1518字节

场景2，PPPOE WAN不带vlan且MTU设成1492，打UDP流测NAT性能

LAN to WAN，LAN口发出的不带ppp头部的报文

最小字节=eth+ip+udp+技术签名+FCS=14+20+8+20+4=66字节

最大字节=eth+MTU+FCS=14+1492+4=1510字节

WAN to LAN，WAN口发出带ppp头部的报文

最小字节=eth+ppp+ip+udp+技术签名+FCS=14+8+20+8+20+4=74字节

最大字节=eth+ppp+MTU+FCS=14+8+1492+4=1518字节

如果要同时跑LAN to WAN和WAN to LAN，综合两种流方向的最小最大字节，最小字节跑74字节，最大字节跑1510字节。

场景3，IPOE WAN带vlan且MTU设成1500，打UDP流测NAT性能

LAN to WAN，LAN口发出不带vlan的报文

最小字节=eth+ip+udp+技术签名+FCS=14+20+8+20+4=66字节

最大字节=eth+MTU+FCS=14+1500+4=1518字节

WAN to LAN，LAN口发出带vlan的报文

最小字节=eth+vlan+ip+udp+技术签名+FCS=14+4+20+8+20+4=70字节

最大字节=eth+vlan+MTU+FCS=14+1500+4=1522字节

如果要同时跑LAN to WAN和WAN to LAN，综合两种流方向的最小最大字节，最小字节跑70字节，最大字节跑1518字节。

场景4，PPPOE WAN带vlan且MTU设成1492，打UDP流测NAT性能

LAN to WAN，LAN口发出的不带vlan不带ppp头部的报文

最小字节=eth+ip+udp+技术签名+FCS=14+20+8+20+4=66字节

最大字节=eth+MTU+FCS=14+1492+4=1510字节

WAN to LAN，WAN口发出带vlan带ppp头部的报文

最小字节=eth+vlan+ppp+ip+udp+技术签名+FCS=14+4+8+20+8+20+4=78字节

最大字节=eth+vlan+ppp+MTU+FCS=14+4+8+1492+4=1522字节

如果要同时跑LAN to WAN和WAN to LAN，综合两种流方向的最小最大字节，最小字节跑78字节，最大字节跑1510字节。

汇总

TCP流最小最大字节的计算与UDP流的一样，不重复计算过程。

在此汇总各类场景下，Testcenter打流的最小字节和最大字节，方便大家查阅使用：

传输协议	WAN类型	valn	方向	最小字节	最大字节
UDP	IPOE	不带VLAN	上行	66	1518
			下行	66	1518
			双向	66	1518
		带VLAN	上行	66	1518
			下行	70	1522
			双向	70	1518
	PPPOE	不带VLAN	上行	66	1510
			下行	74	1518
			双向	74	1510
		带VLAN	上行	66	1510
			下行	78	1522
			双向	78	1510
TCP	IPOE	不带VLAN	上行	78	1518
			下行	78	1518
			双向	78	1518
		带VLAN	上行	78	1518
			下行	82	1522
			双向	82	1518
	PPPOE	不带VLAN	上行	78	1510
			下行	86	1518
			双向	86	1510
		带VLAN	上行	78	1510
			下行	90	1522
			双向	90	1510

特殊场景：LAN to LAN打流

有些经验丰富的网友可能有疑问，按照上述计算，LAN to LAN打UDP流，最小字节应该是66字节，但实践中打64字节流也是无丢包，这如何解释呢？

根据TestCenter的官网文档，20字节的技术签名字段会填写到IP数据包的最后20个字节中，UDP报文的IP包由UDP头部和Data组成，当Data只有18字节不足20字节，技术签名字段的前两个字节就填到UDP头部的校验和字段中。

依次点开连续的三个64字节数据包的UDP头部，可以看到Checksum的第一个字节是连续的，如下图分别是0xaa、0xa9、0xa8，说明checksum字段填写不是真正的校验和，而是技术签名字段的前两个字节。

依次点开连续的三个66字节数据包的UDP头部，可以看到Checksum的第一个字节是随机的，如下图依次是0xe3、0xf9、0x7c，说明checksum填写的确实是UDP的校验和。

LAN to LAN打UDP流，发送报文和接收报文是完全相同的，技术签名字段部分填到UDP头部，TestCenter仍能识别。LAN to WAN打流，发送报文和接收报文相比，源IP和源mac已改变，TestCenter不一定能识别。所以，测LAN to LAN最小字节可以发64字节，LAN to WAN最小字节必现发66字节。

---

原创不易，你的支持是我最大的动力，欢迎大家点赞，收藏，关注！