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

发布时间:  2014-10-27 浏览次数:  403 下载次数:  0
问题描述
整网拓扑如下:

1、在5月1日H3C测试平台,进行测试发现: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由MX960发出的ICMP报文。

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

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

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

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

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

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

H3C平台不存在问题的原因
MX960默认MTU为1500,与H3C平台对接时未使能MPLS,所转发的报文不需要封装label标签,portal发出的1514大小的报文去除二层头之后的1500大小刚好可以转发通过,而与ME60对接时使用了跨域option B方式,报文转发时封装了label标签,当portal发出的1514大小的报文转发时会带上4字节的标签,也就是1504大小,超过了MX960的默认MTU,无法转发。
解决方案
通过与juniper工程师联系,修改MX960下行接口MTU为1574,经过测试发现卡顿现象消失

END