Direct Connect ネットワークパフォーマンスの問題をトラブルシューティングする方法を教えてください。

所要時間5分

AWS Direct Connect 接続で、スループットが低く、トラフィック遅延が発生し、パフォーマンスの問題が発生しています。

解決策

ネットワークとアプリケーションのパフォーマンスの問題を切り分けて診断するには、次の手順を実行します。

**注:**Amazon Virtual Private Cloud (Amazon VPC) を使用してオンプレミスの専用テストマシンをセットアップするのがベストプラクティスです。Amazon Elastic Compute Cloud (Amazon EC2) インスタンスタイプサイズ C5 以上を使用してください。

ネットワークまたはアプリケーションの問題の確認

iPerf3 ツールをインストールして使用し、ネットワーク帯域幅のベンチマークを行い、その結果を他のアプリケーションやツールと照合します。詳細については、iPerf ウェブサイトの「iPerf/iPerf3とは?」を参照してください。

次のコマンドを実行して iPerf3 をインストールします。

Linux/REHEL

$ sudo yum install iperf3 -y

Ubuntu

$ sudo apt install iperf3 -y

スループットを双方向に測定するには、クライアントで iPerf3 を実行します。

Amazon EC2 インスタン (サーバー)

$ iperf3 -s -V

オンプレミスのローカルホスト (クライアント)

$ iperf3 -c <private IP of EC2> -P 15 -t 15
$ iperf3 -c <private IP of EC2> -P 15 -t 15 -R

$ iperf3 -c <private IP of EC2> -w 256K
$ iperf3 -c <private IP of EC2> -w 256K -R

$ iperf3 -c <private IP of EC2> -u -b 1G -t 15
$ iperf3 -c <private IP of EC2> -u -b 1G -t 15 -R

----------------
-P, --parallel n
    number of parallel client threads to run; It is critical to run multi-threads to achieve the max throughput.
-R, --reverse
    reverse the direction of a test. So the EC2 server sends data to the on-prem client to measure AWS -> on-prem throughput.
-u, --udp
    use UDP rather than TCP. Since TCP iperf3 does not report loss, UDP tests are helpful to see the packet loss along a path.

TCP テスト結果の例:

[ ID] Interval          Transfer      Bitrate        Retry[SUM] 0.00-15.00  sec  7.54 GBytes  4.32 Gbits/sec   18112   sender
[SUM] 0.00-15.00  sec  7.52 GBytes  4.31 Gbits/sec           receiver

前の例では次の用語を使用しています。

ビットレート: 測定されたスループットまたは伝送速度。
転送: クライアントとサーバー間で交換されたデータの合計量。
再試行: 再送信されたパケットの数。再送信は送信側で確認されます。

UDP テスト結果の例:

[ ID] Interval           Transfer     Bitrate         Jitter    Lost/Total Datagrams[  5] 0.00-15.00  sec  8.22 GBytes   4.71 Gbits/sec  0.000 ms   0/986756 (0%)  sender
[  5] 0.00-15.00  sec  1.73 GBytes   989 Mbits/sec   0.106 ms   779454/986689 (79%)  receiver

送信側では UDP データグラムが最大量送信されるため、損失は 0% です。受信側の Lost データグラム数/合計データグラム数は、失われたパケットの数と損失率です。この例では、ネットワークトラフィックの 79% が失われています。

**注:**Direct Connect 接続でパブリック仮想インターフェイス (VIF) 経由の Amazon 仮想プライベートネットワーク (Amazon VPN) を使用する場合は、VPN なしでパフォーマンステストを実行します。

メトリクスとインターフェイスカウンタを確認する

Amazon CloudWatch Logs で以下のメトリクスを確認してください。

ConnectionErrorCount:sum statistic を適用します。0 以外の値は AWS デバイスの MAC レベルのエラーを示していることに注意してください。
ConnectionLightLevelTx と ConnectionLightLevelRx: 光信号の読み取り値は -14.4 ～ 2.50 dBm の範囲内でなければなりません。
ConnectionBpsEgress、ConnectionBpsIngress、VirtualInterfaceBpsEgress、および VirtualInterfaceBpsIngress: ビットレートが最大帯域幅に達していないことを確認してください。

詳細については、「AWS Direct Connect のメトリックスとディメンション」を参照してください。

他のユーザーと合計帯域幅を共有するホスト型 VIF を使用する場合は、Direct Connect の所有者に接続の使用状況について確認してください。

Direct Connect ロケーションのルーターとファイアウォールで、次のメトリックを確認してください。

CPU、メモリ、ポート使用率、ドロップ、廃棄
show interfaces statistics などを使用して、CRC、フレーム、衝突、キャリアなどのインターフェースの入出力エラーをチェックします
カウンタが摩耗している場合は、ファイバーパッチリードと SFP モジュールを清掃または交換してください。

AWS Health Dashboard をチェックして、Direct Connect 接続がメンテナンス中でないことを確認します。

MTR を双方向で実行してネットワークパスを確認します

Linux MTR コマンドを使用してネットワークパフォーマンスを分析します。Windows OS では、Linux サブシステムに MTR をインストールできるように WSL 2 を有効にするのがベストプラクティスです。WinMTR は SourceForge のウェブサイトからダウンロードします。

次のコマンドを実行して MTR をインストールします。

Amazon Linux/REHEL installation

$ sudo yum install mtr -y

Ubuntu installation

$ sudo apt install mtr -y

オンプレミスから AWS への方向については、ローカルホスト (ICMP および TCP ベース) で MTR を実行します。

