Linux系統下修改傳輸單元最大值MTU的方法

傳輸單元最大值（Maximum Transmission Unit，MTU）是指一種通訊協定的某一層上面所能通過的最大資料報大小（以位元組為單位）。傳輸單元最大值這個參數通常與通訊介面有關（網路介面卡、串口等）。

網際網路協議允許IP分區，這樣就可以將資料報分成足夠小的片段以通過那些傳輸單元最大值小於該資料報原始大小的鏈路了。這一分區過程發生在IP層（OSI模型的第三層，即網路層），它使用的是將分組發送到鏈路上的網路介面的傳輸單元最大值的值。原始分組的分區都被加上了標記，這樣目的主機的IP層就能將分組重組成原始的資料報了。
在網際網路協議中，一條網際網路傳輸路徑的“路徑傳輸單元最大值”被定義為從源地址到目的地址所經過“路徑”上的所有IP跳的傳輸單元最大值的最小值。或者從另外一個角度來看，就是無需進一步分區就能穿過這條“路徑”的傳輸單元最大值的最大值。
RFC 1191描述了“路徑傳輸單元最大值探索方法”，這是一種確定兩個IP主機之間路徑傳輸單元最大值的技術，其目的是為了避免IP分區。在這項技術中，源地址將資料報的DF（Don't Fragment，不要分區）位置位，再逐漸增大發送的資料報的大小——路徑上任何需要將分組進行分區的裝置都會將這種資料報丟棄並返回一個“資料報過大”的ICMP響應到源地址——這樣，源主機就“學習”到了不用進行分區就能通過這條路徑的最大的傳輸單元最大值了。
不幸的是，越來越多的網路封殺了ICMP的傳輸（譬如說為了防範DOS攻擊）——這使得路徑傳輸單元最大值探索方法不能正常工作，其常見表現就是一個串連在低資料流量的情況下可以正常工作，但一旦有大量資料同時發送，就會立即掛起（例如在使用IRC的時候，客戶會發現在發送了一個禁止IP欺騙的ping之後就得不到任何響應了，這是因為該串連被大量的歡迎訊息堵塞了）。而且，在一個使用網際網路協議的網路中，從源地址到目的地址的“路徑”常常會為了響應各種各樣的事件（負載平衡、擁塞、斷電等等）而被動態地修改——這可能導致路徑傳輸單元最大值在傳輸過程中發生改變——有時甚至是反覆的改變。其結果是，在主機尋找新的可以安全工作的傳輸單元最大值的同時，更多的分組被丟失掉了。
對於時下大多數使用乙太網路的區域網路來說，傳輸單元最大值的值是1500位元組。但是像PPPoE這樣的系統會減小這個數值，這就使得在使用傳輸單元最大值探索方法時可能會產生這樣的結果：一些處於配置不當的防火牆之後的網站變得不可達了。對於這種情況，還是可能找到變通的方法的，但這取決於你控制的是網路的哪一部分。這些方法包括改變用來在防火牆一端建立TCP串連的第一個分組的MSS（Maximum  Segment Size，最大分段大小）。
對於一些支援老版本乙太網路協議的IBM系統（例如XSeries），可能只有在把傳輸單元最大值設為1492之後才能在當下常見的區域網路上進行運作。

MTU的修改方法如下：

1、ifconfig命令修改

[/code]
ifconfig ${Interface} mtu ${SIZE} up
ifconfig eth1 mtu 9000 up

[/code]
這個是最通用的方法，對所有的linux 發行版本都有效。缺點就是重啟後失效，需要在開機項中載入。

2、修改設定檔

CentOS / RHEL / Fedora Linux下

代碼如下:
# vi /etc/sysconfig/network-scripts/ifcfg-eth0
#增加如下內容
MTU="9000"
#儲存後重啟網卡生效
# service network restart
#啟用IPv6地址的，修改IPv6 mtu的參數為
IPV6_MTU="1280"
Debian / Ubuntu Linux下

代碼如下:
# vi /etc/network/interfaces
#增加如下值
mtu 9000
#儲存後，重啟網路生效
# /etc/init.d/networking restart
3、為什麼MTU最大值為9000位元組

從理論上計算，4 bytes的CRC最大支援12000 bytes大小的位元組，超過了就沒有辦法檢查了。另外還有其他一些協議如NFS等的限制。

最後需要注意的是，在經過交換網路裝置時，僅僅修改主機端的MTU值是不行的，還需要交換網路裝置上開啟jumbo frames功能。

4、MTU測試

使用ping命令，-l 指定包大小，-f 選項為通知作業系統不能私自更改該資料包大小

使用英文作業系統時的提示為：Packet needs to be fragmented but DF set