不容忽视的MTU值

MTU即最大传输单元，是一种通信协议的某一层上面所能通过的最大数据包大小（以字节为单位）。因为协议数据单元的包头和包尾的长度是固定的，MTU越大，则一个协议数据单元承载的有效数据就越长，通信效率也越高，而传送相同的用户数据所需的数据包个数也越低。MTU也不是越大越好，因为MTU越大， 传送一个数据包的延迟也越大；并且MTU越大，数据包中bit位发生错误的概率也越大。MTU越大，通信效率越高而传输延迟增大，所以要权衡通信效率和传输延迟选择合适的MTU。笔者单位最近出现的VOD点播卡顿故障，经过采用对比和show命令的使用，最终将故障定位在了ONU的MTU值设置上。接下来就具体介绍一下故障的处理过程。

故障现象

近日，有同事报修VOD点播卡顿，具体故障现象是用户观看点播视频时，画面出现马赛克现象。

故障分析

得知故障现象后，在展开排查的同时，进一步收集故障信息，得知部分点播用户使用点播服务出现卡顿、马赛克等现象。为尽快解决故障，需要寻找一个平衡点，即可以比照的参照物。在点播业务正式商用之前，为了提供一个良好的点播监测平台，我们对点播业务进行全天候监测，具体的实施方法很简单，主要涉及到点播平台关键设备的网管，具体包括交换机在线状态、主备服务器服务状态、用户在线数量实时统计、故障告警等其他常见参数。

在对点播平台网管进行梳理，并在数据机房对点播业务进行了实时观看后均没有发现问题。根据用户报障的信息，我们迅速锁定了就近的数据基站，接下来就是要在靠近用户侧的数据基站，对反映点播故障的视频节目进行查看，没有发现视频卡顿的现象。这样可以肯定视频资源是没有问题的。

故障解决

既然点播视频资源和基站测试正常，下一步就需要按照网络层次排查下汇聚和接入网络，即EPON设备。在排查设备之前需要了解一下网络拓扑情况，具体的网络拓扑情况即BRAS直连OLT，然后使用ONU入户，实现互联网和点播的接入工作。刚才我们介绍到在覆盖报障用户的数据基站测试点播正常，那么可以排除整个链路的带宽使用情况，即BRAS和OLT，PON口的流量，这样故障就逐步缩小在了OLT的PON以下。

来到用户侧进行查看,首先排查物理层问题，即网线、高清线等环节，均没有发现问题。尝试对网络进行数据抓包，通过抓包可以发现从ONU端口有发出的报文，但是没有返回的报文。使用命令show inter onu 1/1/2 system查看该ONU的MTU值是1596，而使用命令show system mtu查看整台OLT的MTU值是1526，我们尝试修改ONU的MTU值，配置命令即：

将ONU的MTU值改成和OLT系统相同的值后，再次观看点播视频时，视频卡顿的现象均没有出现。经过长时间观察，没有再次出现视频卡顿的问题，故障得以解决。

故障总结

通过对视频资源的对比观看，并按照网络层次进行排查，然后通过抓包软件准确找到故障原因，最终通过修改ONU的MTU值达到了解决问题的目的。后期我们对MTU值进行了深入的分析得知，本地MTU值大于网络MTU值时，本地传输的数据包过大导致网络会拆包后传输，不但产生额外的数据包，而且消耗了“拆包、组包”的时间。本地MTU值小于网络MTU值时，本地传输的数据包可以直接传输，但是未能完全利用网络给予的数据包传输尺寸的上限值，传输能力未完全发挥。

这样我们就知道，所谓合理的设置MTU值，就是让本地MTU值与网络MTU值一致，既能完整发挥传输性能，又不让数据包拆分。上面就是将ONU和OLT的MTU值都设置成1526保持一致才达到解决问题的目的。回到该款OLT上来，OLT的端口允许报文一次通过（不进行分片）的最大字节数1526。当转发报文的长度1596超过设备允许的最大值1526时，设备将会自动丢弃该报文，所以才出现抓包时的没有回复报文的的现象发生。这也是VOD点播出现马赛克卡顿的最终原因所在。

针对该故障的出现，我们联系厂家技术支持工程师对设备进行整体软件升级，杜绝该问题的再次出现。