QoS测试中数据包不按既定规则在专用承载上发送问题

admin

QoS测试中数据包不按既定规则在专用承载上发送问题【案例描述】

解决方案QoS测试环境反馈使用三星UE做QoS测试，从UGW触发专有承载建立，采用端口匹配的方式，TCP业务能够正常的完全通过专有承载传输，但是发起UDP业务时，专有承载和默认承载上均有大量数据。

【关键字】

QoS、TCP、UDP、Dedicated Bearer

【版本信息】

非代码缺陷，与版本无关。

【定位思路分析】

TCP业务正常，UDP业务不正常，那么需要对比两种业务在专用承载上的差别，从差别入手进行分析。由于专用承载采用端口匹配的方式，可以考虑差别是否和此种匹配方式有关。

【定位信息】

Ethereal抓包，WebLMT用户吞吐率跟踪，Probe跟踪

【定位过程】

了解问题现象，根据现象进行了简单分析：专有承载使用端口区分的方式，TCP正常，UDP不正常，问题似乎出在TCP和UDP使用了不同的端口上。

TCP业务通过FTP触发，数据链固定使用20号端口；UDP业务使用iperf灌包触发，通过添加 –p 选项固定了UDP端口，如果按照端口filter的方式没错，两者都应该通过端口匹配走到默认承载上。现在的问题是UDP灌包时默认承载上也有大量数据，是否是UDP的问题，抓包来确定。

从抓包结果来看，UDP灌包时出现了分片，检查系统MTU设置，发现对三星终端的USB口设置的MTU确实做过改动，最新的MTU值为1360，而iperf默认的灌包包长为1470+8+20＝1498字节。出现分片是正常的，但是是否是分片导致了这个问题的发生呢？

修改iperf灌包命令，使得灌包的UDP包MTU小于1360个字节，结果果然所有的UDP数据均走了正常的专有承载，问题解决。

原因追溯：通过UGW触发专有承载建立，中间有一步是配置知名端口（通过知名端口识别7层协议类型）：

/****************************************************************************************************************

[UGW9811_telenor-service]well-known-port tmo l7-protocol rtsp sub-protocol rtsp port eq 5033 priority 2

配置知名端口

*************************************************************************************************************/

而对于产生分片的数据包来说，第一个分片由于没有重组数据，是不带端口号的，整个数据报的内容只能在最后一个分片中看到，如下图：

第一个分片：

由此可知，由于没有高层端口号，第一个分片不能匹配到专有承载上，只能走默认承载，而第二个分片通过端口匹配，在专有承载上传输。由此造成了两个承载上都有数据的现象。

而对于TCP，由于在建链过程存在MTU协商过程，使得一开始使用的数据包就满足最小MTU的条件，不会产生分片，因而数据包都可以正常分发到正确的专用承载上。

同样，对于UE侧触发的专有承载建立，不需要规定端口号，按服务器IP地址区分。所以即便被分片，分片包还是会按IP头对端服务器地址匹配到正确的专有承载上。

【问题根因】

由于iperf默认灌包包长超过了网卡的MTU设置值，导致了数据包分片，而第一个分片包不能解析出端口号，对于按照端口号来区分的专有承载，部分数据无法匹配，只能走默认承载，由此造成了两个承载上都有大量数据在传送。

【建议与总结】

做QoS测试，从UGW触发专有承载建立时，建议采用IP匹配的方式。

分片包知识：

把一份IP数据报分片以后，只有到达目的地才进行重新组装。重新组装由目的端的I P层来完成，其目的是使分片和重新组装过程对运输层（TCP和UDP）是透明的。

回到IP首部，下面这些字段用于分片过程。对于发送端发送的每份IP数据报来说，其标识字段都包含一个唯一值。该值在数据报分片时被复制到每个片中（我们现在已经看到这个字段的用途）。标志字段用其中一个比特来表示“更多的片”。除了最后一片外，其他每个组成数据报的片都要把该比特置1。片偏移字段指的是该片偏移原始数据报开始处的位置。另外，当数据报被分片后，每个片的总长度值要改为该片的长度值。最后，标志字段中有一个比特称作“不分片”位。如果将这一比特置1，IP将不对数据报进行分片。

在分片时，除最后一片外，其他每一片中的数据部分（除IP首部外的其余部分）必须是8字节的整数倍。

第一个分片：

第二个分片：

qiumao1212

案例不错，多谢分享