目錄
基于RoCE的應用程序的MTU注意事項
探測網絡中的MTU設置
概要
原文
MTU測試結果
DOC:
CentOS安裝tshark抓包工具
基于RoCE的應用程序的MTU注意事項
原文:https://support.mellanox.com/s/article/MLNX2-117-1682kn
InfiniBand協議最大傳輸單元(MTU)定義了幾個固定大小的MTU:256、512、1024、2048或4096字節。
使用在以太網上運行的RDMA的基于RoCE的應用程序應考慮到RoCE MTU小于以太網MTU(Ethernet MTU)。 (通常默認值為1500)。
驅動程序從上面的列表中選擇比Ethernet MTU 小的最大的那個值作為最大的“active” MTU。(并考慮了RoCE傳輸頭和CRC字段)。
例如:
對于默認的 Ethernet MTU (1500字節),RoCE將使用1024(作為active_mtu)
而對于Ethernet MTU = 4200,RoCE將使用4096作為“active MTU”。
可以使用“ ibv_devinfo”檢查“ active_mtu”值。
通信兩端之間用RoCE協議交換“ active_mtu”并進行協商。將使用最小的MTU。
(RoCE protocol exchanges "active_mtu" values and negotiates it between both ends. The minimum MTU will be used.)
檢查端口MTU:
[root@rdma59 ~]# ?ifconfig ens2f0
ens2f0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> ?mtu 1500
? ? ? ? inet 172.17.31.59 ?netmask 255.255.255.0 ?broadcast 172.17.31.255
? ? ? ? inet6 fe80::b696:91ff:fea5:9a70 ?prefixlen 64 ?scopeid 0x20<link>
? ? ? ? ether b4:96:91:a5:9a:70 ?txqueuelen 1000 ?(Ethernet)
? ? ? ? RX packets 6508 ?bytes 954004 (931.6 KiB)
? ? ? ? RX errors 0 ?dropped 477 ?overruns 0 ?frame 0
? ? ? ? TX packets 4736 ?bytes 361557 (353.0 KiB)
? ? ? ? TX errors 0 ?dropped 0 overruns 0 ?carrier 0 ?collisions 0
檢查InfiniBand MTU:
ibv_devinfo 顯示所有RDMA網口的簡略信息
ibv_devinfo -v顯示所有RDMA網口的所有信息
ibv_devinfo -d mlx5_0顯示所有mlx5_0的簡略信息
ibv_devinfo ?-v -d mlx5_0顯示所有mlx5_0的所有信息
更多:ibv_devinfo ?–h
[root@rdma63 ~]# ibv_devinfo -d mlx5_0
hca_id: mlx5_0
? ? ? ? transport: ? ? ? ? ? ? ? ? ? ? ?InfiniBand (0)
? ? ? ? fw_ver: ? ? ? ? ? ? ? ? ? ? ? ? 16.29.1016
? ? ? ? node_guid: ? ? ? ? ? ? ? ? ? ? ?9803:9b03:009a:2b3a
? ? ? ? sys_image_guid: ? ? ? ? ? ? ? ? 9803:9b03:009a:2b3a
? ? ? ? vendor_id: ? ? ? ? ? ? ? ? ? ? ?0x02c9
? ? ? ? vendor_part_id: ? ? ? ? ? ? ? ? 4119
? ? ? ? hw_ver: ? ? ? ? ? ? ? ? ? ? ? ? 0x0
? ? ? ? board_id: ? ? ? ? ? ? ? ? ? ? ? MT_0000000010
? ? ? ? phys_port_cnt: ? ? ? ? ? ? ? ? ?1
? ? ? ? Device ports:
? ? ? ? ? ? ? ? port: ? 1
? ? ? ? ? ? ? ? ? ? ? ? state: ? ? ? ? ? ? ? ? ?PORT_ACTIVE (4)
? ? ? ? ? ? ? ? ? ? ? ? max_mtu: ? ? ? ? ? ? ? ?4096 (5)
? ? ? ? ? ? ? ? ? ? ? ? active_mtu: ? ? ? ? ? ? 1024 (3)
? ? ? ? ? ? ? ? ? ? ? ? sm_lid: ? ? ? ? ? ? ? ? 0
? ? ? ? ? ? ? ? ? ? ? ? port_lid: ? ? ? ? ? ? ? 0
? ? ? ? ? ? ? ? ? ? ? ? port_lmc: ? ? ? ? ? ? ? 0x00
? ? ? ? ? ? ? ? ? ? ? ? link_layer: ? ? ? ? ? ? Ethernet
對于使用大IO的應用程序,建議擴大MTU。
注意:如果您更改端口MTU,則所有鏈路上的網絡元素(交換機和路由器)中的MTU也應該一同修改。
一旦你修改了端口(port)的MTU后,InfiniBand的 active MTU將自動調整為適合該MTU的最大尺寸。
例如,一旦將端口MTU設置為4200,active_mtu將更改為4096。
但是,最好不要將端口MTU配置為9000,因為這會浪費內存。
建議的MTU值如下:
想讓active MTU為4096-將端口MTU配置為4200
想讓active MTU為2048-將端口MTU配置為2200
# ifconfig eth2 mtu 4200
# ibv_devinfo -d mlx4_0
hca_id: mlx4_0
transport: InfiniBand (0)
fw_ver: 2.31.5050
node_guid: f452:1403:0017:1b80
sys_image_guid: f452:1403:0017:1b83
vendor_id: 0x02c9
vendor_part_id: 4103
hw_ver: 0x0
board_id: MT_1090111019
phys_port_cnt: 2
port: 1
state: PORT_ACTIVE (4)
max_mtu: 4096 (5)
active_mtu: 4096 (5)
sm_lid: 0
port_lid: 0
port_lmc: 0x00
link_layer: Ethernet
port: 2
state: PORT_DOWN (1)
max_mtu: 4096 (5)
active_mtu: 4096 (5)
sm_lid: 0
port_lid: 0
port_lmc: 0x00
link_layer: InfiniBand
#
其他文章:
IP over Infiband MTU size in non homogeneous environments - IBM InfiniBand?
https://www.ibm.com/support/pages/ip-over-infiband-mtu-size-non-homogeneous-environments-ibm-infiniband
Maximum Transmit Unit (MTU) Configuration
https://www.supermicro.org.cn/wdl/driver/InfiniBand/VMWare/ESX_Server_5.X/Mellanox_IB_OFED_Driver_for_VMware_vSphere_User_Manual_Rev_1_8_0.pdf
探測網絡中的MTU設置
概要
1、MTU(Maximum Transmission Unit) 大小指的是一個以太幀(Ethernet Frame)能攜帶的最大數據部分(payload)的大小, 當MTU值設置為9000 Bytes的時候也叫做巨型幀(Jumbo Frame)
2、一般情況下網卡的MTU大小是1500(最大可配置到9000),(增加)數據的傳輸效率,可以通過增加MTU只來實現,MTU的增加即每幀(Frame)傳輸的數據量就會更大。
3、網絡中的所有節點必須同時增大MTU,網絡中小MTU的節點遇到上家發來的大于MTU的Frame(且沒有切分標記),則直接丟棄。
PMTUD方法:
tracepath -n 192.169.31.54
https://networkengineering.stackexchange.com/questions/13417/exactly-when-is-pmtud-performed-path-mtu-discovery
原文
原文:https://www.jianshu.com/p/ee9c32b18005
MTU(Maximum Transmission Unit) 大小指的是一個以太幀(Ethernet Frame)能攜帶的最大數據部分(payload)的大小, 當MTU值設置為9000 Bytes的時候也叫做巨型幀(Jumbo Frame):
以太幀(Ethernet Frame)
802.3 Ethernet MTU
+-------------+------------+-----------------+---------+----------------+
| Dest MAC(6) | Src MAC(6) | Eth Type/Len(2) | Payload | CRC Trailer(4) |
+-------------+------------+-----------------+---------+----------------+
所以說, 當使用 Ethernet 介質時確定只能傳最大 1518 字節的幀后, 減去 18 字節的 L2 頭和尾, 留給 IP 層的就只有 1500 字節了.
一般情況下網卡的MTU大小是1500(最大可配置到9000),然后為了在高性能的網絡環境下(增加)數據的傳輸效率,可以通過增加MTU只來實現,換句話說通過MTU的增加,每幀(Frame)傳輸的數據量就會更大。 這就好比用面包車運輸對比用大貨車運輸的區別。
然而要實現大MTU需要網絡里的每個設備都必須支持巨型幀大MTU,包括發送主機,目標主機以及網絡中的路由器等。
本文主要是記錄如何探測網絡中的MTU設置以及錯誤配置MTU帶來的影響。
為了探測兩個不同實驗室的機器之間的網絡是否支持Jumbo Frame, 我從實驗室A的Centos主機(client) 發送ping命令到實驗室B的服務器(server)。
首先檢查client的MTU配置:
[root@centos ~]# ifconfig eno16777736
eno16777736: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> ?mtu 1500
?
可以看到默認的MTU值為1500, 此時我們發送一個大小為100B的ICMP數據包到目標server.
[root@centos ?~]# ping -s 100 -c 1 10.245.194.61
PING 10.245.194.61 (10.245.194.61) 100(128) bytes of data.
108 bytes from 10.245.194.61: icmp_seq=1 ttl=50 time=23.0 ms
可以看到小于MTU的數據包(128 = 100 + 20(ip header) + 8(icmp header))成功地發出并得到服務器回應, 接著我們增大包的大小到2000,超過了1500的MTU值, 同樣數據ping成功ping發送并得到回應:
[root@centos ~]# ping -s 2000 -c 1 10.245.194.61
PING 10.245.194.61 (10.245.194.61) 2000(2028) bytes of data.
2008 bytes from 10.245.194.61: icmp_seq=1 ttl=50 time=24.2 ms
?
wireshark抓包
或許這里會有疑問,不是說最大只能發送1500字節的包嗎? 為何2000字節也能成功發出?為了解答這個問題,我們通過wireshark抓個包來看看怎么回事
[root@centos ~]# tcpdump -i eno16777736 -s 50 -w mtu_1500.pcap
[root@centos ~]# tshark -t ud -P -O icmp,ip -Y "ip.addr==10.245.194.61" -r mtu_1500.pcap000>>mtu_1500.txt
(參數解釋:
https://www.cnblogs.com/liun1994/p/6142505.html
-t: -t a|ad|d|dd|e|r|u|ud 設置解碼結果的時間格式。“ad”表示帶日期的絕對時間,“a”表示不帶日期的絕對時間,“r”表示從第一個包到現在的相對時間,“d”表示兩個相鄰包之間的增量時間(delta)。 -u: s|hms 格式化輸出秒;
-P: 即使將解碼結果寫入文件中,也打印包的概要信息;
-O: -O <protocols>,只顯示此選項指定的協議的詳細信息。
-Y: -Y <display filter>,使用讀取過濾器的語法,在單次分析中可以代替-R選項;
-r: -r <infile> 設置讀取本地文件
)
打開mtu_1500.txt,找到ICMP包:
icmp 幀
?
可以看到,即使我們指定的數據包大小是2000字節,但是IP層會根據當前MTU的設置對超過的ICMP數據進行分片(Fragmentation),以滿足發送方的MTU設置要求。那么接收方是如何判定當前IP包是否被分片過?可以通過More Fragments 標志位(上圖93行)和Flags字段(上圖第90行)的值來判斷,, 當接收方的IP層收到最后一個切片后(More Fragments: Not set),就會組裝收到的所有切片包然后交給上層協議, 這里我們停下來想一想,IP層如何保證切片重組的順序?其實很簡單,IP包里有個Fragment offset屬性,接收方可根據此屬性的順序重組切片, 此列中,理論上應當只有兩個切片(1500 + 500 =2000), 所以接下來的一個Frame就是最后一個IP 切片:
第二個Fragment
?
上圖第二個切片也是最后一個,其IP包的大小為548字節,也就是著總的數據傳輸量為2048(1500+548)字節,其中1個icmp頭(8B), 2個ip頭(20B+20B)和icmp的數據部分(2000). 所以可以看到,即便發送數據量超過了MTU的值,在IP層也會進行切片來適配所設置的MTU大小。
那么將發送發的MTU設置為9000字節啟用巨型幀的話,會出現什么結果呢?
[root@centos ~]# ifconfig eno16777736 mtu 9000 up
[root@centos ~]# ifconfig eno16777736
eno16777736: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> ?mtu 9000
設置好巨型幀以后,再來ping一個大數據包看看這次結果有什么不一樣。
[root@centos ~]# ping -s 2000 -c 1 10.245.194.61
PING 10.245.194.61 (10.245.194.61) 2000(2028) bytes of data.
?
--- 10.245.194.61 ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 0ms
額。。。 增大了MTU之后,反而ping不成功!這是怎么回事??? 在看看網絡包:
ping with jumbo frame
?
嗯,沒問題,MTU設置應該是成功的,這次IP層沒有分片,發送的數據也是2000字節,但是為什么服務器沒有回應呢?
其實,這恰恰說明了此網絡是不支持巨型幀的,只要網絡里有一個轉發節點的MTU值不是9000B并且發送方要求不分片(第170行, DF: Set)的情況下,轉發節點會丟棄該報文。這也就是為什么會返回超時丟包的錯誤了。
簡單來說,當一個轉發點收到一個IP報文以后,先檢查該報文的大小是否超過自己的MTU值,如果超過,再檢查是否設置了DF標志(Don't Fragment), 如果設置,此報文將會被直接丟棄,如果沒有設置DF,那么該節點會對報文進行切片后再轉發到下一個路由節點。
作者:hynoor
鏈接:https://www.jianshu.com/p/ee9c32b18005
?
MTU測試結果
谷歌搜索 MTU Test / Great Jumbo Frames /圖片搜索
《The Great Jumbo Frames Debate》https://longwhiteclouds.com/2013/09/10/the-great-jumbo-frames-debate/
《Jumbo Frames on vSphere 5》https://longwhiteclouds.com/2012/02/20/jumbo-frames-on-vsphere-5/
《Hardware Offloads - Test results》https://docs.openstack.org/performance-docs/latest/test_results/hardware_features/hardware_offloads/test_results.html
《Large MTUs and Internet Performance》http://irep.ntu.ac.uk/id/eprint/13183/1/221075_PubSub2797_Lee_K.pdf
《AWS Performance Test Results》https://docs.aviatrix.com/HowTos/insane_mode_perf.html
《Jumbo Frames for RAC Interconnect》https://blogs.oracle.com/exadata/jumbo-frames-for-rac-interconnect-v2
谷歌搜索 “mtu latency”,圖片
DOC:
基于RoCE的應用程序的MTU注意事項
InfiniBand自動選擇的MTU與端口MTU有關
?
InfiniBand協議最大傳輸單元(MTU)定義了幾個固定大小的MTU:256、512、1024、2048或4096字節。
基于RoCE的應用程序應考慮到RoCE MTU小于以太網MTU(Ethernet MTU)。 (通常默認值為1500)。
驅動程序從上面的列表中選擇比Ethernet MTU 小的最大的那個值作為active_mtu(即實際使用的MTU)。(并考慮了RoCE傳輸頭和CRC字段)。
例如:
對于默認的 Ethernet MTU (1500字節),RoCE將使用1024(作為active_mtu)
而對于Ethernet MTU = 4200,RoCE將使用4096作為active_mtu。
通信兩端之間用RoCE協議交換“ active_mtu”并進行協商,將使用最小的MTU。
(Mellanox :RoCE protocol exchanges "active_mtu" values and negotiates it between both ends. The minimum MTU will be used.)
(IBM:When an SMC-R link is initially established between two peer hosts, the MTU size is exchanged and negotiated to the lowest value for both hosts. The negotiated MTU size must account for transport headers and cyclic redundancy check (CRC) information that is used by the underlying RoCE protocols.)
查看端口MTU和InfiniBand MTU
檢查端口MTU:
?
檢查端口MTU:
netstat -i
也可以:
基于RoCE的應用程序的MTU注意事項
InfiniBand自動選擇的MTU與端口MTU有關
?
InfiniBand協議最大傳輸單元(MTU)定義了幾個固定大小的MTU:256、512、1024、2048或4096字節。
基于RoCE的應用程序應考慮到RoCE MTU小于以太網MTU(Ethernet MTU)。 (通常默認值為1500)。
驅動程序從上面的列表中選擇比Ethernet MTU 小的最大的那個值作為active_mtu(即實際使用的MTU)。(并考慮了RoCE傳輸頭和CRC字段)。
例如:
對于默認的 Ethernet MTU (1500字節),RoCE將使用1024(作為active_mtu)
而對于Ethernet MTU = 4200,RoCE將使用4096作為active_mtu。
通信兩端之間用RoCE協議交換“ active_mtu”并進行協商,將使用最小的MTU。
(Mellanox :RoCE protocol exchanges "active_mtu" values and negotiates it between both ends. The minimum MTU will be used.)
(IBM:When an SMC-R link is initially established between two peer hosts, the MTU size is exchanged and negotiated to the lowest value for both hosts. The negotiated MTU size must account for transport headers and cyclic redundancy check (CRC) information that is used by the underlying RoCE protocols.)
查看端口MTU和InfiniBand MTU
檢查端口MTU:
?
檢查端口MTU:
netstat -i
也可以:
[root@rdma59 ~]# ?ifconfig ens2f0
ens2f0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> ?mtu 1500
? ? ? ? inet 172.17.31.59 ?netmask 255.255.255.0 ?broadcast 172.17.31.255
? ? ? ? inet6 fe80::b696:91ff:fea5:9a70 ?prefixlen 64 ?scopeid 0x20<link>
? ? ? ? ether b4:96:91:a5:9a:70 ?txqueuelen 1000 ?(Ethernet)
? ? ? ? RX packets 6508 ?bytes 954004 (931.6 KiB)
? ? ? ? RX errors 0 ?dropped 477 ?overruns 0 ?frame 0
? ? ? ? TX packets 4736 ?bytes 361557 (353.0 KiB)
? ? ? ? TX errors 0 ?dropped 0 overruns 0 ?carrier 0 ?collisions 0
檢查InfiniBand MTU
可以使用“ ibv_devinfo”檢查“ active_mtu”值。
ibv_devinfo 顯示所有RDMA網口的簡略信息
ibv_devinfo -v顯示所有RDMA網口的所有信息
ibv_devinfo -d mlx5_0顯示網口mlx5_0的簡略信息
ibv_devinfo ?-v -d mlx5_0顯示網口mlx5_0的所有信息
更多:ibv_devinfo ?–h
[root@rdma63 ~]# ibv_devinfo -d mlx5_0
hca_id: mlx5_0
? ? ? ? transport: ? ? ? ? ? ? ? ? ? ? ?InfiniBand (0)
? ? ? ? fw_ver: ? ? ? ? ? ? ? ? ? ? ? ? 16.29.1016
? ? ? ? node_guid: ? ? ? ? ? ? ? ? ? ? ?9803:9b03:009a:2b3a
? ? ? ? sys_image_guid: ? ? ? ? ? ? ? ? 9803:9b03:009a:2b3a
? ? ? ? vendor_id: ? ? ? ? ? ? ? ? ? ? ?0x02c9
? ? ? ? vendor_part_id: ? ? ? ? ? ? ? ? 4119
? ? ? ? hw_ver: ? ? ? ? ? ? ? ? ? ? ? ? 0x0
? ? ? ? board_id: ? ? ? ? ? ? ? ? ? ? ? MT_0000000010
? ? ? ? phys_port_cnt: ? ? ? ? ? ? ? ? ?1
? ? ? ? Device ports:
? ? ? ? ? ? ? ? port: ? 1
? ? ? ? ? ? ? ? ? ? ? ? state: ? ? ? ? ? ? ? ? ?PORT_ACTIVE (4)
? ? ? ? ? ? ? ? ? ? ? ? max_mtu: ? ? ? ? ? ? ? ?4096 (5)
? ? ? ? ? ? ? ? ? ? ? ? active_mtu: ? ? ? ? ? ? 1024 (3)
? ? ? ? ? ? ? ? ? ? ? ? sm_lid: ? ? ? ? ? ? ? ? 0
? ? ? ? ? ? ? ? ? ? ? ? port_lid: ? ? ? ? ? ? ? 0
? ? ? ? ? ? ? ? ? ? ? ? port_lmc: ? ? ? ? ? ? ? 0x00
? ? ? ? ? ? ? ? ? ? ? ? link_layer: ? ? ? ? ? ? Ethernet
max_mtu: ? infiniband網口支持的最大MTU ? ? ? ??
active_mtu: ?infiniband網口實際使用的MTU ? ?
MTU設置建議和注意事項
MTU設置建議
對于使用大IO的應用程序,建議擴大MTU。
注意事項
注意:如果您更改端口MTU,則所有鏈路上的網絡元素(交換機和路由器)中的MTU也應該一同修改,否則大MTU端口發出的大幀遇到小MTU端口會發生數據丟棄,且沒有反饋,問題難以排查。
(MTU:最大傳輸單元,最大接收單元MRU,即MTU >MRU時,接收方就丟棄數據)
一旦你修改了端口(port)的MTU后,InfiniBand的 active MTU將自動調整為適合該MTU的最大尺寸。
例如,一旦將端口MTU設置為4200,active_mtu將更改為4096。
但是,最好不要將端口MTU配置為9000,因為這會浪費內存。
建議的MTU值如下:
想讓active MTU為4096-將端口MTU配置為4200
想讓active MTU為2048-將端口MTU配置為2200
# ifconfig eth2 mtu 4200
# ibv_devinfo -d mlx4_0
hca_id: mlx4_0
transport: InfiniBand (0)
fw_ver: 2.31.5050
node_guid: f452:1403:0017:1b80
sys_image_guid: f452:1403:0017:1b83
vendor_id: 0x02c9
vendor_part_id: 4103
hw_ver: 0x0
board_id: MT_1090111019
phys_port_cnt: 2
port: 1
state: PORT_ACTIVE (4)
max_mtu: 4096 (5)
active_mtu: 4096 (5)
sm_lid: 0
port_lid: 0
port_lmc: 0x00
link_layer: Ethernet
port: 2
state: PORT_DOWN (1)
max_mtu: 4096 (5)
active_mtu: 4096 (5)
sm_lid: 0
port_lid: 0
port_lmc: 0x00
link_layer: InfiniBand
#
確定路徑的MTU
原理
用來確定到達目的地的路徑的最大傳輸單元(MTU)的大小的策略/技術叫PMTUD(路徑MTU發現)
[路徑MTU發現] (PMTUD)通過在IP報頭中設置不分片DF(Don't Fragment)標志來探測路徑中的MTU值。一旦DF位置1,將不允許中間設備對該報文進行分片,那么在遇到IP報文長度超過中間設備轉發接口的MTU值時,該IP報文將會被中間設備丟棄。在丟棄之后,中間設備會向發送方發送ICMP差錯報文。
(注意:如果通信路徑中間有防火墻阻止了ICMP錯誤消息,那么會阻止PMTUD正常執行。)
http://www.vants.org/?post=109
檢測
?
(ping的參數解釋,可以執行 man ping 查看)
在Windows主機上,還可以使用“-f” ping參數將“不分段(DF)”位設置為1。
C:\ Users \ ScottHogg> ping 192.168.10.1 -l 1500 -f
在Linux上,命令為:
RedHat# ping -s 1500 -M do 192.168.10.1
通過改變ping包的大小,來回逼近的方法確定MTU
環境測試實踐結果
intel集群的172.17.31.55、172.17.31.59
?
在intel集群的172.17.31.55、172.17.31.59上測試:
只要兩個網口的MTU不一致,使用ping測試傳輸大于一端MTU的數據包就會失敗。
例如:
172.17.31.55 設置eth的MTU為4200(ib的MTU自動為4096):
ifconfig ens2f0 mtu 4200
172.17.31.59 的eth的MTU默認1500
在172.17.31.55上向172.17.31.59 ping 200 byte的包會成功,ping 2000 byte的包會失敗:
ping -s 200 -c 1 172.17.31.59 ? ?#成功
ping -s 2000 -c 1 172.17.31.59 ? #失敗
反過來也一樣。
172.17.31.55 、172.17.31.59都設置eth的MTU為4200(ib的MTU自動為4096):
ping -s 2000 -c 1 172.17.31.59 ? #成功
windows檢查MTU size
?
ping ?-f -l 2000 182.200.31.59
-l size ? ? ? ?發送緩沖區大小。
-f ? ? ? ? ? ?在數據包中設置“不分段”標志(僅適用于 IPv4)
返回中提示需要拆分,說明MTU 小于2000
PS C:\Users\l24514> ping 182.200.31.59 -l 1500 -f
正在 Ping 182.200.31.59 具有 1500 字節的數據:
來自 182.200.31.254 的回復: 需要拆分數據包但是設置 DF。
來自 182.200.31.254 的回復: 需要拆分數據包但是設置 DF。
來自 182.200.31.254 的回復: 需要拆分數據包但是設置 DF。
來自 182.200.31.254 的回復: 需要拆分數據包但是設置 DF。
設置方法
設置:
# ifconfig eth2 mtu 4200
查看:
# ibv_devinfo -d mlx4_0
(eth2網口對應的 device是mlx4_0)
為什么以太網mtu默認值為1500?
https://www.zhihu.com/question/21524257/answer/118266374
理想狀態幀越大傳輸效率越高。(MTU越大允許的幀越大)
MTU過大引起的副作用:
傳送一個數據包的延遲也越大
?
對于上行鏈路,會有多個計算機的數據幀排隊等待傳輸,如果某個數據幀太大的話,那么其他數據幀等待的時間就會加長,導致體驗變差。
需要更大的緩存區(內存)
網絡I/O控制器需要從Host端主存中的緩沖區中取數據,緩沖區的大小是有限制的,Host主存資源有限,一般無法分配太大的緩沖區,只能將數據碎片化,一小份一小份的放置,并用環形隊列追蹤組織起來。
并且MTU越大,數據包中 bit位發生錯誤的概率也越大
?
如果一次傳送太大量的數據,一旦該數據中有一小部分被干擾,那么接收方的數據校驗算法由于無法判斷具體是哪里產生了錯誤以及如何修復錯誤,所以只能將這份數據全部丟棄,并通知發送方重傳,這極度浪費了網絡帶寬資源
所以折衷的長度:1518 byte ! 對應的IP packet 就是 1500 byte:
https://www.zhihu.com/question/21524257/answer/118266374
其他相關內容
Path MTU Discovery (PMTUD)?
PMTUD:
路徑MTU發現(PMTUD),用于確定計算機網絡中使用互聯網協議(IP)主機間的最大傳輸單元(MTU)的大小,通常目標是避免IP分片。PMTUD原定應用在IPv4的路由器上,然而所有現代操作系統都是在終端應用它。在IPv6中,這個方法只應用在終端之間的會話。對于IPv4包,路徑MTU發現通過在傳出包的IP頭中設置Don't Fragment (DF)標志位來工作。然后,任何路徑上MTU小于數據包的設備都將丟棄它,并返回包含其MTU過大的ICMPv4(類型3、代碼4)數據包,從而允許源主機適當地減小其路徑MTU。 [1]?
探測網絡中的MTU設置 實踐
?
《探測網絡中的MTU設置》: https://www.jianshu.com/p/ee9c32b18005
概要:
1、MTU(Maximum Transmission Unit) 大小指的是一個以太幀(Ethernet Frame)能攜帶的最大數據部分(payload)的大小, 當MTU值設置為9000 Bytes的時候也叫做巨型幀(Jumbo Frame)
2、一般情況下網卡的MTU大小是1500(最大可配置到9000),(增加)數據的傳輸效率,可以通過增加MTU只來實現,MTU的增加即每幀(Frame)傳輸的數據量就會更大。
3、網絡中的所有節點必須同時增大MTU,網絡中小MTU的節點遇到上家發來的大于MTU的Frame(且沒有切分標記),則直接丟棄。
MTU Size Issues
https://www.networkworld.com/article/2224654/mtu-size-issues.html
RDMA 信息常用命令
查看RDMA device列表
?
[root@rdma63 tcpdump]# ibv_devices
? ? device ? ? ? ? ? ? ? ? node GUID
? ? ------ ? ? ? ? ? ? ?----------------
? ? mlx5_1 ? ? ? ? ? ? ?98039b03009a4296
? ? mlx5_0 ? ? ? ? ? ? ?98039b03009a2b3a
查看device信息
?
[root@rdma63 tcpdump]# ibv_devinfo -v -d mlx5_1
hca_id: mlx5_1
? ? ? ? transport: ? ? ? ? ? ? ? ? ? ? ?InfiniBand (0)
? ? ? ? fw_ver: ? ? ? ? ? ? ? ? ? ? ? ? 16.29.1016
? ? ? ? node_guid: ? ? ? ? ? ? ? ? ? ? ?9803:9b03:009a:4296
? ? ? ? sys_image_guid: ? ? ? ? ? ? ? ? 9803:9b03:009a:4296
? ? ? ? vendor_id: ? ? ? ? ? ? ? ? ? ? ?0x02c9
? ? ? ? vendor_part_id: ? ? ? ? ? ? ? ? 4119
? ? ? ? hw_ver: ? ? ? ? ? ? ? ? ? ? ? ? 0x0
? ? ? ? board_id: ? ? ? ? ? ? ? ? ? ? ? MT_0000000010
? ? ? ? phys_port_cnt: ? ? ? ? ? ? ? ? ?1
? ? ? ? Device ports:
? ? ? ? ? ? ? ? port: ? 1
? ? ? ? ? ? ? ? ? ? ? ? state: ? ? ? ? ? ? ? ? ?PORT_ACTIVE (4)
? ? ? ? ? ? ? ? ? ? ? ? max_mtu: ? ? ? ? ? ? ? ?4096 (5)
? ? ? ? ? ? ? ? ? ? ? ? active_mtu: ? ? ? ? ? ? 1024 (3)
? ? ? ? ? ? ? ? ? ? ? ? sm_lid: ? ? ? ? ? ? ? ? 0
? ? ? ? ? ? ? ? ? ? ? ? port_lid: ? ? ? ? ? ? ? 0
? ? ? ? ? ? ? ? ? ? ? ? port_lmc: ? ? ? ? ? ? ? 0x00
? ? ? ? ? ? ? ? ? ? ? ? link_layer: ? ? ? ? ? ? Ethernet
[root@rdma63 ~]# ibv_devinfo --help
ibv_devinfo: unrecognized option '--help'
Usage: ibv_devinfo ? ? ? ? ? ? print the ca attributes
Options:
? -d, --ib-dev=<dev> ? ? use IB device <dev> (default all devices found)
? -i, --ib-port=<port> ? use port <port> of IB device (default 0: all ports)
? -l, --list ? ? ? ? ? ? print only the IB devices names
? -v, --verbose ? ? ? ? ?print all the attributes of the IB device(s)
查看網口映射關系
?
mellonx:
[root@rdma64 ibdump-master]# ibdev2netdev
mlx5_0 port 1 ==> eth18-0 (Up)
mlx5_1 port 1 ==> ib3b-0 (Up)
intel:
ibv_devices|awk '{system("echo "$1"\"-->\"`ls /sys/class/infiniband/"$1"/device/net`")}'
檢查InfiniBand MTU
可以使用“ ibv_devinfo”檢查“ active_mtu”值。
ibv_devinfo 顯示所有RDMA網口的簡略信息
ibv_devinfo -v顯示所有RDMA網口的所有信息
ibv_devinfo -d mlx5_0顯示網口mlx5_0的簡略信息
ibv_devinfo ?-v -d mlx5_0顯示網口mlx5_0的所有信息
更多:ibv_devinfo ?–h
[root@rdma63 ~]# ibv_devinfo -d mlx5_0
hca_id: mlx5_0
? ? ? ? transport: ? ? ? ? ? ? ? ? ? ? ?InfiniBand (0)
? ? ? ? fw_ver: ? ? ? ? ? ? ? ? ? ? ? ? 16.29.1016
? ? ? ? node_guid: ? ? ? ? ? ? ? ? ? ? ?9803:9b03:009a:2b3a
? ? ? ? sys_image_guid: ? ? ? ? ? ? ? ? 9803:9b03:009a:2b3a
? ? ? ? vendor_id: ? ? ? ? ? ? ? ? ? ? ?0x02c9
? ? ? ? vendor_part_id: ? ? ? ? ? ? ? ? 4119
? ? ? ? hw_ver: ? ? ? ? ? ? ? ? ? ? ? ? 0x0
? ? ? ? board_id: ? ? ? ? ? ? ? ? ? ? ? MT_0000000010
? ? ? ? phys_port_cnt: ? ? ? ? ? ? ? ? ?1
? ? ? ? Device ports:
? ? ? ? ? ? ? ? port: ? 1
? ? ? ? ? ? ? ? ? ? ? ? state: ? ? ? ? ? ? ? ? ?PORT_ACTIVE (4)
? ? ? ? ? ? ? ? ? ? ? ? max_mtu: ? ? ? ? ? ? ? ?4096 (5)
? ? ? ? ? ? ? ? ? ? ? ? active_mtu: ? ? ? ? ? ? 1024 (3)
? ? ? ? ? ? ? ? ? ? ? ? sm_lid: ? ? ? ? ? ? ? ? 0
? ? ? ? ? ? ? ? ? ? ? ? port_lid: ? ? ? ? ? ? ? 0
? ? ? ? ? ? ? ? ? ? ? ? port_lmc: ? ? ? ? ? ? ? 0x00
? ? ? ? ? ? ? ? ? ? ? ? link_layer: ? ? ? ? ? ? Ethernet
max_mtu: ? infiniband網口支持的最大MTU ? ? ? ??
active_mtu: ?infiniband網口實際使用的MTU ? ?
MTU設置建議和注意事項
?
對于使用大IO的應用程序,建議擴大MTU。
注意:如果您更改端口MTU,則所有鏈路上的網絡元素(交換機和路由器)中的MTU也應該一同修改,否則大MTU端口發出的大幀遇到小MTU端口會發生數據丟棄,且沒有反饋,問題難以排查。
(MTU:最大傳輸單元,最大接收單元MRU,即MTU >MRU時,接收方就丟棄數據)
一旦你修改了端口(port)的MTU后,InfiniBand的 active MTU將自動調整為適合該MTU的最大尺寸。
例如,一旦將端口MTU設置為4200,active_mtu將更改為4096。
但是,最好不要將端口MTU配置為9000,因為這會浪費內存。
建議的MTU值如下:
想讓active MTU為4096-將端口MTU配置為4200
想讓active MTU為2048-將端口MTU配置為2200
# ifconfig eth2 mtu 4200
# ibv_devinfo -d mlx4_0
hca_id: mlx4_0
transport: InfiniBand (0)
fw_ver: 2.31.5050
node_guid: f452:1403:0017:1b80
sys_image_guid: f452:1403:0017:1b83
vendor_id: 0x02c9
vendor_part_id: 4103
hw_ver: 0x0
board_id: MT_1090111019
phys_port_cnt: 2
port: 1
state: PORT_ACTIVE (4)
max_mtu: 4096 (5)
active_mtu: 4096 (5)
sm_lid: 0
port_lid: 0
port_lmc: 0x00
link_layer: Ethernet
port: 2
state: PORT_DOWN (1)
max_mtu: 4096 (5)
active_mtu: 4096 (5)
sm_lid: 0
port_lid: 0
port_lmc: 0x00
link_layer: InfiniBand
#
為什么以太網mtu默認值為1500?
https://www.zhihu.com/question/21524257/answer/118266374
理想狀態幀越大傳輸效率越高。(MTU越大允許的幀越大)
MTU過大引起的副作用:
傳送一個數據包的延遲也越大
?
對于上行鏈路,會有多個計算機的數據幀排隊等待傳輸,如果某個數據幀太大的話,那么其他數據幀等待的時間就會加長,導致體驗變差。
需要更大的緩存區(內存)
網絡I/O控制器需要從Host端主存中的緩沖區中取數據,緩沖區的大小是有限制的,Host主存資源有限,一般無法分配太大的緩沖區,只能將數據碎片化,一小份一小份的放置,并用環形隊列追蹤組織起來。
并且MTU越大,數據包中 bit位發生錯誤的概率也越大
?
如果一次傳送太大量的數據,一旦該數據中有一小部分被干擾,那么接收方的數據校驗算法由于無法判斷具體是哪里產生了錯誤以及如何修復錯誤,所以只能將這份數據全部丟棄,并通知發送方重傳,這極度浪費了網絡帶寬資源
所以折衷的長度:1518 byte ! 對應的IP packet 就是 1500 byte:
https://www.zhihu.com/question/21524257/answer/118266374
其他相關內容
Path MTU Discovery (PMTUD)?
PMTUD:
路徑MTU發現(PMTUD),用于確定計算機網絡中使用互聯網協議(IP)主機間的最大傳輸單元(MTU)的大小,通常目標是避免IP分片。PMTUD原定應用在IPv4的路由器上,然而所有現代操作系統都是在終端應用它。在IPv6中,這個方法只應用在終端之間的會話。對于IPv4包,路徑MTU發現通過在傳出包的IP頭中設置Don't Fragment (DF)標志位來工作。然后,任何路徑上MTU小于數據包的設備都將丟棄它,并返回包含其MTU過大的ICMPv4(類型3、代碼4)數據包,從而允許源主機適當地減小其路徑MTU。 [1]?
探測網絡中的MTU設置 實踐
?
《探測網絡中的MTU設置》: https://www.jianshu.com/p/ee9c32b18005
概要:
1、MTU(Maximum Transmission Unit) 大小指的是一個以太幀(Ethernet Frame)能攜帶的最大數據部分(payload)的大小, 當MTU值設置為9000 Bytes的時候也叫做巨型幀(Jumbo Frame)
2、一般情況下網卡的MTU大小是1500(最大可配置到9000),(增加)數據的傳輸效率,可以通過增加MTU只來實現,MTU的增加即每幀(Frame)傳輸的數據量就會更大。
3、網絡中的所有節點必須同時增大MTU,網絡中小MTU的節點遇到上家發來的大于MTU的Frame(且沒有切分標記),則直接丟棄。
MTU Size Issues
https://www.networkworld.com/article/2224654/mtu-size-issues.html
CentOS安裝tshark抓包工具
?
準備在服務器上用tshark抓包,分析一下數據。直接yum install tshark卻發現沒有這個包。網上搜索一下,各種奇葩安裝方式,又是安裝apt?又是安裝各種環境?我相信既然CentOS已經有了yum這么好的包管理工具,那么一定有更簡單的方式。
最后只好在Google上直接用我這蹩腳的英文搜索一下。果然,一句how to install tshark on centos順利解決了我的問題。
原來一直是自己對yum這個命令了解太少了,平時只會yum install,yum update :first_quarter_moon_with_face: 。那么到底故事如何,客官且聽我細細道來。
當我試圖直接安裝時:
$ yum install tshark
已加載插件:fastestmirror
Loading mirror speeds from cached hostfile
沒有可用軟件包 tshark。
錯誤:無須任何處理
那么,該怎么辦呢? 原來yum提供了搜索功能。
$ yum whatprovides *tshark*
已加載插件:fastestmirror
Loading mirror speeds from cached hostfile
base/7/x86_64/filelists_db ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?| 6.9 MB ?00:00:00
epel/x86_64/filelists ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? | ?10 MB ?00:00:00
extras/7/x86_64/filelists_db ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?| 524 kB ?00:00:00
updates/7/x86_64/filelists_db ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? | 2.1 MB ?00:00:00
1:bash-completion-extras-2.1-11.el7.noarch : Additional programmable completions for Bash
源 ? ?:epel
匹配來源:
文件名 ? ?:/usr/share/bash-completion/completions/tshark
?
wireshark-1.10.14-14.el7.i686 : Network traffic analyzer
源 ? ?:base
匹配來源:
文件名 ? ?:/usr/sbin/tshark
文件名 ? ?:/usr/share/wireshark/tshark.html
文件名 ? ?:/usr/share/man/man1/tshark.1.gz
?
wireshark-1.10.14-14.el7.x86_64 : Network traffic analyzer
源 ? ?:base
匹配來源:
文件名 ? ?:/usr/sbin/tshark
文件名 ? ?:/usr/share/wireshark/tshark.html
文件名 ? ?:/usr/share/man/man1/tshark.1.gz
我們可以看到wireshark包已經包含了tshark包。
接下來就是我們熟悉的步驟了==。
$ yum install wireshark
已加載插件:fastestmirror
Loading mirror speeds from cached hostfile
正在解決依賴關系
--> 正在檢查事務
---> 軟件包 wireshark.x86_64.0.1.10.14-14.el7 將被 安裝
--> 正在處理依賴關系 libsmi.so.2()(64bit),它被軟件包 wireshark-1.10.14-14.el7.x86_64 需要
--> 正在處理依賴關系 libcares.so.2()(64bit),它被軟件包 wireshark-1.10.14-14.el7.x86_64 需要
--> 正在檢查事務
---> 軟件包 c-ares.x86_64.0.1.10.0-3.el7 將被 安裝
---> 軟件包 libsmi.x86_64.0.0.4.8-13.el7 將被 安裝
--> 解決依賴關系完成
?
...
?
已安裝:
? wireshark.x86_64 0:1.10.14-14.el7
?
作為依賴被安裝:
? ? c-ares.x86_64 0:1.10.0-3.el7 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?libsmi.x86_64 0:0.4.8-13.el7
?
完畢!
最后我們驗證一下:
?$ tshark -v
————————————————
版權聲明:本文為CSDN博主「bandaoyu」的原創文章,遵循CC 4.0 BY-SA版權協議,轉載請附上原文出處鏈接及本聲明。
原文鏈接:https://blog.csdn.net/bandaoyu/article/details/116706925