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

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

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工具，其定位很清晰，就是用来查看协议栈丢包的问题。详情请看下面的连接

http://blog.yufeng.info/archives/2497

• 还有就是我们组@砺辛自制的一款网络问题排查小工具，其中就包含了udp窗口过小导致的协议栈丢包，可以通过复现上述问题快速定位原因

https://www.atatech.org/articles/85295