先學習理解一下幀的封裝格式：
需要注意的是，區別兩種幀封裝格式：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 VPN;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 VPN技術，增加了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 VPN;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 VPN技術，增加了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