728
iperf UDP測試丟包問題分析
本文目的
分析同一region下兩台vpc類型ECS之間iperf測試UDP丟包問題排查
問題描述
用戶在同一個region下的兩台ECS分屬兩個vpc，兩個vpc通過高速通道打通，然後通過iperf測試二者內網之間UDP的丟包情況，當測試帶寬達到50M以上的時候，出現了丟包現象，且隨著帶寬的增加，丟包率出現增長趨勢。
ECS A：iperf -c <ECS_B_IP> -u -b <bandwidth>
ECS B: iperf -s -u
問題分析
vpc類型ECS A與vpc類型ECS B 通信鏈路圖如下：
具體數據流走向
ECS A(192.168.104.235)-> NC1(100.105.59.3)-> vgw(10.141.166.253)-> NC2(100.105.59.9)-> ECS B(10.182.83.13)
排查思路
- 丟包的第一感覺是網絡丟包，抓包排查有個誤區，由於隻看到了源NC和目的NC之前的通信，故判斷是NC和NC之間的直接通信
- vpc同學介入一起排查，發現源端eth0的抓包，發給了vgx，但是在目的端抓包發現外殼封裝了目的NC的IP
[Time ] 17:32:07.130844 Point: `input `
[ETHER] 24:4c:07:33:0e:02 -> 00:04:37:28:00:65, eth_type: 0x0800
[IPv4 ] 100.105.59.3 -> 10.141.166.253
proto: 17, ver: 04, ihl: 05, len: 1534, ident: 59824,R: 0, DF: 1, MF: 0, offset: 0, ttl: 60, chksum: 0xfe47
[UDP ] sport: 46703, dport: 250, size: 1514, chksum: 0x0000
[VxLan] debug_flag: 0, vlan_tag: 0, payload_type: 0, version: 1, tunnel_id: 1878597, tos: 0, tof: 0
[IPv4 ] 192.168.104.235 -> 10.182.83.13
proto: 17, ver: 04, ihl: 05, len: 1498, ident: 55469,R: 0, DF: 1, MF: 0, offset: 0, ttl: 64, chksum: 0xd50e
[UDP ] sport: 36687, dport: 5001, size: 1478, chksum: 0xa0aa
[Time ] 17:32:07.130854 Point: `output`
[ETHER] 24:4c:07:33:0e:02 -> 00:04:37:28:00:65, eth_type: 0x0800
[IPv4 ] 100.105.59.3 -> 100.105.59.9
proto: 17, ver: 04, ihl: 05, len: 1534, ident: 59824,R: 0, DF: 1, MF: 0, offset: 0, ttl: 60, chksum: 0x0000
[UDP ] sport: 46703, dport: 250, size: 1514, chksum: 0x0000
[VxLan] debug_flag: 0, vlan_tag: 0, payload_type: 0, version: 1, tunnel_id: 2125861, tos: 0, tof: 0
[IPv4 ] 192.168.104.235 -> 10.182.83.13
proto: 17, ver: 04, ihl: 05, len: 1498, ident: 55469,R: 0, DF: 1, MF: 0, offset: 0, ttl: 64, chksum: 0xd50e
[UDP ] sport: 36687, dport: 5001, size: 1478, chksum: 0xa0aa
- 在確認數據包確認通過vgw後，開始統計抓包信息，方案如下
ECS A 通過iperf打UDP流量：iperf -c 10.182.83.13 -u -b 600m
ECS B 通過iperf接收：iperf -u -s
VM 內部抓包
ECS A：
sudo tcpdump -w ~/client.pcap -n -i eth0 src host 192.168.104.25 and src port 1234
ECS B:
sudo tcpdump -w ~/server.pcap -n -i eth0 src host 192.168.104.25 and src port 1234
兩個NC eth0口抓包：
NC1:
sudo houyi-tcpdump -w /apsara/i-6we6pnh19n2q7srkgomd.pcap -nnK -i eth0 udp and src inner_port 1234 and dst inner_host 10.182.83.13
NC2: sudo houyi-tcpdump -B 4096 -w /apsara/i-6we53i9h3ducbju5rmuw.pap -nn -i eth0 udp -K and src inner_host 192.168.104.235 and src inner_port 1234
網工配合在ASW和LSW部署流統
100.105.59.3:46728 ->10.141.166.253:250
由於目的端包外殼自動封裝了目的NC的IP，所以vgw上的包的報文格式是
100.105.59.3:46728 -> 100.105.59.9:250
- 抓包結果
ECS A 丟包/發包：171/510203
NC1 eth0 發包：510204
ASW和LSW流統計出包：510204
NC2 eth0 收包：510204
ECS B 收包：510204，capture 507442， dropped by kernel 2162
- 以上分析定位到vm內部丟包，即協議棧丟包， 通過調整 vm 內部UDP buffer size來調整網絡 stack，默認的UDF buffer size 為212992（208KB），調整至 2097152（2MB）
/proc/sys/net/core/rmem_default
/proc/sys/net/core/rmem_max
- 調整後，再次測試發現基本不丟包
後記
- 上述問題本身屬於協議棧丟包的一種場景，關於排查協議棧丟包的傳統方法是利用tcpdump或者更先進的wireshark來進行抓包分析，老板@鐵竹推薦了大神@褚霸介紹的Dropwatch工具，其定位很清晰，就是用來查看協議棧丟包的問題。詳情請看下麵的連接
https://blog.yufeng.info/archives/2497
- 還有就是我們組@礪辛自製的一款網絡問題排查小工具，其中就包含了udp窗口過小導致的協議棧丟包，可以通過複現上述問題快速定位原因
https://www.atatech.org/articles/85295
最後更新：2017-08-24 12:02:54