OSN1500,OSN3500因MTU问题导致ping丢包

问题描述

从NodeB往路由器方向Ping包，超过1454长度的报文无法通过。

网络结构为：NodeB直连我司OSN 1500的接口板EFS8；OSN1500通过GE口连接到一个OSN7500上；OSN7500连接路由器，对接RNC。

处理过程

1、观察与微波或NodeB对接的端口MAC计数（或RMON性能统计，但接口板暂不支持统计报文的字节长度）；

2、根据在端口看到的MAC计数，在无线侧修改（减小）最小分片包长；

或2、增加业务MTU（目前不支持PW承载的业务MTU在线修改功能，必须删除PW后重建）。

根因

1、从NodeB往路由器分别Ping 1473、1455、1454长度的把文，观察端口MAC计数，可以看出，从NodeB Ping过来的报文，实际上增加了46字节。因此无线侧ping报文的MTU，实际上只包含了净荷，不包括MAC层的其他信息，如：DA、SA、VLAN、FCS等。经SE确认：“其实OSN设备的“MTU”应该叫最大包长（包含DA SA），借用了“MTU”这个名称。”

2、在操作中发现，在OSN3500和OSN1500对接的场景下，只需改变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不通的原因了。

建议与总结

创建PW前，需从无线侧了解清楚业务MTU的需求，并适当增加一定字节数（至少增加46字节）来确定PW业务MTU的大小。