先學習理解一下幀的封裝格式：
需要注意的是，區別兩種幀封裝格式：802標準幀和以太網幀
1，在802標準定義的幀格式中，長度字段是指它後續數據的字節長度，但不包括C R C檢驗碼。RFC 1042（IEEE 802）
2，RFC 894（以太網）
所以，以太網幀報頭爲目的地址6+源地址6+類型2+CRC 4=18bytes
而802幀沒有CRC，所以爲14bytes。Sniffer採用的是802幀爲14bytes
轉載文章：
MTU: Maxitum Transmission Unit 最大傳輸單元
MSS: Maxitum Segment Size 最大分段大小
MSS: Maxitum Segment Size 最大分段大小
由於以太網EthernetII最大的數據幀是1518Bytes這樣，刨去以太網幀的幀頭（DMAC目的地址MAC48bit=6Bytes+SMAC源MAC地址48bit=6Bytes+Type域2bytes）14Bytes和幀尾CRC校驗部分4Bytes（這個部門有時候大家也把它叫做FCS），那麼剩下承載上層協議的地方也就是Data域最大就只能有1500Bytes. 這個值我們就把它稱之爲MTU。
以太網的MTU是1500，再減去PPP的包頭包尾的開銷（8Bytes），就變成1492。
MSS就是TCP數據包每次能夠傳輸的最大數據分段。爲了達到最佳的傳輸效能
TCP協議在建立連接的時候通常要協商雙方的MSS值，這個值TCP協議在實現的
時候往往用MTU值代替（需要減去IP數據包包頭的大小20Bytes和TCP數據段的
包頭20Bytes）所以往往MSS爲1460。通訊雙方會根據雙方提供的MSS值得最小
值確定爲這次連接的最大MSS值。
先說說這MTU最大傳輸單元，這個最大傳輸單元實際上和鏈路層協議有着密切的關係，讓我們先仔細回憶一下EthernetII幀的結構DMAC+SMAC+Type+Data+CRC。由於以太網傳輸電氣方面的限制，每個以太網幀都有最小的大小64bytes，最大不能超過1518bytes，對於小於或者大於這個限制的以太網幀我們都可以視之爲錯誤的數據幀，一般的以太網轉發設備會丟棄這些數據幀。（注：小於64Bytes的數據幀一般是由於以太網衝突產生的“碎片”或者線路干擾或者壞的以太網接口產生的，對於大於1518Bytes的數據幀我們一般把它叫做Giant幀，這種一般是由於線路干擾或者壞的以太網口產生）
由於以太網EthernetII最大的數據幀是1518Bytes這樣，刨去以太網幀的幀頭（DMAC目的MAC地址48bit=6Bytes+SMAC源MAC地址48bit=6Bytes+Type域2bytes）14Bytes和幀尾CRC校驗部分4Bytes（這個部門有時候大家也把它叫做FCS），那麼剩下承載上層協議的地方也就是Data域最大就只能有1500Bytes這個值我們就把它稱之爲MTU。這個就是網絡層協議非常關心的地方，因爲網絡層協議比如IP協議會根據這個值來決定是否把上層傳下來的數據進行分片。就好比一個盒子沒法裝下一大塊麪包，我們需要把麪包切成片，裝在多個盒子裏面一樣的道理。
當兩臺遠程PC互聯的時候，它們的數據需要穿過很多的路由器和各種各樣的網絡媒介才能到達對端，網絡中不同媒介的MTU各不相同，就好比一長段的水管，由不同粗細的水管組成（MTU不同 :)）通過這段水管最大水量就要由中間最細的水管決定。
對於網絡層的上層協議而言（我們以TCP/IP協議族爲例）它們對水管粗細不在意它們認爲這個是網絡層的事情。網絡層IP協議會檢查每個從上層協議下來的數據包的大小，並根據本機MTU的大小決定是否作“分片”處理。分片最大的壞處就是降低了傳輸性能，本來一次可以搞定的事情，分成多次搞定，所以在網絡層更高一層（就是傳輸層）的實現中往往會對此加以注意！有些高層因爲某些原因就會要求我這個麪包不能切片，我要完整地面包，所以會在IP數據包包頭裏面加上一個標籤：DF（Donot Fragment）。這樣當這個IP數據包在一大段網絡（水管裏面）傳輸的時候，如果遇到MTU小於IP數據包的情況，轉發設備就會根據要求丟棄這個數據包。然後返回一個錯誤信息給發送者。這樣往往會造成某些通訊上的問題，不過幸運的是大部分網絡鏈路都是MTU1500或者大於1500。
對於UDP協議而言，這個協議本身是無連接的協議，對數據包的到達順序以及是否正確到達不甚關心，所以一般UDP應用對分片沒有特殊要求。
對於TCP協議而言就不一樣了，這個協議是面向連接的協議，對於TCP協議而言它非常在意數據包的到達順序以及是否傳輸中有錯誤發生。所以有些TCP應用對分片有要求---不能分片（DF）。
花開兩朵，各表一枝，說完MTU的故事我們該講講今天的第二個豬腳---PPPoE所謂PPPoE就是在以太網上面跑PPP協議，有人奇怪了，PPP協議和Ethernet不都是鏈路層協議嗎？怎麼一個鏈路層跑到另外一個鏈路層上面去了，難道升級成網絡層協議了不成。其實這是個誤區：就是某層協議只能承載更上一層協議。
爲什麼會產生這種奇怪的需求呢？這是因爲隨着寬帶接入（這種寬帶接入一般爲Cable Modem或者xDSL或者以太網的接入）由於以太網缺乏認證計費機制而傳統運營商是通過PPP協議來對撥號等接入服務進行認證計費的，所以就出了這麼一個怪胎：PPPoE。（有關PPPoE的詳細介紹參見V大以及本站其他成
員的一些介紹文章，我就不囉裏囉唆的了）
PPPoE帶來了好處，也帶來了一些壞處，比如：二次封裝耗費資源，降低了傳輸效能等等，這些壞處俺也不多說了，最大的壞處就是PPPoE導致MTU變小了以太網的MTU是1500，再減去PPP的包頭包尾的開銷（8Bytes），就變成1492。
如果兩臺主機之間的某段網絡使用了PPPoE那麼就會導致某些不能分片的應用無法通訊。
這個時候就需要我們調整一下主機的MTU，通過降低主機的MTU，這樣我們就能夠順利地進行通訊了。
當然對於TCP應用而言還有另外的解決方案。馬上請出今天第三位豬腳：MSS。
MSS最大傳輸大小的縮寫，是TCP協議裏面的一個概念。MSS就是TCP數據包每次能夠傳輸的最大數據分段。爲了達到最佳的傳輸效能TCP協議在建立連接的時候通常要協商雙方的MSS值，這個值TCP協議在實現的時候往往用MTU值代替（需要減去IP數據包包頭的大小20Bytes和TCP數據段的包頭20Bytes）所以往往MSS爲1460。通訊雙方會根據雙方提供的MSS值得最小值確定爲這次連接的最大MSS值。
我們回過頭來看前言裏面的那個問題，我們試想一下，如果我們在中間路由器上把每次TCP連接的最大MSS進行調整這樣使得通過PPPoE鏈路的最大MSS值加上數據包頭包尾不會超過PPPoE的MTU大小1492這樣就不會造成無法通訊的問題。
所以上面的問題可以通過ip tcp adjust-mss 1452來解決。
當然問題也可以通過修改PC機的MTU來解決。
[後記]
Cisco在IOS 12.2(4)T及以後的版本支持修改MSS大小的特性
Cisco的TCP Adjust MSS Feature：
The TCP MSS Adjustment feature enables the configuration of the
maximum segment size (MSS) for transient packets that traverse a router,
specifically TCP segments in the SYN bit set, when Point to Point Protocol
over Ethernet (PPPoE) is being used in the network. PPPoE truncates the
Ethernet maximum transmission unit (MTU) 1492, and if the effective MTU
on the hosts (PCs) is not changed, the router in between the host and the
server can terminate the TCP sessions. The ip tcp adjust-mss command
specifies the MSS value . the intermediate router of the SYN packets to
avoid truncation.
附：MS文章---路徑最大傳輸單元 (PMTU) 黑洞路由器
當路由器必須將 IP 包分段但又因 DF 標記設置爲 1 而不能分段時，路由器可採用以下任一種方式：
|
•
|
發送符合 RFC 792 中最初定義的“ICMP Destination Unreachable-Fragmentation Needed and DF Set”消息，然後丟棄該包。
原始消息格式中不包含有關轉發失敗的鏈路的 IP MTU 的信息。
|
|
•
|
發送符合 RFC 1191 中重新定義的“ICMP Destination Unreachable-Fragmentation Needed and DF Set”消息，然後丟棄該包。此新消息格式包含一個 MTU 字段，可指出轉發失敗的鏈路的 IP MTU。
RFC 1191 定義了路徑 MTU (PMTU) 發現，它使得成對的 TCP 對等方能夠動態地發現二者之間路徑的IP MTU，從而發現該路徑的 TCP MSS。一旦收到符合 RFC 1191 定義的“Destination Unreachable-Fragmentation Needed and DF Set”消息，TCP 就會將該連接的 MSS 調整爲指定 IP MTU 減去 TCP 和 IP 報頭的大小。這樣，在該 TCP 連接上發送的後續包就不會超過最大大小，無需分段即可在該路徑上傳輸。
|
|
•
|
直接丟棄包。
直接丟棄需分段但 DF 標記設置爲 1 的包的路由器稱爲 PMTU 黑洞路由器。
|
PMTU 黑洞路由器會給 TCP 連接帶來問題。例如，Microsoft® Windows® XP 和 Windows Server™2003 中的 TCP/IP 協議默認情況下會使用 PMTU 發現。TCP 會發送 DF 標記設置爲 1 的數據段，並且在需要時，會根據符合 RFC 1191 定義的“ICMP Destination Unreachable-Fragmentation Needed and DF Set（ICMP Type 3 Code 4）”消息的回執（其中包含 IP MTU），更改 TCP MSS值。
在 TCP 三次握手期間交換的 TCP 數據段不會太大，因而不會被 PMTU 黑洞路由器丟棄。但是，一旦開始在連接上傳輸數據—假定基於協商的 MSS 確定的 PMTU 比實際 PMTU 大—TCP 數據段的大於實際 PMTU的 IP 包就會被直接丟棄。
例如，您可以用 FTP 命令行工具成功地與 FTP 服務器建立連接並登錄。但是，當您試圖下載或者上載文件時，中間的 PMTU 黑洞路由器就會丟棄達到最大大小的 TCP 數據段，從而導致錯誤和文件傳輸失敗。
您可以按照下面的語法使用 Ping 工具來檢測 PMTU 黑洞路由器：
Pingdestination –f –l ICMPEchoPayloadSize
|
•
|
此處的 destination 可以是一個 IP 地址，也可以是一個可解析爲 IP 地址的名稱。
|
|
•
|
-f 選項可將 DF 標記設置爲 1。
|
|
•
|
-l 選項指定 ICMP Echo 消息的有效負載的大小。
|
|
•
|
ICMPEchoPayloadSize 是 ICMP Echo 消息的有效負載的字節數。
|
要計算 ICMPEchoPayloadSize，可用您想發送的 IP 包的大小減去 28。這是因爲，IP 報頭的大小爲 20字節，而 ICMP Echo 消息的 ICMP 報頭的大小爲 8 字節。下圖顯示了二者的關係。
例如，要發送長度爲 1500 字節的 ICMP Echo 消息，您應使用以下命令：
ping destination –f –l 1472
如果有 IP MTU 更小的中間鏈路，且路由器發送了“ICMP Destination Unreachable-Fragmentation Needed and DF Set”消息，則 Ping 工具會顯示“Packet needs to be fragmented but DF set”消息。如果有 IP MTU 更小的中間鏈路，且 PMTU 黑洞路由器直接丟棄了包，則 Ping 工具會顯示“Request timed out”消息。
要找出包含 PMTU 黑洞路由器的路徑的有效 IP MTU，請使用 Ping 工具，同時不斷增大 Echo 消息的有效負載的大小。因爲典型子網的最小 IP MTU 是 576 字節，因此開始時可將 ICMP Echo 消息的有效負載設置爲 548字節，然後每次遞增 100 字節，直到找到有效 PMTU。
例如，如果 ping 10.0.0.10 -f -l 972 命令顯示“Reply from 10.0.0.10”，而命令 ping 10.0.0.10 -f -l 973 顯示“Request timed out”，則 IP 地址爲 10.0.0.10 的節點的有效 PMTU 爲 1000 字節(972+28)。
PMTU 黑洞路由器的解決方案和工作方法
1. 配置中間路由器以支持路由器端 PMTU 發現
解決專用 Intranet 中的 PMTU 黑洞路由器問題的最簡單的方法，是將您的所有路由器配置爲支持路由器端RFC 1191，並支持發送 ICMP Destination Unreachable-Fragmentation Needed and DF Set 消息（其中帶有轉發失敗的鏈路的 IP MTU）。這與將路由器配置爲支持主機端 RFC 1191 是有區別的，後者的路由器會對自己的 TCP 連接使用 PMTU 發現。
在 Internet 上進行通信時，通常不太可能將 Internet 路由器配置爲支持路由器端 PMTU 發現。在這種情況下，您可以使用以下各節介紹的工作方法。
3. 確定最佳 IP MTU 並通過 MTU 註冊表設置來設置該值
啓用 PMTU 黑洞路由器檢測的替代方法，是根據本文前面部分的介紹使用 Ping 工具確定所有相關路徑的PMTU 值，然後使用註冊表設置手動配置發送接口的 IP MTU。
該方法通過不停發送 DF 標記設置爲 1，大小又不會導致 PMTU 黑洞路由器將其直接丟棄的 IP 包來避開PMTU 黑洞路由器。手動指定 IP MTU 意味着所有通信量（包括本地子網通信量和不包含 PMTU 黑洞路由器的路徑上的通信量）都將使用較小的 IP MTU。
確定有效的 PMTU 後，您可以通過以下步驟手動指定 TCP/IP 接口的 IP MTU：
|
1.
|
打開 Network Connections 文件夾，記下 LAN 連接的名稱，如“Local Area Connection”。
|
|
2.
|
單擊開始，單擊“運行”，鍵入“regedit.exe”，然後單擊“確定”。
|
|
3.
|
使用註冊表編輯器工具的樹圖（左邊窗格）打開如下鍵：HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control \Network\{4D36E972-E325-11CE-BFC1-08002BE10318}
|
|
4.
|
此鍵下面是與已安裝的 LAN 連接相關聯的全局唯一標識符 (GUID) 的一個或多個鍵。這些 GUID 鍵中的每一個都有一個 Connection 子鍵。打開每個 GUID\Connection 鍵，尋找值與第一步中記下的 LAN 連接的名稱匹配的 Name 設置。
|
|
5.
|
如果找到包含與 LAN 連接匹配的 Name 設置的 GUID\Connection 鍵，請寫下或記下該 GUID 值。
|
|
6.
|
使用註冊表編輯器的樹視圖打開如下鍵：HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip \Parameters\Interfaces\GUID
|
|
7.
|
右鍵單擊樹視圖中的“GUID”鍵，指向“新建”，然後單擊“雙字節值”。
|
|
8.
|
在註冊表編輯器工具的內容窗格（右窗格）中，爲新註冊表設置的值鍵入 MTU，然後按 ENTER。
|
|
9.
|
在內容窗格中，雙擊新的 MTU 設置，並在“編輯雙字節值”對話框中選擇“十進制”，然後在“數值數據”中鍵入有效 MTU 值。
|
|
10.
|
單擊“確定”。關閉註冊表編輯器工具。
|
|
11.
|
重新啓動計算機使 MTU 設置生效。
|
網絡故障舉例：[轉自華爲3COM全球服務論壇]
現象描述：
組網：
PC－AR2831－AR2880－CISCO設備組成的核心網－SERVER
網絡運行MPLS ***;AR2880爲PE;AR2831爲CE，PE、CE間運行OSPF,多CE配置；路由器各接口MTU、TCP MSS值採用默認設置
AR2880：Version 3.30, Release 0008
AR2831：Version 3.30, Release 0008
現象1：
AR2880路由器的以太口MTU使用缺省設置時,使用的OA系統(BS架構)部分流程無法運行,上網發郵件時附件無法粘貼；但是在cisco設備上，同樣的組網沒有發現問題；
現象2：
將AR2880路由器的以太口MTU改爲512測試,郵件附件可以粘貼,但OA主頁打開後無內容,刷新不了；將AR2880路由器的以太口MTU改爲1200測試,郵件附件可以粘貼,OA主頁可以正常顯示,但是點擊OA系統的"起草公文"無頁面彈出,正常狀況下應彈出新建公文頁面；
告警信息：
無
原因分析：
原因分析：
可能是應用軟件問題；可能是MTU 、TCP MSS值協商配置問題；
具體分析：
1、接口MTU、TCP MSS採用缺省值1500時，無法貼附件；
這是因爲應用了三層MPLS ***技術，增加了8bit的標籤，MTU值協商出現問題。
AR28XX路由器默認在接口上自動分片，所以在普通的應用中採用默認值不會影響業務。但路由器接口上收到一個報文長度大於本接口MTU值的報文，如果該報文被強制打上不分片的標記，將丟棄報文，並返回一個ICMP差錯報文（type 3,code 4），通知報文發起者丟棄原因。報文發起者將發送比較小的報文。通過多次上述報文協商，將得到對於某一個固定路徑上的最小Mtu值，這個過程叫做Mtu Discovery ，通過MTU Discovery來確定報文路徑上最小可通過的MTU；如果兩個設備相連，沒有MTU Discovery功能並且MTU值不一致，將可能導致丟棄報文。只有把雙方設備的Mtu爲對端設備MRU的最小值，才能正常通信。由於某些組網考慮到網絡安全問題和性能，往往會把ICMP報文過濾掉，引起Mtu Discovery不能正常運行；應用軟件由於程序算法問題或根本沒有相應協商功能，也會導致了部分應用異常。
2、更改接口MTU值以後，仍然有部分業務不正常；
這是因爲TCP MSS值協商的問題。
MSS值的計算方法是：MSS=MTU-IP-TCP（如果有其他pppoe、加密報文頭的話也同樣減去），也就是說MSS值其實就是TCP所承載的淨載荷的長度。由於AR28XX接口缺省的MTU是1500字節，故一般要求加密報文頭+鏈路層開銷+IP頭（20-60字節）+TCP報文（20字節）小於1500字節，即TCP分片配置1200左右比較適合。缺省情況下，TCP報文不分片。因此TCP MSS不匹配也會引起部分應用異常。
處理過程：
本例中通過修改路由器接口MTU、TCP MSS值，解決問題。
具體報文mtu 、tcp mss大小要根據具體應用，按經驗值進行嘗試，選擇最佳值；其中MTU值的選擇可以通過ping命令設置不分片來進行測試；TCP MSS值的選擇則可以通過MTU減去相應其它加密、鏈路層開銷、IP頭、TCP頭等字節計算。
具體過程如下：
1、本例中使用cisco路由器時相關應用正常。初步估計是mtu值問題，但是對普通應用AR28系列路由器會自動分片，不會影響業務。測試發現在client上ping大包的時候，如果不設置不允許分片，業務正常。看來客戶應用中做了不允許分片的設置或其它原因mtu協商錯誤。更改路由器接口mtu爲1500-8＝1492以後，業務正常。
2、更改接口mtu以後，其它部分業務還不正常。分析原因是tcp mss值的問題。減小tcp mss值8字節1460-8＝1452，但是還有部分業務不正常。詢問軟件集成商，得到答覆部分軟件中使用了加密技術。而且不同的應用加密強度不同。
3、逐步調整路由器接口的tcp mss值，減到到1200以後，所有業務測試通過。
命令說明：
1、mtu命令用來設置以太網接口的MTU（最大傳輸單元），undo mtu命令用來恢復MTU的缺省值。缺省的MTU爲1500。使用mtu命令改變接口最大傳輸單元MTU後，需要先對接口執行shutdown命令，再執行undo shutdown命令將接口重啓，以保證設置的MTU生效。
2、tcp mss命令用來配置TCP報文分片，undo tcp mss命令用來取消TCP報文分片。
組網：
PC－AR2831－AR2880－CISCO設備組成的核心網－SERVER
網絡運行MPLS ***;AR2880爲PE;AR2831爲CE，PE、CE間運行OSPF,多CE配置；路由器各接口MTU、TCP MSS值採用默認設置
AR2880：Version 3.30, Release 0008
AR2831：Version 3.30, Release 0008
現象1：
AR2880路由器的以太口MTU使用缺省設置時,使用的OA系統(BS架構)部分流程無法運行,上網發郵件時附件無法粘貼；但是在cisco設備上，同樣的組網沒有發現問題；
現象2：
將AR2880路由器的以太口MTU改爲512測試,郵件附件可以粘貼,但OA主頁打開後無內容,刷新不了；將AR2880路由器的以太口MTU改爲1200測試,郵件附件可以粘貼,OA主頁可以正常顯示,但是點擊OA系統的"起草公文"無頁面彈出,正常狀況下應彈出新建公文頁面；
告警信息：
無
原因分析：
原因分析：
可能是應用軟件問題；可能是MTU 、TCP MSS值協商配置問題；
具體分析：
1、接口MTU、TCP MSS採用缺省值1500時，無法貼附件；
這是因爲應用了三層MPLS ***技術，增加了8bit的標籤，MTU值協商出現問題。
AR28XX路由器默認在接口上自動分片，所以在普通的應用中採用默認值不會影響業務。但路由器接口上收到一個報文長度大於本接口MTU值的報文，如果該報文被強制打上不分片的標記，將丟棄報文，並返回一個ICMP差錯報文（type 3,code 4），通知報文發起者丟棄原因。報文發起者將發送比較小的報文。通過多次上述報文協商，將得到對於某一個固定路徑上的最小Mtu值，這個過程叫做Mtu Discovery ，通過MTU Discovery來確定報文路徑上最小可通過的MTU；如果兩個設備相連，沒有MTU Discovery功能並且MTU值不一致，將可能導致丟棄報文。只有把雙方設備的Mtu爲對端設備MRU的最小值，才能正常通信。由於某些組網考慮到網絡安全問題和性能，往往會把ICMP報文過濾掉，引起Mtu Discovery不能正常運行；應用軟件由於程序算法問題或根本沒有相應協商功能，也會導致了部分應用異常。
2、更改接口MTU值以後，仍然有部分業務不正常；
這是因爲TCP MSS值協商的問題。
MSS值的計算方法是：MSS=MTU-IP-TCP（如果有其他pppoe、加密報文頭的話也同樣減去），也就是說MSS值其實就是TCP所承載的淨載荷的長度。由於AR28XX接口缺省的MTU是1500字節，故一般要求加密報文頭+鏈路層開銷+IP頭（20-60字節）+TCP報文（20字節）小於1500字節，即TCP分片配置1200左右比較適合。缺省情況下，TCP報文不分片。因此TCP MSS不匹配也會引起部分應用異常。
處理過程：
本例中通過修改路由器接口MTU、TCP MSS值，解決問題。
具體報文mtu 、tcp mss大小要根據具體應用，按經驗值進行嘗試，選擇最佳值；其中MTU值的選擇可以通過ping命令設置不分片來進行測試；TCP MSS值的選擇則可以通過MTU減去相應其它加密、鏈路層開銷、IP頭、TCP頭等字節計算。
具體過程如下：
1、本例中使用cisco路由器時相關應用正常。初步估計是mtu值問題，但是對普通應用AR28系列路由器會自動分片，不會影響業務。測試發現在client上ping大包的時候，如果不設置不允許分片，業務正常。看來客戶應用中做了不允許分片的設置或其它原因mtu協商錯誤。更改路由器接口mtu爲1500-8＝1492以後，業務正常。
2、更改接口mtu以後，其它部分業務還不正常。分析原因是tcp mss值的問題。減小tcp mss值8字節1460-8＝1452，但是還有部分業務不正常。詢問軟件集成商，得到答覆部分軟件中使用了加密技術。而且不同的應用加密強度不同。
3、逐步調整路由器接口的tcp mss值，減到到1200以後，所有業務測試通過。
命令說明：
1、mtu命令用來設置以太網接口的MTU（最大傳輸單元），undo mtu命令用來恢復MTU的缺省值。缺省的MTU爲1500。使用mtu命令改變接口最大傳輸單元MTU後，需要先對接口執行shutdown命令，再執行undo shutdown命令將接口重啓，以保證設置的MTU生效。
2、tcp mss命令用來配置TCP報文分片，undo tcp mss命令用來取消TCP報文分片。
個人總結：
MTU=MSS+IP header+TCP header+鏈路層開銷+加密報文頭（某些程序加密強度不一樣）
MTU，對UDP和TCP報文都檢測，當超過時，如果報文DF=0 ，就進行分段，如果DF=1，就丟棄，同時返回RFC 792定義的ICMP Type3 Code 4（ICMP Destination Unreachable-Fragmentation Needed and DF Set）或 RFC 1191定義的ICMP包（包含轉發失敗鏈路的MTU），主機收到後會調節MSS以適應，後續包不會分片就可進行傳輸。如果兩端之間某Router配置了ACL ，deny掉所有的ICMP，那就無法收到咯。
MSS其實就是TCP報文payload大小。一般的應用軟件，當客戶端和服務器端在建立TCP連接的時候需要根據實際傳輸的報文大小來協商TCP的窗口大小MSS。Tcp連接成功後會進行兩次滑動窗口的協商,一次是pc與server，一次是與網關，然後在兩次協商裏選擇一個較小的值作爲窗口來發送報文。
當協商出來的MSS比較大時，加上IP header+TCP header+鏈路層開銷+加密報文頭後，就有可能大於MTU，當DF=1時，就會丟棄掉。
正如 所說：“對於UDP協議而言，這個協議本身是無連接的協議，對數據包的到達順序以及是否正確到達不甚關心，所以一般UDP應用對分片沒有特殊要求。”所以在路由器上進行ip tcp mss命令只對tcp packet檢測就夠了。
再提供一個案例：MSN是使用https方式登陸的，有時會有突發大報文，而且DF位是設置爲1的。雖然目前大部分出現的故障現象都是：不能發送附件；不能打開網頁等。都是在PPPoE中發生的。但就算源和目的網絡的MTU都是1500，但是由於中間經過的節點鏈路可能存在不同，可能少於1500。或者在傳輸過程中的某個路由器設置了較小的MTU。而往往配置路由器或交換機時，習慣禁止了所有的ICMP信息，這樣的話那路由器就無法返回ICMP 3/4的包給源主機了。 RFC 2923 （TCP Problems with Path MTU Discovery）。
所以，有時候出現的故障，不止要調試MTU值，還要調試MSS值，才能使所有應用正常
其實碰到此問題時，最好是藉助Sniffer抓包分析（不過奇怪，銳捷NBR1000無法抓到ICMP Type 3 Code 4的包，所以無法抓包提供分析圖，好可惜！是路由器不支持還是其他原因，以後有機會考證）
附：Sniffer抓包協助理解分片過程以及DF
上圖是：Ping –l 2000 [url]www.163.com[/url]
首先看IP header，More fragments位爲1，向對方通告此數據包爲多幀發送（分段），total lengt=1300bytes（1280bytes+IP報頭20bytes）。再看ICMP處，可以看到分了兩個包，大小分別爲1280bytes和728bytes，2008 bytes of reassembled data指明重組後的數據爲2008bytes（icmp包頭8bytes，數據2000bytes）。然後看DLC部分，指明瞭以太類型0800（IP），幀大小爲1314bytes（ICMP的1280bytes+IP報頭20bytes+幀14bytes）
再接着看下一個幀。首先看到DLC部分寫着了幀大小爲762bytes，IP部分，continuation of frame 17，第17個幀的後續。Fragment offset 分段偏移量爲1280bytes（第一個包的大小）。至此，第一個icmp echo包全部發送完畢。
ping –f –l 1200 [url]www.163.com[/url]
-f命令：將數據報DF（don’t fragment）位設置爲1（不能分段）
本文出自 “我是木頭” 博客，請務必保留此出處http://infotech.blog.51cto.com/391844/123859