因MTU问题导致ping丢包(长包不过)

发布时间:  2011-06-14 浏览次数:  218 下载次数:  2
问题描述
从NodeB往路由器方向Ping包,超过1454长度的报文无法通过。
网络结构为:NodeB直连我司OSN 1500的接口板EFS8;OSN 1500通过GE口连接到一个OSN 7500上;OSN 7500连接路由器,对接RNC。

无。
处理过程
1、从NodeB往路由器分别Ping??1473、1455、1454长度的把文,观察端口MAC计数,可以看出,从NodeB Ping过来的报文,实际上增加了46字节。因此无线侧ping报文的MTU,实际上只包含了净荷,不包括MAC层的其他信息,如:DA、SA、VLAN、FCS等。经SE确认:“其实OSN设备的“MTU”应该叫最大包长(包含DA SA),借用了“MTU”这个名称。”
2、在操作中发现,在OSN 3500和OSN 1500对接的场景下,只需改变RNC的最小分片包长即可,不用改NodeB的。因此咨询研发我们的业务MTU校验机制,确认在PL317芯片(OSN 1500的Q1PEGS2单板的芯片)上是在pw->VUNI处校验;而在SD8850芯片(0SN 3500/7500的N1PEG8、N1PEX2、N2PEX1的芯片)上是在VUNI->pw处校验。例如:在NodeB上往RNC ping 2000字节MTU的报文,将会被NodeB拆成1500+500两个包来发(NodeB没改),因为在下隧道时校验业务MTU,但下隧道却是OSN 3500,而OSN 3500又是在上隧道时校验,所以相当于没校验,这时报文可以正常通过;ping报文到RNC后,RNC发出2000字节的响应报文,但被拆成了1480+520两个包发出去(RNC改了最小分片包长),此时OSN 3500在上隧道时校验(小于业务MTU 1500),OSN 1500在下隧道校验(小于业务MTU 1500),因此也能正常通过;最终结果是Ping包正常无丢包。也可以说明在RNC没改之前ping不通的原因了。
根因
N/A
解决方案
1、观察与微波或NodeB对接的端口MAC计数(或RMON性能统计,但接口板暂不支持统计报文的字节长度);
2、根据在端口看到的MAC计数,在无线侧修改(减小)最小分片包长;
或2、增加业务MTU(目前不支持PW承载的业务MTU在线修改功能,必须删除PW后重建)。
建议与总结
创建PW前,需从无线侧了解清楚业务MTU的需求,并适当增加一定字节数(至少增加46字节)来确定PW业务MTU的大小。

END