所选语种没有对应资源,请选择:

本站点使用Cookies,继续浏览表示您同意我们使用Cookies。Cookies和隐私政策>

提示

尊敬的用户,您的IE浏览器版本过低,为获取更好的浏览体验,请升级您的IE浏览器。

升级

MTU设置过小导致portal页面打开缓慢

发布时间:  2019-07-03 浏览次数:  1232 下载次数:  4

问题描述

整网拓扑如下:
 
1、在5月1日友商测试平台,进行测试发现:150+STB获取地址正常,TV打开portal页面正常;
2、在我司ME平台测试,发现少量STB上线时,获取地址正常,TV打开portal页面稍微出现卡顿现象;大量STB上线时,打开portal页面卡顿现象明显。

告警信息

无告警

处理过程

怀疑一:ME配置文件
经过验证VOD点播部分配置无误。

怀疑二:ME发生丢包
经过确认ME上没有出现丢包现象。

怀疑三:网络其他部分存在问题
为了确认问题发生原因,在上图两个点对问题出现时的流量进行镜像分析:
  
1、 两个镜像点1和2获取报文如下(两台笔记本同时抓,系统时间不同):
 
视频卡顿可以通过两个镜像点的①与③之间的时间间隔看出来,笔记本1纪录的卡顿时间是11:07:13~11:07:44,笔记本2纪录的卡顿时间是11:02:55~11:03:26,卡顿约21秒。
通过上面的对比可以看到在镜像点1(NE40E)抓到的大小为1514的报文②在传输中被丢弃了,这也是造成视频卡顿的原因。

2、镜像点1中存在,而镜像点2中未抓到的报文如下:

发现portal服务器在给STB发送了四个TCP分片包之后,因为未收到ACK确认报文,所以开始重传,并在最后收到一个序号为15由省干接入发出的ICMP报文。

3、在第14个TCP包中详细信息如下

标红色出标明该报不能分片。

4、在第15个ICMP包中详细信息如下

该报文由省干接入发出给portal服务器,标红出标明原因是目的不可达,需要分片,下一跳MTU为1488。

5、再看两个镜像点所抓的报文③部分,后续正常传输包MTU为1474。

根因

由以上几点可以推断出如下结论:
由STB发出TCP连接请求,经过三次握手后,建立TCP连接。然后STB通过HTTP方式请求portal,portal服务器发出报文,其中有部分报文为1514长度。在经过省干接入时发现超过MTU,需要分片,但是该报文表示为不可分片,因此省干接入发出ICMP报文给portal服务器,请求MTU为1488的包。后续portal服务发出1474的IP包,正常通过MX960,再经过ME60,到达STB。

友商平台不存在问题的原因
 省干接入设备默认MTU为1500,与友商平台对接时未使能MPLS,所转发的报文不需要封装label标签,portal发出的1514大小的报文去除二层头之后的1500大小刚好可以转发通过,而与ME60对接时使用了跨域option B方式,报文转发时封装了label标签,当portal发出的1514大小的报文转发时会带上4字节的标签,也就是1504大小,超过了省干接入的默认MTU,无法转发。

解决方案

通过与友商工程师联系,修改省干接入下行接口MTU为1574,经过测试发现卡顿现象消失

END