關於×××鏈路中的MTU傳輸問題

時間 2019-12-28

標籤關於鏈路 mtu 傳輸問題简体版

原文原文鏈接

轉自： http://bbs.chinaunix.net/viewthread.php?tid=1193897

1、問題概述：
在咱們的實際組網中常常遇到此類問題：
1）某些網站瀏覽沒有問題，而某些網站瀏覽很是慢甚至沒法瀏覽。QQ等正常沒有任何問題。
2）沒法下載大的文件。
3） EMAIL沒法發大附件。
2、問題分析：
通常所來是因爲路徑MTU不匹配的緣故，特別是在通過了×××鏈路的時候，譬如ADSL PPPOE撥號，L2TP,PPTP,IPSEC,GRE隧道等狀況。下面就以GRE隧道爲例來講明MTU的問題，其餘隧道協議相似只是頭部字節不一樣而已。
拓撲結構：

×××網關1和2之間創建了一條GRE隧道，×××1 ×××2的外網口均爲以太網口，MTU爲1500。PC與SERVER經過該GRE隧道互訪。
分析過程：
PC在ping –f –l 1448 SERVER 的時候能夠ping 通，而ping –f –l 1449 SERVER的時候卻收到報文不可分片錯誤。
PC出來的IP報文長度爲1448＋8（ICMP）＋20（IP），到達×××網關1，×××網關1發到GRE隧道口，封裝GRE頭（4），再加上外層IP頭，到達×××網關外層以太口，這時IP報文的長度已經變爲：1448＋8＋20＋4＋20＝1500字節，恰好等於以太口的MTU，因而被順利傳送。而ping 1449時，到達外層以太口爲1501字節，超出了1500的MTU，又由於報文DF位被設置，因而就只能丟棄改報文，並返回DF錯誤。
上述實驗中出現此結果是由於DF被置位，致使沒法分片。可是若是DF沒有置位則能夠正常的經過可是會出現分片的現象。不過如今不少服務器譬如WEB爲了提升效率以及安全問題等所發出的包是不容許分片的。而且大多防火牆、IPS等設備，這些設備一般也是不容許分片經過的。所以就出現了有些網站沒法瀏覽，大文件沒法傳輸的狀況。

解決方法：
假設PC創建了到SERVER的HTTP鏈接，PC但願從SERVER下載一個大的網頁。SERVER接收到PC的請求後開始發送大網頁文件，其IP的DF位置1，不容許分片，IP報文長度爲1500字節。到達×××網關2的外網口（以太）後，×××網關2發現其長度超過了1500個字節，因而將其丟棄，並給SERVER發回一個目的地址不可達的ICMP信息，同時指出「MTU of next hop: 1500」。PC接收到該消息後，又按照1500字節對外發送，又被丟棄，因而就造成了循環，沒法通信。
根據上述的分析，很容易獲得以下解決方式，在×××網關2的出接口設置MTU爲1500－4－20＝1476，這樣×××網關2返回ICMP不可達消息時將給出」MTU of next hop: 1476」。SERVER將以1476做爲本身的最大MTU對外發送，到達×××網關1，封裝GRE和外層IP頭後就不會超過1500而順利發到對端。這個是下載問題的解決，若是要解決上傳的問題，在相應方向的接口修改MTU便可。固然也能夠修改TCPMSS，不過這個是影響到TCP的windows從而減少了包的長度。另外修改操做系統的最大MTU值也是可行的，不過比較麻煩。