$ mtr -n -c 100 <private IP of EC2> --report$ mtr -n -T -P <EC2 instance open TCP port> -c 100 <private IP of EC2> --report

AWS をオンプレミスにする場合は、EC2 インスタンス (ICMP および TCP ベース) で MTR を実行します。

$ mtr -n -c 100 <private IP of the local host> --report$ mtr -n -T -P <local host open TCP port> -c 100 <private IP of the local host> --report

MTR テスト結果の例:

#ICMP based MTR results$ mtr -n -c 100 192.168.52.10 --report
Start: Sat Oct 30 20:54:39 2021
HOST:                             Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- 10.0.101.222               0.0%   100    0.7   0.7   0.6   0.9   0.0
  2.|-- ???                       100.0   100    0.0   0.0   0.0   0.0   0.0
  3.|-- 10.110.120.2               0.0%   100  266.5 267.4 266.4 321.0   4.8
  4.|-- 10.110.120.1              54.5%   100  357.6 383.0 353.4 423.7  19.6
  5.|-- 192.168.52.10             47.5%   100  359.4 381.3 352.4 427.9  20.6

#TCP based MTR results
$ mtr -n -T -P 80 -c 100 192.168.52.10 --report
Start: Sat Oct 30 21:03:48 2021
HOST:                             Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- 10.0.101.222               0.0%   100    0.9   0.7   0.7   1.1   0.0
  2.|-- ???                       100.0   100    0.0   0.0   0.0   0.0   0.0
  3.|-- 10.110.120.2               0.0%   100  264.1 265.8 263.9 295.3   3.4
  4.|-- 10.110.120.1               8.0%   100  374.3 905.3 354.4 7428. 1210.6
  5.|-- 192.168.52.10             12.0%   100  400.9 1139. 400.4 7624. 1384.3

ホップの各行は、データパケットが送信元から宛先に渡すネットワークデバイスを表します。MTRテスト結果の読み方の詳細については、ExaVault のウェブサイトの「MTR 出力ネットワーク診断ツールの読み込み」を参照してください。

次の例は、BGP ピア 10.110.120.1 と 10.110.120.2 との Direct Connect 接続を示しています。損失率は、4 番目と 5 番目の宛先ホップで確認されます。これは、Direct Connect 接続またはリモートルーター 10.110.120.1 に問題があることを示している可能性があります。Direct Connect 接続では TCP が ICMP よりも優先されるため、TCP MTR の結果では損失率が低くなります。

#ICMP based MTR results$ mtr -n -c 100 192.168.52.10 --report
Start: Sat Oct 30 20:54:39 2021
HOST:                             Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- 10.0.101.222               0.0%   100    0.7   0.7   0.6   0.9   0.0
  2.|-- ???                       100.0   100    0.0   0.0   0.0   0.0   0.0
  3.|-- 10.110.120.2               0.0%   100  266.5 267.4 266.4 321.0   4.8
  4.|-- 10.110.120.1              54.5%   100  357.6 383.0 353.4 423.7  19.6
  5.|-- 192.168.52.10             47.5%   100  359.4 381.3 352.4 427.9  20.6

#TCP based MTR results
$ mtr -n -T -P 80 -c 100 192.168.52.10 --report
Start: Sat Oct 30 21:03:48 2021
HOST:                             Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- 10.0.101.222               0.0%   100    0.9   0.7   0.7   1.1   0.0
  2.|-- ???                       100.0   100    0.0   0.0   0.0   0.0   0.0
  3.|-- 10.110.120.2               0.0%   100  264.1 265.8 263.9 295.3   3.4
  4.|-- 10.110.120.1               8.0%   100  374.3 905.3 354.4 7428. 1210.6
  5.|-- 192.168.52.10             12.0%   100  400.9 1139. 400.4 7624. 1384.3

次の例は、ローカルファイアウォールまたは NAT デバイスのパケット損失が 5% であることを示しています。パケット損失は、宛先を含む後続のすべてのホップに影響します。

$ mtr -n -c 100 192.168.52.10 --report
Start: Sat Oct 30 21:11:22 2021
HOST:                              Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- 10.0.101.222               5.0%   100    0.8   0.7   0.7   1.1   0.0
  2.|-- ???                       100.0   100    0.0   0.0   0.0   0.0   0.0
  3.|-- 10.110.120.2               6.0%   100  265.7 267.1 265.6 307.8   5.1
  4.|-- 10.110.120.1               6.0%   100  265.1 265.2 265.0 265.4   0.0
  5.|-- 192.168.52.10              6.0%   100  266.7 266.6 266.5 267.2   0.0

パケットキャプチャを行い、結果を分析します

ローカルホストと EC2 インスタンスでパケットキャプチャを行います。tcpdump または Wireshark ユーティリティを使用して、分析用のネットワークトラフィックを取得します。次の tcpdump コマンド例は、タイムスタンプとホスト IP アドレスを取得します。

tcpdump -i <network interface> -s0 -w $(date +"%Y%m%d\_%H%M%S").$(hostname -s).pcap port <port>

Switch ウェブサイトにある TCPスループットツールを使用して、ネットワーク制限、帯域幅遅延積、TCP バッファサイズを計算してください。詳細については、「AWS Direct Connect のトラブルシューティング」を参照してください。

Direct Connect ネットワークパフォーマンスの問題をトラブルシューティングする方法を教えてください。

解決策

ネットワークまたはアプリケーションの問題の確認

メトリクスとインターフェイスカウンタを確認する

MTR を双方向で実行してネットワークパスを確認します

パケットキャプチャを行い、結果を分析します

関連情報

関連するコンテンツ