不容忽視的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點播出現馬賽克卡頓的最終原因所在。

針對該故障的出現，我們聯系廠家技術支持工程師對設備進行整體軟件升級，杜絕該問題的再次出現。