iPerf を使用して UDP パケット損失をテストおよびトラブルシューティングする方法-Linuxの運用と保守-php.cn

iPerf を使用して UDP パケット損失をテストおよびトラブルシューティングする方法

坏嘻嘻

リリース： 2018-09-28 15:37:15

オリジナル

8907 人が閲覧しました

この記事の内容は、iPerf を使用して UDP パケット損失の問題をテストおよびトラブルシューティングする方法についてです。必要な方は参考にしていただければ幸いです。

iPerf を使用して UDP パケット損失の問題をテストおよびトラブルシューティングする

現象の説明

高速チャネルを使用して、同じリージョン (リージョン VPC ネットワークタイプの 2 つの ECS インスタンスを設定した後、レートは増加傾向を示しています。以下に示すように:

iPerf を使用して UDP パケット損失をテストおよびトラブルシューティングする方法

##問題分析

2 つのネットワークタイプの ECS インスタンスのプライベート IP が次のとおりであると仮定します。 VPC ECS A (192.168.104.235) と ECS B (10.182.83.13) を使用し、Netcat (NC) を使用して UDP データパケットを監視および送信すると、ネットワークタイプの ECS インスタンス A とインスタンス B の間の通信リンク図は次のようになります。 :

iPerf を使用して UDP パケット損失をテストおよびトラブルシューティングする方法

データフローの方向は次のとおりです:

ECS A(192.168.104.235)-> NC 1(100.105.59.3)-> VGW(10.141.166.253)-> NC 2(100.105.59.9)-> ECS B(10.182.83.13)

ログイン後にコピー

パケット損失の最終的な原因を見つけるために、リンクのトラブルシューティングと分析を行う必要があります。

解決策

注: ソース Netcat (つまり NC 1) と宛先 Netcat (つまり NC 2) の間の通信のみが表示されるため、パケットキャプチャとトラブルシューティングでは、パケット損失が Netcat (NC) 間の直接通信によって引き起こされたものであると恣意的に判断するという誤解を避ける必要があります。

調査の結果、送信元でキャプチャされた eth0 のパケットは VGW に送信されるが、宛先でパケットがキャプチャされると、シェルが宛先 NC をカプセル化していることがわかります。 2 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

ログイン後にコピー

2 つの NC eth0 ロケーションでパケットをキャプチャします。

NC 1：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
NC 2：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 1 IP を自動的にカプセル化するため、VGW 側のデータパケットのメッセージ形式は 100.105.59.3:46728 -> 100.105.59.9:250 です。

パケットキャプチャ結果に基づく分析。

ECS A パケット損失/パケット配信: 171/510203

NC 1 eth0 パケット配信: 510204

ASW および LSW フロー統計パケット配信: 510204

NC 2 eth0 パケット受信: 510204

ECS B パケット受信: 510204、キャプチャ 507442、カーネル 2162 によってドロップされました

#上記の分析により、インスタンスプロトコルスタックのパケット損失が特定され、インスタンスの内部 UDP バッファサイズ。ネットワークスタック (スタック) を調整します。デフォルトの UDF バッファサイズは 212992 (208 KB) ですが、2097152 (2 MB) まで調整できます。

/proc/sys/net/core/rmem_default #默认的接收数据包内存大小
/proc/sys/net/core/rmem_max #最大的接收数据包内存大小

ログイン後にコピー

調整後に UDP パケット損失をテストします。

以上がiPerf を使用して UDP パケット損失をテストおよびトラブルシューティングする方法の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。